פתרון בעיות שקשורות למעקב מבוזר

במאמר הזה מוסבר איך לאבחן ולפתור בעיות ב-distributed tracing כשמשתמשים ב-Cloud Trace ובמדיניות טלמטריה עם Secure Web Proxy.

העקבות לא מופיעים ב-Trace

אם טווחי המעקב שנוצרו על ידי Secure Web Proxy לא מופיעים בכלי לבדיקת מעקב, כדאי לבדוק את הפריטים הבאים:

  1. מוודאים ש-Cloud Trace API מופעל: מוודאים ש-Trace API ‏ (cloudtrace.googleapis.com) מופעל בGoogle Cloud פרויקט שמארח את שער Secure Web Proxy.

    <pre class="devsite-click-to-copy">
gcloud services enable cloudtrace.googleapis.com
</pre>

  2. מוודאים שמדיניות הטלמטריה קיימת ופעילה: משתמשים בפקודה gcloud beta network-services telemetry-policies describe כדי לבדוק שמדיניות הטלמטריה קיימת באזור הנכון ושהיא מפנה לשער המתאים של Secure Web Proxy:

    gcloud beta network-services telemetry-policies describe POLICY_NAME \
    --location=REGION

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫POLICY_NAME: השם של מדיניות הטלמטריה, למשל my-swp-tracing-policy
    • ‫REGION: האזור שבו מדיניות הטלמטריה שלכם נפרסת, למשל us-central1

  3. בודקים את קצב הדגימה: אם הערך של samplingRate במדיניות נמוך (לדוגמה, 0.01 ל-1% או 0.001 ל-0.1%), יכול להיות שבקשות בדיקה ידניות לא יידגמו. כדי לוודא שהמעקב פועל, צריך לעדכן באופן זמני את המדיניות לשימוש ב-100% דגימה (samplingRate: 1.00) ואז לשחזר את קצב הייצור.

  4. אימות ה-URI של משאב שער היעד: מוודאים שבשדה telemetryTarget.resources במדיניות הטלמטריה מצוין ה-URL המדויק של המשאב או השם הקצר של שער Secure Web Proxy.

    //networkservices.googleapis.com/projects/PROJECT_ID/locations/REGION/gateways/GATEWAY_NAME

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud
    • ‫REGION: האזור שבו שער Secure Web Proxy פרוס, למשל us-central1
    • ‫GATEWAY_NAME: השם של מופע שער Secure Web Proxy

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

  5. בדיקת ההרשאות לניהול זהויות וגישה (IAM):

    • כדי להציג טווחים במסוף Google Cloud , צריך לוודא שחשבון המשתמש או חשבון השירות קיבלו את התפקיד Cloud Trace User (roles/cloudtrace.user).
    • מוודאים שהענקתם את התפקיד Cloud Trace Agent‏ (roles/cloudtrace.agent) לחשבונות השירות הבאים:
      • service-PROJECT_NUMBER@compute-system.
      • service-PROJECT_NUMBER@gcp-sa-networksecurity.
      • חשבונות שירות של מכונות וירטואליות (VM) של לקוחות, אם אפליקציות לקוח יוצרות או מעבירות טווחים

חסרים טווחי זמן של ילדים או תרשימי מעקב שבורים

אם טווח ה-proxy של Secure Web Proxy מופיע כשורשים עצמאיים או מנותקים במקום כטווחים צאצאים של בקשות האפליקציה, צריך לבצע את הפעולות הבאות:

  1. הפעלת דגימה מבוססת-הורה: בקובץ ה-YAML של מדיניות הטלמטריה, מוודאים שהערך של parentBasedSampling.enabled מוגדר ל-true.

    tracingConfiguration:
  samplingRate: 0.01
  parentBasedSampling:
    enabled: true

    כשדגימה שמבוססת על הורה מושבתת, יכול להיות ש-Secure Web Proxy ישמיט עקבות שנדגמו במעלה הזרם אם הן לא תואמות ל-samplingRate המקומי.

  2. בדיקת המכשור של OpenTelemetry: מוודאים שהאפליקציה משתמשת ב-SDK של OpenTelemetry שבו מופעלת העברת הקשר של מעקב מבוזר. מידע נוסף זמין במסמכי התיעוד בנושא OpenTelemetry TraceContext propagator.

נפח גבוה באופן לא צפוי של נתוני מעקב

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

  1. הקטנת קצב הדגימה של בסיס הנתונים: בסביבות ייצור עם תנועת גולשים גבוהה, מגדירים את samplingRate לשבר קטן יותר, כמו 0.01 (1%) או 0.001 (0.1%).
  2. להסתמך על דגימה שמבוססת על הורה: חשוב לשמור על ערך הבסיס של השער samplingRate נמוך ולהפעיל את parentBasedSampling. השילוב הזה עוזר לוודא שה-proxy דוגם רק את הבקשות שאפליקציות במעלה הזרם בוחרות באופן ספציפי.
  3. הסרת מדיניות זמנית לניפוי באגים: אם הפעלתם דגימה של 100% (samplingRate: 1.00) במהלך פתרון בעיות, עליכם להסיר את המדיניות או לחזור להגדרה הקודמת אחרי שתהליך ניפוי הבאגים יסתיים.

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