בקשה של יומני שרת proxy

בדפים של Cloud Service Mesh יש קישורים לשני סוגים שונים של יומנים ב-Cloud Logging:‏ יומני גישה (נקראים גם יומני Envoy) ויומני תנועה (נקראים גם יומני גישה של Google Cloud Observability).

יומני גישה

הפעלת יומני גישה

השלבים שנדרשים להפעלת יומני גישה תלויים בסוג Cloud Service Mesh, כלומר מנוהל או בתוך האשכול:

מנוהל

פועלים לפי ההוראות כדי להפעיל יומני גישה ב-Cloud Service Mesh מנוהל.

באשכול

פועלים לפי ההוראות כדי להפעיל יומני גישה ב-Cloud Service Mesh בתוך האשכול.

צפייה ביומני הגישה

כדי לראות את יומני הגישה ב-Logs Explorer:

  1. מנווטים אל Logs Explorer:

    כניסה לדף Logs Explorer

  2. בוחרים את הפרויקט המתאים Google Cloud .

  3. מריצים את השאילתה הבאה:

    resource.type="k8s_container" \
resource.labels.container_name="istio-proxy"
resource.labels.cluster_name="CLUSTER_NAME" \
resource.labels.namespace_name="NAMESPACE_NAME" \
resource.labels.pod_name="POD_NAME"

יומני תעבורת נתונים

הפעלת יומני תנועה

יומני התנועה מופעלים כברירת מחדל, אלא אם Cloud Service Mesh מותקן ב-Google Distributed Cloud עם Istio CA (שנקרא בעבר Citadel).

כדי להפעיל יומני תנועה ב-Google Distributed Cloud עם Istio CA כשמתקינים את Cloud Service Mesh בתוך האשכול, משתמשים בדגל --option stackdriver. אפשר גם להפעיל יומני תנועה ב-Google Distributed Cloud באמצעות Istio CA אחרי התקנה של Cloud Service Mesh בתוך האשכול.

צפייה ביומני תעבורת נתונים

צפייה ביומני תנועה בכלי Logs Explorer

כדי להציג יומני תעבורת נתונים ב-Logs Explorer:

  1. מנווטים אל Logs Explorer:

    כניסה לדף Logs Explorer

  2. בוחרים את הפרויקט המתאים Google Cloud .

  3. מריצים את השאילתה הבאה בהתאם ליומני הגישה של הלקוח או של השרת:

    יומני שרת

    resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_NAME/logs/server-accesslog-stackdriver"

    יומני לקוח

    resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_NAME/logs/client-accesslog-stackdriver"

צפייה ביומני תעבורה בדף Anthos Service Mesh

כדי לראות את יומני התנועה בדף Cloud Service Mesh של שירות מסוים במהלך פרק זמן מוגדר:

  1. במסוף Google Cloud , נכנסים לדף Cloud Service Mesh.

    כניסה לדף Cloud Service Mesh

  2. בקטע Services (שירותים), בוחרים את שם השירות שרוצים לבדוק.

  3. עוברים לדף מדדים.

  4. מציינים טווח זמן מהתפריט הנפתח טווח זמן או מגדירים טווח מותאם אישית באמצעות ציר הזמן.

  5. בקטע Select a filter option (בחירת אפשרות סינון), לוחצים על View traffic logs (הצגת יומני תנועה).

יומן התנועה נקרא server-accesslog-stackdriver והוא מצורף למשאב במעקב המתאים (k8s_container או gce_instance) שבו השירות שלכם משתמש. יומן התנועה מכיל את הפרטים הבאים:

  • מאפיינים של בקשת HTTP, כמו מזהה, כתובת URL, גודל, זמן אחזור וכותרות נפוצות.

  • פרטי עומס העבודה של המקור והיעד, כמו שם, מרחב שמות, זהות ותוויות נפוצות.

  • אם המעקב מופעל, פרטי המעקב, כמו דגימה, מזהה מעקב ומזהה טווח.

דוגמה לרשומה ביומן:

{
  insertId: "1awb4hug5pos2qi"
  httpRequest: {
    requestMethod: "GET"
    requestUrl: "YOUR-INGRESS/productpage"
    requestSize: "952"
    status: 200
    responseSize: "5875"
    remoteIp: "10.8.0.44:0"
    serverIp: "10.56.4.25:9080"
    latency: "1.587232023s"
    protocol: "http"
  }
  resource: {
    type: "k8s_container"
    labels: {
      location: "us-central1-a"
      project_id: "YOUR-PROJECT"
      pod_name: "productpage-v1-76589d9fdc-ptnt9"
      cluster_name: "YOUR-CLUSTER-NAME"
      container_name: "productpage"
      namespace_name: "default"
    }
  }
  timestamp: "2020-04-28T19:55:21.056759Z"
  severity: "INFO"
  labels: {
    destination_principal: "spiffe://cluster.local/ns/default/sa/bookinfo-productpage"
    response_flag: "-"
    destination_service_host: "productpage.default.svc.cluster.local"
    source_app: "istio-ingressgateway"
    service_authentication_policy: "MUTUAL_TLS"
    source_name: "istio-ingressgateway-5ff85d8dd8-mwplb"
    mesh_uid: "YOUR-MESH-UID"
    request_id: "021ce752-9001-4ac6-b6d6-3b15f5d3632"
    destination_namespace: "default"
    source_principal:  "spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"
    destination_workload: "productpage-v1"
    destination_version: "v1"
    source_namespace: "istio-system"
    source_workload: "istio-ingressgateway"
    destination_name: "productpage-v1-76589d9fdc-ptnt9"
    destination_app: "productpage"
  }
  trace: "projects/YOUR-PROJECT/traces/d4197f59b7a43e3aeff3571bac99d536"
  receiveTimestamp: "2020-04-29T03:07:14.362416217Z"
  spanId: "43226343ca2bb2b1"
  traceSampled: true
  logName: "projects/YOUR-PROJECT/logs/server-accesslog-stackdriver"
  receiveTimestamp: "2020-04-28T19:55:32.185229100Z"
}

הסבר על טלמטריית Anthos Service Mesh

בקטעים הבאים מוסבר איך לבדוק את הסטטוס של הרשת ואיך לעיין בנתוני הטלמטריה השונים שמכילים פרטים שימושיים שיעזרו לכם לפתור בעיות.

פירוש מדדים של מישור הבקרה

כשמתקינים את Cloud Service Mesh עם מישור הבקרה בתוך האשכול, המערכת מייצאת מדדים ל-Google Cloud Observability לצורך מעקב, כברירת מחדל.istiod המדדים האלה מתחילים בקידומת istiod ומספקים תובנות לגבי מצב מישור הבקרה, כמו מספר השרתים הפרוקסי שמחוברים לכל מופע של מישור הבקרה, אירועי הגדרה, פעולות push ואימותים.istio.io/control

כדי לבדוק את מישור הבקרה או לפתור בו בעיות, פועלים לפי השלבים הבאים.

  1. טעינת לוח בקרה לדוגמה:

    git clone https://github.com/GoogleCloudPlatform/monitoring-dashboard-samples && cd monitoring-dashboard-samples/dashboards && git checkout servicemesh

  2. מתקינים את לוח הבקרה של Cloud Service Mesh:

    gcloud monitoring dashboards create --config-from-file=dashboards/servicemesh/anthos-service-mesh-control-plane-monitoring.json

  3. מחפשים ברשימה את מרכז הבקרה שנקרא Istio Control Plane Dashboard. מידע נוסף זמין במאמר בנושא הצגת לוח הבקרה המותקן.

רשימה מלאה של המדדים הזמינים מופיעה במאמר מדדים מיוצאים.

אבחון עיכובים בהגדרות

בשלבים הבאים מוסבר איך להשתמש במדד pilot_proxy_convergence_time כדי לאבחן עיכוב בין שינוי בהגדרות לבין ההתכנסות של כל השרתים הפרוקסי.

  1. מריצים פקודת shell ב-pod:

    kubectl exec -it $(kubectl get pod -l app=pilot -o jsonpath='{.items[0].metadata.name}' -n istio-system) -n istio-system -c istio-proxy -- curl -s

  2. גישה אל localhost:15014 ואל grep עבור convergence במדדים:

    curl http://localhost:15014/metrics | grep convergence

הסבר על יומני הגישה של חבילת התפעול של Google Cloud

בקטע הבא מוסבר איך להשתמש ביומני הגישה של Google Cloud Observability כדי לפתור בעיות בחיבור. יומני הגישה והתנועה של Google Cloud Observability מופעלים כברירת מחדל.

‫Cloud Service Mesh מייצא נתונים ליומני גישה של Google Cloud Observability, שיכולים לעזור לכם לנפות באגים בבעיות מהסוגים הבאים:

  • תנועה וכשלים
  • ניתוב בקשות מקצה לקצה

יומני הגישה של Google Cloud Observability מופעלים כברירת מחדל בהתקנות של Cloud Service Mesh ב-Google Kubernetes Engine. כדי להפעיל את יומני הגישה של Google Cloud Observability, מריצים מחדש את הפקודה asmcli install. משתמשים באותן האפשרויות שבהן השתמשתם בהתקנה המקורית, אבל משמיטים את שכבת העל המותאמת אישית שהשביתה את Stackdriver.

יש שני סוגים של יומני גישה:

  • יומני גישה לשרת מספקים תצוגה של בקשות בצד השרת. הם ממוקמים בקטע server-accesslog-stackdriver, ומצורפים למשאב k8s_container שבמעקב. כדי להציג יומני גישה בצד השרת, משתמשים בתחביר כתובת ה-URL הבא:

    https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"&project=PROJECT_ID

  • יומני גישה של לקוחות מספקים תצוגה של בקשות מצד הלקוח. הם נמצאים בקטע client-accesslog-stackdriver, ומצורפים למשאב במעקב k8s_pod. כדי להציג את יומני הגישה בצד הלקוח, משתמשים בתחביר כתובת ה-URL הבא:

    https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/client-accesslog-stackdriver"&project=PROJECT_ID

יומני הגישה מכילים את המידע הבא:

  • מאפיינים של בקשת HTTP, כמו מזהה, כתובת URL, גודל, זמן אחזור וכותרות נפוצות.
  • פרטי עומס העבודה של המקור והיעד, כמו שם, מרחב שמות, זהות ותוויות משותפות.
  • מידע על השירות הקנוני והגרסה שלו במקור וביעד.
  • אם המעקב מופעל, היומנים מכילים פרטי מעקב, כמו דגימה, מזהה מעקב ומזהה טווח.

המידע שמוצג ביומני הגישה של Google Cloud Observability מגיע מיומני הגישה של Envoy, כשמפעילים אותם בהגדרות של Istio. הם מכילים את הכותרות הבאות:

  • route_name
  • upstream_cluster
  • X-Envoy-Original-Path
  • X-Envoy-Original-Host

זו דוגמה לרשומה ביומן:

{
  "insertId": "1j84zg8g68vb62z",
  "httpRequest": {
    "requestMethod": "GET",
    "requestUrl": "http://35.235.89.201:80/productpage",
    "requestSize": "795",
    "status": 200,
    "responseSize": "7005",
    "remoteIp": "10.168.0.26:0",
    "serverIp": "10.36.3.153:9080",
    "latency": "0.229384205s",
    "protocol": "http"
  },
  "resource": {
    "type": "k8s_container",
    "labels": {
      "cluster_name": "istio-e2e22",
      "namespace_name": "istio-bookinfo-1-68819",
      "container_name": "productpage",
      "project_id": "***",
      "location": "us-west2-a",
      "pod_name": "productpage-v1-64794f5db4-8xbtf"
    }
  },
  "timestamp": "2020-08-13T21:37:42.963881Z",
  "severity": "INFO",
  "labels": {
    "protocol": "http",
    "upstream_host": "127.0.0.1:9080",
    "source_canonical_service": "istio-ingressgateway",
    "source_namespace": "istio-system",
    "x-envoy-original-path": "",
    "source_canonical_revision": "latest",
    "connection_id": "32",
    "upstream_cluster": "inbound|9080|http|productpage.istio-bookinfo-1-68819.svc.cluster.local",
    "requested_server_name": "outbound_.9080_._.productpage.istio-bookinfo-1-68819.svc.cluster.local",
    "destination_version": "v1",
    "destination_workload": "productpage-v1",
    "source_workload": "istio-ingressgateway",
    "destination_canonical_revision": "v1",
    "mesh_uid": "cluster.local",
    "source_principal": "spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account",
    "x-envoy-original-dst-host": "",
    "service_authentication_policy": "MUTUAL_TLS",
    "destination_principal": "spiffe://cluster.local/ns/istio-bookinfo-1-68819/sa/bookinfo-productpage",
    "response_flag": "-",
    "log_sampled": "false",
    "destination_service_host": "productpage.istio-bookinfo-1-68819.svc.cluster.local",
    "destination_name": "productpage-v1-64794f5db4-8xbtf",
    "destination_canonical_service": "productpage",
    "destination_namespace": "istio-bookinfo-1-68819",
    "source_name": "istio-ingressgateway-6845f6d664-lnfvp",
    "source_app": "istio-ingressgateway",
    "destination_app": "productpage",
    "request_id": "39013650-4e62-9be2-9d25-78682dd27ea4",
    "route_name": "default"
  },
  "logName": "projects/***/logs/server-accesslog-stackdriver",
  "trace": "projects/***t/traces/466d77d15753cb4d7749ba5413b5f70f",
  "receiveTimestamp": "2020-08-13T21:37:48.758673203Z",
  "spanId": "633831cb1fda4fd5",
  "traceSampled": true
}

אפשר להשתמש ביומן הזה בדרכים שונות:

  • שילוב עם Cloud Trace, שהוא תכונה אופציונלית ב-Cloud Service Mesh.
  • ייצוא יומני תנועה ל-BigQuery, שבו אפשר להריץ שאילתות כמו בחירת כל הבקשות שלוקחות יותר מ-5 שניות.
  • יצירת מדדים מבוססי-יומנים.
  • פתרון בעיות שגיאה 404 ו-503

פתרון בעיות שגיאה 404 ו-503

בדוגמה הבאה מוסבר איך להשתמש ביומן הזה כדי לפתור בעיות כשבקשה נכשלת עם קוד תגובה 404 או 503.

  1. ביומן הגישה של הלקוח, מחפשים רשומה כמו הבאה:

    httpRequest: {
requestMethod: "GET"
requestUrl: "://IP_ADDRESS/src/Util/PHP/eval-stdin.php"
requestSize: "2088"
status: 404
responseSize: "75"
remoteIp: "10.168.0.26:34165"
serverIp: "10.36.3.149:8080"
latency: "0.000371440s"
protocol: "http"
}

  2. מנווטים לתוויות ברשומה ביומן הגישה. מחפשים את השדה response_flag שדומה לזה:

    response_flag: "NR"

    הערך NR הוא ראשי תיבות של NoRoute, כלומר לא נמצא מסלול ליעד או שלא נמצאה שרשרת מסננים תואמת לחיבור במורד הזרם. באופן דומה, אפשר להשתמש בתווית response_flag כדי לפתור שגיאות של 503.

  3. אם מופיעות שגיאות 503 ביומני הגישה של הלקוח ושל השרת, צריך לוודא ששמות היציאות שהוגדרו לכל שירות תואמים לשם הפרוטוקול שנמצא בשימוש ביניהם. לדוגמה, אם לקוח בינארי של golang מתחבר לשרת golang באמצעות HTTP, אבל היציאה נקראת http2, הפרוטוקול לא ינהל משא ומתן אוטומטי בצורה נכונה.

מידע נוסף זמין במאמר בנושא דגלים של תגובות.

פירוש יומני הגישה

בשלבים הבאים מוסבר איך להשתמש ביומני הגישה (שנקראים גם יומני Envoy proxy) כדי להציג את התנועה בין שני הקצוות של חיבור לצורך פתרון בעיות.

יומני גישה שימושיים לאבחון בעיות כמו:

  • תנועה וכשלים
  • ניתוב בקשות מקצה לקצה

יומני הגישה לא מופעלים כברירת מחדל ב-Cloud Service Mesh, ואפשר להפעיל אותם רק באופן גלובלי בכל הרשת.

כדי לפתור בעיות שקשורות לחיבור או לבקשות שנכשלו, אפשר ליצור פעילות באפליקציה שמפעילה בקשת HTTP, ואז לבדוק את הבקשה המשויכת ביומני המקור או היעד.

אם מופעלת בקשה והיא מופיעה ביומני ה-proxy של המקור, זה מצביע על כך שהפניית התנועה של iptables פועלת בצורה תקינה ושה-proxy של Envoy מטפל בתנועה. אם מופיעות שגיאות ביומנים, צריך ליצור קובץ dump של הגדרות Envoy ולבדוק את הגדרות האשכול של Envoy כדי לוודא שהן נכונות. אם הבקשה מופיעה אבל ביומן אין שגיאות, צריך לבדוק את יומני ה-proxy של היעד.

אם הבקשה מופיעה ביומני ה-proxy של היעד, זה מצביע על כך שהרשת עצמה פועלת בצורה תקינה. אם מופיעה שגיאה, מריצים dump של הגדרות Envoy ומוודאים שהערכים הנכונים של יציאת התנועה מוגדרים בהגדרות של listener.

אם הבעיה נמשכת אחרי שמבצעים את השלבים הקודמים, יכול להיות ש-Envoy לא מצליח לנהל משא ומתן אוטומטי על הפרוטוקול בין ה-sidecar לבין ה-pod של האפליקציה. מוודאים ששם יציאת השירות של Kubernetes, למשל http-80, זהה לפרוטוקול שבו האפליקציה משתמשת.

שימוש ב-Logs Explorer לשליחת שאילתות ליומנים

אפשר להשתמש בממשק של Logs Explorer כדי לשלוח שאילתות ליומני גישה ספציפיים. לדוגמה, כדי לשלוח שאילתה על כל הבקשות שבהן MULTUAL_TLS מופעל ונעשה שימוש בפרוטוקול grpc, מוסיפים את השאילתה הבאה ליומני הגישה של השרת:

labels.protocol="grpc" labels.service_authentication_policy="MULTUAL_TLS"

הגדרת מדיניות של יומן גישה

כדי להגדיר רישום ביומן של שרת proxy ב-Cloud Service Mesh מנוהל, ראו יומני גישה של Envoy.

כדי להגדיר מדיניות של יומן גישה ל-Cloud Service Mesh באמצעות מישור הבקרה באשכול:

  1. יוצרים IstioOperator קובץ שכבת-על בהתאמה אישית שכולל את הערכים הרלוונטיים של AccessLogPolicyConfig לתרחיש שלכם.

  2. מעבירים את הקובץ הזה אל asmcli באמצעות האפשרות --custom_overlay כדי לעדכן את התצורה של מישור הבקרה באשכול. מידע על הפעלת asmcli install עם קובץ שכבת-על מותאם אישית זמין במאמר התקנה עם תכונות אופציונליות.

הצגת מידע ספציפי על שירות או עומס עבודה

אם יש לכם בעיה בשירות או בעומס עבודה ספציפיים ולא בעיה כללית ברשת, כדאי לבדוק את שרתי ה-proxy של Envoy ולאסוף מהם מידע רלוונטי. כדי לאסוף מידע על עומס עבודה מסוים ועל שרתי ה-proxy שלו, אפשר להשתמש ב-pilot-agent:

kubectl exec POD_NAME -c istio-proxy -- pilot-agent request GET SCOPE

בדוגמה, SCOPE הוא אחד מהבאים:

  • ‫certs – אישורים במופע Envoy
  • ‫clusters - אשכולות עם Envoy מוגדר
  • ‫config_dump – יצירת עותק של הגדרות Envoy
  • ‫listeners - Listeners with Envoy configured
  • logging – הצגה ושינוי של הגדרות הרישום ביומן
  • ‫stats - נתונים סטטיסטיים של Envoy
  • ‫stats/prometheus – נתונים סטטיסטיים של Envoy כרשומות Prometheus

הצגת מצבי שקע ה-proxy

אפשר לבדוק ישירות את מצב השקעים של Envoy proxy באמצעות התהליך הבא.

  1. הצגת רשימה של שקעים מבוססים, כולל שקעים במצב TIME_WAIT state, שיכולה להשפיע באופן שלילי על יכולת ההתאמה אם המספר שלהם גבוה:

    kubectl exec POD_NAME -c istio-proxy -- ss -anopim

  2. הצגת סיכום של נתונים סטטיסטיים של שקעים:

    kubectl exec POD_NAME -c istio-proxy -- ss -s

מידע נוסף זמין במאמר מבוא לפקודה ss.

יומני istio-proxy ו-istio-init

בנוסף, כדאי לאחזר את היומנים של istio-proxy ולבדוק את התוכן שלהם כדי לזהות שגיאות שיכולות להצביע על הגורם לבעיה:

kubectl logs POD_NAME -c istio-proxy

אפשר לעשות את אותו הדבר עם מאגר התגים init:

kubectl logs POD_NAME -c istio-init

המאמרים הבאים