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

ב-Cloud Service Mesh יש תמיכה בשני סוגים שונים של יומני גישה ב-Cloud Logging: יומני תעבורת נתונים (שנקראים גם יומני גישה של Google Cloud Observability) ויומני גישה של Envoy. בדף הזה מוסבר איך להפעיל, להשבית, להציג ולפרש את היומנים האלה. שימו לב שיומני התנועה מופעלים כברירת מחדל.

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

‫Traffic Director מנוהל

יומני הגישה של Envoy

מריצים את הפקודה הבאה כדי להפעיל את יומני הגישה של Envoy ולהשבית את יומני התנועה:

cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: enable-envoy-disable-sd
  namespace: istio-system
spec:
  accessLogging:
  - providers:
      - name: envoy
  - providers:
      - name: stackdriver
    disabled: true
EOF

שימו לב ששם הספק של יומן התנועה הוא stackdriver.

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

כברירת מחדל, יומני התנועה מופעלים ויומני הגישה של Envoy מושבתים. אם הפעלתם בעבר את יומני הגישה של Envoy ואתם רוצים להפעיל את יומני התנועה ולהשבית את יומני הגישה של Envoy, הריצו את הפקודה הבאה:

cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: disable-envoy-enable-sd
  namespace: istio-system
spec:
  accessLogging:
  - providers:
      - name: envoy
    disabled: true
  - providers:
      - name: stackdriver
EOF

שני הסוגים

  • כדי להפעיל גם את יומני הגישה וגם את יומני התנועה של Envoy, מריצים את הפקודה הבאה:

    cat <<EOF | kubectl apply -n istio-system -f -
    apiVersion: telemetry.istio.io/v1alpha1
    kind: Telemetry
    metadata:
      name: enable-envoy-and-sd-access-log
      namespace: istio-system
    spec:
      accessLogging:
      - providers:
          - name: envoy
          - name: stackdriver
    EOF
    
  • כדי להשבית גם את יומני הגישה וגם את יומני התנועה של Envoy, מריצים את הפקודה הבאה:

    cat <<EOF | kubectl apply -n istio-system -f -
    apiVersion: telemetry.istio.io/v1alpha1
    kind: Telemetry
    metadata:
      name: disable-envoy-and-sd
      namespace: istio-system
    spec:
      accessLogging:
      - providers:
          - name: envoy
        disabled: true
      - providers:
          - name: stackdriver
        disabled: true
    EOF
    

יומני גישה ספציפיים לבורר

כדי להפעיל את רישום הגישה ביומן רק לעומס עבודה ספציפי, קודם צריך להשבית אותו ברמת ה-mesh על ידי החלת הגדרת טלמטריה במרחב השמות הבסיסי (כי רישום התנועה ביומן מופעל כברירת מחדל). לאחר מכן, אתם מחילים הגדרה נפרדת עם בורר כדי להפעיל אותה רק לעומס העבודה הזה.

# 1. Disable mesh-wide access logging
cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: disable-mesh-wide-telemetry
  namespace: istio-system
spec:
  accessLogging:
  - providers:
    - name: stackdriver
    disabled: true
EOF

# 2. Enable access logging for a specific workload
cat <<EOF | kubectl apply -n NAMESPACE -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: workload-specific-telemetry
  namespace: NAMESPACE
spec:
  selector:
    matchLabels:
      app: YOUR_APP_LABEL
  accessLogging:
  - providers:
    - name: stackdriver
EOF

istiod מנוהל

יומני הגישה של Envoy

מריצים את הפקודות הבאות כדי להפעיל את יומן הגישה של Envoy:

  1. מריצים את הפקודה הבאה כדי להוסיף את accessLogFile: /dev/stdout:

    cat <<EOF | kubectl apply -f -
    apiVersion: v1
    data:
      mesh: |-
        accessLogFile: /dev/stdout
    kind: ConfigMap
    metadata:
      name: istio-release-channel
      namespace: istio-system
    EOF
    

    כאשר release-channel הוא ערוץ ההפצה (asm-managed,‏ asm-managed-stable או asm-managed-rapid).

  2. מריצים את הפקודה הבאה כדי להציג את ה-configmap:

     kubectl get configmap istio-release-channel -n istio-system -o yaml
    
  3. כדי לוודא שיומן הגישה מופעל, צריך לוודא שהשורה accessLogFile: /dev/stdout מופיעה בקטע mesh:.

    ...
    apiVersion: v1
    data:
      mesh: |
        ....
        accessLogFile: /dev/stdout
    ...
    

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

יומני התנועה מופעלים כברירת מחדל.

בתוך האשכול

יומני הגישה של Envoy

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: "/dev/stdout"

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

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

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

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

התאמה אישית של הפורמט והקידוד של יומן הגישה של Envoy

אתם יכולים להתאים אישית את התוכן והמבנה של יומני הגישה של Envoy שנשלחים לפלט סטנדרטי (/dev/stdout). כך אתם יכולים לכלול שדות ספציפיים לביקורת או לתאימות (כמו סט אלגוריתמים להצפנה של TLS) כדי לבחור בין טקסט פשוט לבין פלט JSON מובנה.

מגבלות

הגדרת הפורמט של יומן הגישה זמינה רק בערוץ ההפצה המהיר.

שדות תצורה

מגדירים את השדות הבאים ב-MeshConfig:

  • ‫accessLogEncoding: מציין את מבנה היומנים, TEXT או JSON. ברירת המחדל היא TEXT.
  • ‫accessLogFormat: מחרוזת הפורמט של יומן הגישה של Envoy או הגדרת JSON (אופציונלי כשבוחרים באפשרות TEXT).

שימוש בתצורה

האופן שבו מחילים את ההגדרות האלה תלוי במישור הבקרה:

‫Traffic Director מנוהל

מעדכנים את ה-ConfigMap של istio-asm-managed-rapid במרחב השמות istio-system (גם אם משתמשים בערוץ אחר ולא בערוץ המהיר). מוסיפים את accessLogEncoding ואת accessLogFormat בשדה mesh.

cat <<EOF | kubectl apply -f -
apiVersion: v1
data:
  mesh: |-
    accessLogFile: /dev/stdout
    accessLogEncoding: JSON
    accessLogFormat: '{"time": "%START_TIME%","code": "%RESPONSE_CODE%","upstream_cluster": "%UPSTREAM_CLUSTER%"}'
kind: ConfigMap
metadata:
  name: istio-asm-managed-rapid
  namespace: istio-system
EOF

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

יומני הגישה של Envoy

שורת הפקודה

כדי להציג את יומני הגישה של Envoy ביומן istio-proxy, מריצים את הפקודה הבאה:

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-proxy

Logs Explorer

כדי לראות את יומני הגישה של Envoy ב-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"

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

כדי לראות את יומני התנועה ב-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"
    

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

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

    כניסה לדף Cloud Service Mesh

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

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

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

  5. בקטע Select a filter option, לוחצים על View traffic logs.

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

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

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

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

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

{
  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"
}

פירוש נתוני הטלמטריה של Cloud Service Mesh

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

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

‫Traffic Director מנוהל

ב-Cloud Service Mesh עם מישור בקרה מנוהל של Traffic Director, אי אפשר להשתמש במדדים של מישור הבקרה.

istiod מנוהל

ב-Cloud Service Mesh עם מישור בקרה מנוהל של istiod, אי אפשר לבדוק את המדדים של מישור הבקרה כמו שמוסבר בקטע הזה.

בתוך האשכול

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

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

  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. למידע נוסף, ראו הצגת מרכז הבקרה המותקן.

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

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

‫Traffic Director מנוהל

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

istiod מנוהל

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

בתוך האשכול

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

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

    kubectl debug --image istio/base --target istio-proxy -it $(kubectl get pod -l app=pilot -o jsonpath='{.items[0].metadata.name}' -n istio-system) -n istio-system -- curl -s
  2. גישה אל localhost:15014 ואל grep עבור convergence במדדים:

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

פירוש של יומני תעבורת נתונים

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

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

  • זרימת התנועה ותקלות
  • ניתוב בקשות מקצה לקצה

כברירת מחדל, יומני התנועה מופעלים בהתקנות של Cloud Service Mesh ב-Google Kubernetes Engine. כדי להפעיל את יומני התנועה, צריך להריץ מחדש את 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, גודל, זמן אחזור וכותרות נפוצות.
  • פרטי עומס העבודה של המקור והיעד, כמו שם, מרחב שמות, זהות ותוויות נפוצות.
  • מידע על השירות הקנוני ועל הגרסה של המקור והיעד.
  • אם המעקב מופעל, היומנים מכילים מידע על המעקב, כמו דגימה, מזהה המעקב ומזהה הטווח.

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

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

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

{
  "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

כדי לפתור בעיות, אתם יכולים להשתמש ביומני הגישה של Envoy כדי להציג את התנועה בין שני הקצוות של החיבור.

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

  • זרימת התנועה ותקלות
  • ניתוב בקשות מקצה לקצה

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

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

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

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

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

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

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

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

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

‫Traffic Director מנוהל

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

istiod מנוהל

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

בתוך האשכול

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

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

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

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

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

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

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

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

הצגת מצבי שקע של שרת proxy

כדי לבדוק ישירות את מצב השקעים של שרת ה-proxy של Envoy, מבצעים את התהליך הבא:

  1. הצגת רשימה של שקעים שנוצרו, כולל שקעים במצב TIME_WAIT, שיכולים להשפיע לרעה על יכולת ההתאמה לעומס (scalability) אם המספר שלהם גבוה:

    kubectl debug --image istio/base --target istio-proxy -it POD_NAME -n NAMESPACE_NAME -- ss -anopim
  2. הצגת סיכום של נתוני שקעים:

    kubectl debug --image istio/base --target istio-proxy -it POD_NAME -n NAMESPACE_NAME -- ss -s

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

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

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

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-proxy

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

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-init

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