‫Anthos Service Mesh ו-Traffic Director נקראים עכשיו Cloud Service Mesh. מידע נוסף זמין בסקירה הכללית על Cloud Service Mesh.

‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

פתרון בעיות שקשורות לניראות ולטלמטריה ב-Cloud Service Mesh

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

בטלמטריה של Cloud Service Mesh, פרוקסי Envoy קוראים ל-Google Cloud Observability APIs באופן תקופתי כדי לדווח על נתוני טלמטריה. התדירות של קריאה ל-API תלויה בסוג שלה:

רישום ביומן: כל 10 שניות בערך
מדדים: כל דקה בערך
קצוות (Context API/תצוגת טופולוגיה): דוחות מצטברים כל דקה בערך, עם דוחות מלאים כל 10 דקות בערך.
עקבות: נקבעים לפי תדירות הדגימה שהגדרתם (בדרך כלל, אחת מכל 100 בקשות).

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

מוודאים שיש לכם לכל היותר הגדרה אחת של Istio Telemetry API

הקטע הזה רלוונטי רק למישור בקרה מנוהל של Traffic Director.

אם כבר יש לכם CR של Istio telemetry API, כדי לשמור את הגדרות ההתאמה האישית הקודמות ב-CR הקיים של Istio telemetry, אתם צריכים לכלול אותן ב-CR החדש של Istio telemetry API.

כדי להציג את הגדרות ה-API של הטלמטריה, מריצים את הפקודה הבאה. מוודאים שיש לכל היותר הגדרה אחת של Istio telemetry API.

kubectl -n istio-system get telemetry

שירות חסר בלוח הבקרה של השירותים

בלוח הבקרה מוצגים רק שירותי HTTP(S)/gRPC. אם השירות שלכם אמור להופיע ברשימה, צריך לוודא שהטלמטריה של Cloud Service Mesh מזהה אותו כשירות HTTP.

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

מעיינים ברשימה של כל שירותי Kubernetes:
```
kubectl get services --all-namespaces
```
כדי לעיין ברשימת השירותים של Kubernetes במרחב שמות ספציפי:
```
kubectl get services -n YOUR_NAMESPACE
```

מדדים חסרים או שגויים לגבי שירותים

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

מוודאים שקיימים שרתי proxy מסוג Sidecar ושבוצעה הזרקה שלהם בצורה תקינה

יכול להיות שאין למרחב השמות תווית להוספה אוטומטית, או שההוספה הידנית נכשלה. מוודאים שלפודים במרחב השמות יש לפחות שני קונטיינרים, ואחד מהם הוא קונטיינר istio-proxy:

kubectl -n YOUR_NAMESPACE get pods

בדיקה שקיימת הגדרת טלמטריה

כדי לוודא שהמסנן Google Cloud Observability מוגדר, צריך לאסוף dump של ההגדרות מכל שרת proxy ולחפש את המסנן Google Cloud Observability:

kubectl debug --image istio/base --target istio-proxy -it YOUR_POD_NAME -n YOUR_NAMESPACE curl localhost:15000/config_dump

בפלט של הפקודה הקודמת, מחפשים את המסנן Google Cloud Observability, שנראה כך:

"config": {
    "root_id": "stackdriver_inbound",
    "vm_config": {
        "vm_id": "stackdriver_inbound",
        "runtime": "envoy.wasm.runtime.null",
        "code": {
            "local": {
                "inline_string": "envoy.wasm.null.stackdriver"
             }
         }
     },
     "configuration": "{....}"
}

אימות ש-Cloud Service Mesh מזהה שירות HTTP

מדדים לא יוצגו בממשק המשתמש אם יציאת השירות של שירות Kubernetes לא נקראת http או שם כלשהו עם הקידומת http-. מוודאים שלשירות יש את השמות הנכונים של היציאות שלו.

מוודאים ש-Cloud Monitoring API מופעל בפרויקט

מוודאים ש-Cloud Monitoring API מופעל במרכז הבקרה של השירותים וממשקי ה-API במסוףGoogle Cloud , שמוגדר כברירת מחדל.

אימות שלא מדווחות שגיאות ל-Cloud Monitoring API

במרכז הבקרה של השירותים וממשקי ה-API במסוף Google Cloud , פותחים את כתובת ה-URL של הגרף Traffic By Response Code (תנועה לפי קוד תגובה):

https://console.cloud.google.com/apis/api/monitoring.googleapis.com/metrics?folder=&organizationId=&project=YOUR_PROJECT_ID

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

אימות המכסה הנכונה ל-Cloud Monitoring API

במסוף Google Cloud , פותחים את התפריט IAM & Admin ומוודאים שיש אפשרות Quotas. אפשר לגשת ישירות לדף הזה באמצעות כתובת ה-URL:

https://console.cloud.google.com/iam-admin/quotas?project=YOUR_PROJECT_ID

בדף הזה מוצגות כל המכסות של הפרויקט, ואפשר לחפש Cloud Monitoring API.

אימות שלא קיימים יומני שגיאות ב-Envoy proxies

בודקים את היומנים של ה-proxy הרלוונטי ומחפשים מקרים של הודעות שגיאה:

kubectl -n YOUR_NAMESPACE logs YOUR_POD_NAME -c istio-proxy

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

[warning][filter] [src/envoy/http/authn/http_filter_factory.cc:83]
mTLS PERMISSIVE mode is used, connection can be either plaintext or TLS,
and client cert can be omitted. Please consider to upgrade to mTLS STRICT mode
for more secure configuration that only allows TLS connection with client cert.
See https://istio.io/docs/tasks/security/mtls-migration/ [warning][config]
[bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91]
gRPC config stream closed: 13

מוודאים שההגדרה של `metric.mesh_uid` נכונה

פותחים את Metrics Explorer ומריצים את שאילתת ה-MQL הבאה:

fetch istio_canonical_service
| metric 'istio.io/service/server/request_count'
| align delta(1m)
| every 1m
| group_by [metric.destination_canonical_service_namespace, metric.destination_canonical_service_name, metric.mesh_uid]

מוודאים שכל השירותים הצפויים מדווחים על מדדים, ושערך metric.mesh_uid שלהם הוא בפורמט proj-<Cloud Service Mesh fleet project number>.

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

נתוני טלמטריה חסרים או שגויים לגבי שירותים

כברירת מחדל, שירותי Cloud Monitoring ו-Cloud Logging מופעלים בGoogle Cloud פרויקט כשמתקינים את Cloud Service Mesh. כדי לדווח על נתוני טלמטריה, כל פרוקסי מסוג sidecar שמוזרק ל-pods של השירות שלכם קורא ל-Cloud Monitoring API ול-Cloud Logging API. אחרי פריסת עומסי עבודה, נתוני הטלמטריה מוצגים במסוףGoogle Cloud תוך דקה או שתיים. ‫Cloud Service Mesh מעדכן אוטומטית את לוחות הבקרה של השירותים:

לגבי מדדים, פרוקסי ה-sidecar קוראים ל-Cloud Monitoring API בערך כל דקה.
כדי לעדכן את גרף הטופולוגיה, פרוקסי ה-sidecar שולחים דוחות מצטברים בערך כל דקה ודוחות מלאים בערך כל עשר דקות.
לצורך רישום ביומן, פרוקסי ה-sidecar מפעילים את Cloud Logging API בערך כל עשר שניות.
כדי להשתמש ב-Trace, צריך להפעיל את Cloud Trace. הנתונים של העקבות מדווחים בהתאם לתדירות הדגימה שהגדרתם (בדרך כלל, אחת מכל 100 בקשות).

המדדים מוצגים רק לשירותי HTTP בדף 'מדדים' ב-Cloud Service Mesh. אם לא מופיעים מדדים, צריך לוודא שכל ה-pods במרחב השמות של שירותי האפליקציה כוללים sidecar proxies:

kubectl get pod -n YOUR_NAMESPACE --all

בפלט, שימו לב שבעמודה READY מוצגים שני קונטיינרים לכל אחד מעומסי העבודה: הקונטיינר הראשי והקונטיינר של ה-sidecar proxy.

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