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

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

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

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

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

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

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

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

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

kubectl get services --all-namespaces

כדי לעיין ברשימת השירותים של Kubernetes במרחב שמות ספציפי:

kubectl get services -n YOUR_NAMESPACE

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

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

אימות של קיום פרוקסי מסוג Sidecar והזרקה תקינה שלהם

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

kubectl -n YOUR_NAMESPACE get pods

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

משתמשים ב-EnvoyFilters במרחב השמות istio-system כדי להגדיר טלמטריה. בלי ההגדרה הזו, Cloud Service Mesh לא ידווח על נתונים ל-Google Cloud Observability.

מוודאים שההגדרה של Google Cloud Observability (וההגדרה של חילופי מטא-נתונים) קיימת:

kubectl -n istio-system get envoyfilter

הפלט הצפוי אמור להיראות כך:

NAME                        AGE
metadata-exchange-1.4       13d
metadata-exchange-1.5       13d
stackdriver-filter-1.4      13d
stackdriver-filter-1.5      13d
...

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

kubectl exec YOUR_POD_NAME -n YOUR_NAMESPACE -c istio-proxy 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. כדי לדווח על נתוני טלמטריה, כל קובץ עזר חיצוני שמוזרק ל-Pods של השירות שלכם קורא ל-Cloud Monitoring API ול-Cloud Logging API. אחרי פריסת עומסי עבודה, עוברות בערך דקה או שתיים עד שנתוני הטלמטריה מוצגים בGoogle Cloud מסוף. ‫Cloud Service Mesh מעדכן אוטומטית את לוחות הבקרה של השירותים:

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

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

kubectl get pod -n YOUR_NAMESPACE --all

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

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