רישום ביומן ומעקב אחרי מאזן עומסים גלובלי חיצוני של אפליקציות (ALB)

במאמר הזה מוסבר איך להגדיר ולהשתמש ב-Cloud Logging וב-Cloud Monitoring עם מאזני עומסים של אפליקציות (ALB) בגרסה הקלאסית, מאזני עומסים גלובליים חיצוניים של אפליקציות ו-Cloud CDN.

רישום ביומן

אתם יכולים להפעיל, להשבית ולראות יומנים של שירות לקצה העורפי של מאזן עומסים של אפליקציות חיצוני. במאזני עומסים חיצוניים של אפליקציות עם backend buckets, הרישום ביומן מופעל אוטומטית ואי אפשר להשבית אותו.

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

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

דגימה ואיסוף של יומנים

מתבצעת דגימה של הבקשות והתגובות התואמות שמטופלות על ידי מכונות וירטואליות (VM) בעורף של מאזן העומסים. לאחר מכן, המערכת מעבדת את הבקשות האלה עם הדגימה כדי ליצור יומנים. אתם קובעים את החלק היחסי של הבקשות שמוצגות כרשומות ביומן בהתאם לשדה logConfig.sampleRate. אם הערך של logConfig.sampleRate הוא 1.0 (100%), המשמעות היא שיומנים נוצרים עבור כל הבקשות ונכתבים ב-Cloud Logging.

שדות אופציונליים

רשומות ביומן מכילות שדות חובה ושדות אופציונליים. בקטע What is logged (מה נרשם ביומן) מפורטים השדות האופציונליים ושדות החובה. כל שדות החובה תמיד כלולים. אתם יכולים לבחור אילו שדות אופציונליים להשאיר.

  • אם בוחרים באפשרות include all optional, כל השדות האופציונליים בפורמט של רשומת היומן נכללים ביומנים. כשנוספים שדות חדשים אופציונליים לפורמט הרשומה, היומנים כוללים אוטומטית את השדות החדשים.

  • אם בוחרים באפשרות exclude all optional (החרגת כל השדות האופציונליים), כל השדות האופציונליים מושמטים.

  • אם בוחרים באפשרות מותאם אישית, אפשר לציין את השדות האופציונליים שרוצים לכלול, כמו tls.protocol,tls.cipher,orcaLoadReport.cpu_utilization,orcaLoadReport.mem_utilization.

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

הפעלת רישום ביומן בשירות חדש לקצה העורפי

המסוף

  1. נכנסים לדף Load Balancing במסוף Google Cloud .

    כניסה לדף Load balancing

  2. לוחצים על השם של מאזן העומסים.

  3. לוחצים על עריכה.

  4. לוחצים על Backend Configuration (הגדרת ה-Backend).

  5. בוחרים באפשרות יצירת שירות לקצה העורפי.

  6. ממלאים את שדות החובה של שירות ה-Backend.

  7. בקטע Logging, מסמנים את התיבה Enable logging.

  8. מגדירים שבר Sample rate. אפשר להגדיר מספר מ-0.0 עד 1.0, כאשר 0.0 אומר שלא מתבצעת רישום של בקשות ו-1.0 אומר שמתבצע רישום של 100% מהבקשות. ערך ברירת המחדל הוא 1.0.

  9. אופציונלי: כדי לכלול את כל השדות האופציונליים ביומנים, בקטע Optional fields (שדות אופציונליים), לוחצים על Include all optional fields (כלול את כל השדות האופציונליים).

  10. כדי לסיים את העריכה של שירות לקצה העורפי, לוחצים על עדכון.

  11. כדי לסיים את העריכה של מאזן העומסים, לוחצים על Update (עדכון).

gcloud

יוצרים שירות לקצה העורפי ומפעילים את הרישום ביומן באמצעות הפקודה gcloud compute backend-services create.

gcloud compute backend-services create BACKEND_SERVICE \
    --global \
    --enable-logging \
    --logging-sample-rate=VALUE \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --logging-optional=LOGGING_OPTIONAL_MODE \
    --logging-optional-fields=OPTIONAL_FIELDS

הפקודה gcloud compute backend-services create תומכת בשדות הבאים:

  • --global מציין שהשירות לקצה העורפי הוא גלובלי. משתמשים בשדה הזה לשירותי בק-אנד שמשמשים עם מאזני עומסים גלובליים חיצוניים של אפליקציות.
  • --enable-logging מאפשר רישום ביומן עבור שירות הקצה העורפי הזה.
  • --logging-sample-rate מאפשר לציין ערך מ-0.0 עד 1.0, כאשר 0.0 אומר שלא מתבצעת רישום של בקשות ו-1.0 אומר שמתבצעת רישום של 100% מהבקשות. השדה הזה רלוונטי רק לפרמטר --enable-logging. הפעלת הרישום אבל הגדרת קצב הדגימה ל-0.0 שווה להשבתת הרישום. ערך ברירת המחדל הוא 1.0.
  • --logging-optional מאפשר לכם לציין את השדות האופציונליים שאתם רוצים לכלול ביומנים. השדות האלה נתמכים רק במאזני עומסים חיצוניים גלובליים של אפליקציות (ALB).

    • INCLUDE_ALL_OPTIONAL כדי לכלול את כל השדות האופציונליים.

    • EXCLUDE_ALL_OPTIONAL (ברירת מחדל) כדי לא לכלול את כל השדות האופציונליים.

    • CUSTOM כדי לכלול רשימה מותאמת אישית של שדות אופציונליים שצוינו ב-OPTIONAL_FIELDS.

  • --logging-optional-fields: רשימה מופרדת בפסיקים של שדות אופציונליים שרוצים לכלול ביומנים.

    לדוגמה, אפשר להגדיר את tls.protocol,tls.cipher רק אם LOGGING_OPTIONAL_MODE מוגדר לערך CUSTOM. אם אתם משתמשים במדדים מותאמים אישית ורוצים לרשום ביומן רכיבים של דוח הטעינה של ORCA, צריך להגדיר את LOGGING_OPTIONAL_MODE ל-CUSTOM ולציין אילו רכיבים צריך לרשום ביומן בשדה OPTIONAL_FIELDS. לדוגמה, orcaLoadReport.cpu_utilization,orcaLoadReport.mem_utilization.

הפעלת רישום ביומן בשירות קיים לקצה העורפי

המסוף

  1. נכנסים לדף Load Balancing במסוף Google Cloud .

    כניסה לדף Load balancing

  2. לוחצים על השם של מאזן העומסים.

  3. לוחצים על עריכה.

  4. לוחצים על Backend Configuration (הגדרת ה-Backend).

  5. לוחצים על עריכה לצד שירות ה-Backend.

  6. בקטע Logging, מסמנים את התיבה Enable logging.

  7. בשדה שיעור הדגימה, מגדירים את הסתברות הדגימה. אפשר להגדיר מספר בין 0.0 ל-1.0, כאשר 0.0 מציין שלא מתבצעת רישום ביומן של אף בקשה ו-1.0 מציין שמתבצע רישום ביומן של 100% מהבקשות. ערך ברירת המחדל הוא 1.0.

  8. אופציונלי: כדי לכלול את כל השדות האופציונליים ביומנים, בקטע Optional fields (שדות אופציונליים), לוחצים על Include all optional fields (כלול את כל השדות האופציונליים).

  9. כדי לסיים את העריכה של שירות לקצה העורפי, לוחצים על עדכון.

  10. כדי לסיים את העריכה של מאזן העומסים, לוחצים על Update (עדכון).

gcloud

מפעילים רישום ביומן בשירות קיים לקצה העורפי באמצעות הפקודה gcloud compute backend-services update.

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --enable-logging \
    --logging-sample-rate=VALUE \
    --logging-optional=LOGGING_OPTIONAL_MODE \
    --logging-optional-fields=OPTIONAL_FIELDS

איפה

  • --global מציין שהשירות לקצה העורפי הוא גלובלי. משתמשים בשדה הזה לשירותי בק-אנד שמשמשים עם מאזני עומסים גלובליים חיצוניים של אפליקציות.
  • --enable-logging מאפשר רישום ביומן עבור שירות הקצה העורפי הזה.
  • --logging-sample-rate מאפשר לציין ערך מ-0.0 עד 1.0, כאשר 0.0 אומר שלא מתבצעת רישום של בקשות ו-1.0 אומר שמתבצע רישום של 100% מהבקשות. הפרמטר הזה רלוונטי רק עם הפרמטר --enable-logging. הפעלת הרישום ביומן אבל הגדרת קצב הדגימה ל-0.0 שווה להשבתת הרישום ביומן. ערך ברירת המחדל הוא 1.0.
  • --logging-optional מאפשר לכם לציין את השדות האופציונליים שאתם רוצים לכלול ביומנים. השדות האלה נתמכים רק במאזני עומסים חיצוניים גלובליים של אפליקציות (ALB).

    • INCLUDE_ALL_OPTIONAL כדי לכלול את כל השדות האופציונליים.

    • EXCLUDE_ALL_OPTIONAL (ברירת מחדל) כדי להחריג את כל השדות האופציונליים.

    • CUSTOM כדי לכלול רשימה מותאמת אישית של שדות אופציונליים שצוינו ב-OPTIONAL_FIELDS.

  • --logging-optional-fields: רשימה מופרדת בפסיקים של שדות אופציונליים שרוצים לכלול ביומנים.

    לדוגמה, tls.protocol,tls.cipher. אפשר להגדיר את ההגדרה הזו רק אם ההגדרה של LOGGING_OPTIONAL_MODE היא CUSTOM. אם אתם משתמשים במדדים מותאמים אישית ורוצים לרשום ביומן רכיבים של דוח הטעינה של ORCA, צריך להגדיר את LOGGING_OPTIONAL_MODE ל-CUSTOM ולציין אילו רכיבים צריך לרשום ביומן בשדה OPTIONAL_FIELDS. לדוגמה, orcaLoadReport.cpu_utilization,orcaLoadReport.mem_utilization.

השבתה או שינוי של רישום ביומן בשירות קיים של קצה עורפי

המסוף

  1. נכנסים לדף Load Balancing במסוף Google Cloud .

    כניסה לדף Load balancing

  2. לוחצים על השם של מאזן העומסים.

  3. לוחצים על עריכה.

  4. לוחצים על Backend Configuration (הגדרת ה-Backend).

  5. לוחצים על עריכה לצד שירות ה-Backend.

  6. כדי להשבית את הרישום ביומן לחלוטין, בקטע Logging, מבטלים את הסימון בתיבה Enable logging.

  7. אם משאירים את האפשרות 'רישום ביומן' מופעלת, אפשר להגדיר שבר אחר של שיעור הדגימה. אפשר להגדיר מספר מ-0.0 עד 1.0, כאשר 0.0 מציין שלא מתבצעת רישום של בקשות, ו-1.0 מציין שמתבצע רישום של 100% מהבקשות. ערך ברירת המחדל הוא 1.0. לדוגמה, 0.2 אומר ש-20% מהבקשות שנדגמו יוצרות יומנים.

  8. כדי לסיים את העריכה של שירות לקצה העורפי, לוחצים על עדכון.

  9. כדי לסיים את העריכה של מאזן העומסים, לוחצים על Update (עדכון).

‫gcloud: מצב גלובלי

משביתים את הרישום ביומן בשירות קצה עורפי באמצעות הפקודה gcloud compute backend-services update.

השבתה מלאה של רישום ביומן

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --no-enable-logging

איפה

  • --global מציין שהשירות לקצה העורפי הוא גלובלי. משתמשים בשדה הזה לשירותי בק-אנד שמשמשים עם מאזני עומסים גלובליים חיצוניים של אפליקציות.
  • --no-enable-logging משבית את הרישום ביומן עבור שירות הקצה העורפי הזה.

הפעלת שדות אופציונליים ביומן בשירות קיים של קצה עורפי

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --enable-logging \
    --logging-sample-rate=VALUE \
    --logging-optional=LOGGING_OPTIONAL_MODE \
    --logging-optional-fields=OPTIONAL_FIELDS

איפה

  • --logging-sample-rate מאפשר לציין ערך מ-0.0 עד 1.0, כאשר 0.0 אומר שלא מתבצעת רישום של בקשות ו-1.0 אומר שמתבצע רישום של 100% מהבקשות. הפרמטר הזה רלוונטי רק עם הפרמטר --enable-logging. הפעלת הרישום ביומן אבל הגדרת קצב הדגימה ל-0.0 שווה להשבתת הרישום ביומן. ערך ברירת המחדל הוא 1.0.
  • --logging-optional מאפשרת לכם לציין את השדות האופציונליים שאתם רוצים לכלול ביומנים:

    • INCLUDE_ALL_OPTIONAL כדי לכלול את כל השדות האופציונליים.

    • EXCLUDE_ALL_OPTIONAL (ברירת מחדל) כדי לא לכלול את כל השדות האופציונליים.

    • CUSTOM כדי לכלול רשימה מותאמת אישית של שדות אופציונליים שצוינו ב-OPTIONAL_FIELDS.

  • --logging-optional-fields: רשימה מופרדת בפסיקים של שדות אופציונליים שרוצים לכלול ביומנים.

    לדוגמה, אפשר להגדיר את tls.protocol,tls.cipher רק אם LOGGING_OPTIONAL_MODE מוגדר לערך CUSTOM. אם אתם משתמשים במדדים מותאמים אישית ורוצים לרשום ביומן רכיבים של דוח הטעינה של ORCA, צריך להגדיר את LOGGING_OPTIONAL_MODE ל-CUSTOM ולציין אילו רכיבים צריך לרשום ביומן בשדה OPTIONAL_FIELDS. לדוגמה, orcaLoadReport.cpu_utilization,orcaLoadReport.mem_utilization.

עדכון מצב אופציונלי של רישום ביומן מ-CUSTOM למצבים אחרים

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --enable-logging \
    --logging-sample-rate=VALUE \
    --logging-optional=LOGGING_OPTIONAL_MODE \
    --logging-optional-fields=

איפה

  • --logging-optional מאפשרת לכם לציין את השדות האופציונליים שאתם רוצים לכלול ביומנים:

    • INCLUDE_ALL_OPTIONAL כדי לכלול את כל השדות האופציונליים.

    • EXCLUDE_ALL_OPTIONAL (ברירת מחדל) כדי לא לכלול את כל השדות האופציונליים.

  • צריך להגדיר את --logging-optional-fields באופן מפורש כמו שמוצג כדי לנקות את השדות הקיימים של CUSTOM. ה-API לא מאפשר לשלב מצב שאינו CUSTOM עם שדות CUSTOM.

שינוי קצב הדגימה של הרישום ביומן

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --logging-sample-rate=VALUE

‫gcloud: מצב קלאסי

משביתים את הרישום ביומן בשירות קצה עורפי באמצעות הפקודה gcloud compute backend-services update.

השבתה מלאה של רישום ביומן

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --no-enable-logging

איפה

  • --global מציין שהשירות לקצה העורפי הוא גלובלי. משתמשים בשדה הזה לשירותים לקצה העורפי שמשמשים עם מאזן עומסים של אפליקציות (ALB) מהגרסה הקלאסית.
  • --no-enable-logging משבית את הרישום ביומן עבור שירות הקצה העורפי הזה.

שינוי קצב הדגימה של הרישום ביומן

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --logging-sample-rate=VALUE

איפה

  • --global מציין שהשירות לקצה העורפי הוא גלובלי. משתמשים בשדה הזה לשירותים לקצה העורפי שמשמשים עם מאזן עומסים של אפליקציות (ALB) מהגרסה הקלאסית.
  • --logging-sample-rate מאפשר לציין ערך מ-0.0 עד 1.0, כאשר 0.0 אומר שלא מתבצעת רישום של בקשות ו-1.0 אומר שמתבצע רישום של 100% מהבקשות. הפרמטר הזה רלוונטי רק עם הפרמטר --enable-logging. הפעלת הרישום ביומן אבל הגדרת קצב הדגימה ל-0.0 שווה להשבתת הרישום ביומן.

צפייה ביומנים


לחצו על תראו לי איך כדי לקרוא הסבר מפורט על המשימה ישירות במסוף Google Cloud :

תראו לי איך


יומני HTTP(S) עוברים אינדוקס קודם על ידי כלל העברה ואז על ידי מפת URL.

כדי לראות את היומנים, עוברים לדף Logs Explorer:

כניסה לדף Logs Explorer

  • כדי לראות את כל היומנים, בתפריט המסננים Resource, בוחרים באפשרות Application Load Balancer > All forwarding_rule_name.
  • כדי להציג יומנים של כלל העברה אחד, בוחרים שם של כלל העברה אחד.

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

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

קידוד UTF-8 חל על שדות היומן. תווים שאינם תווים בפורמט UTF-8 מוחלפים בסימני שאלה. במאזני עומסים קלאסיים של אפליקציות ובמאזני עומסים גלובליים חיצוניים של אפליקציות, אפשר לייצא מדדים שמבוססים על יומנים באמצעות יומני משאבים (resource.type="http_load_balancer"). המדדים שנוצרים מבוססים על משאב Application Load Balancer Rule (Logs-based Metrics) (l7_lb_rule), שזמין בלוחות הבקרה של Cloud Monitoring ולא במשאב https_lb_rule.

מה נרשם ביומן

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

רשומות ביומן מכילות שדות אופציונליים שמוסיפים מידע נוסף על תעבורת ה-HTTP(S). אפשר להשמיט שדות אופציונליים כדי לחסוך בעלויות האחסון.

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

שדה פורמט השדה סוג השדה: חובה או אופציונלי תיאור
severity
insertID
logName
LogEntry חובה השדות הכלליים כפי שמתואר ברשומה ביומן.
חותמת זמן מחרוזת (פורמט Timestamp) אופציונלי השעה שבה השכבה הראשונה של GFE מקבלת את הבקשה.
httpRequest HttpRequest חובה פרוטוקול נפוץ לרישום בקשות HTTP.

המאפיין HttpRequest.protocol לא מאוכלס עבור resource.type="http_load_balancer".

resource MonitoredResource חובה

MonitoredResource הוא סוג המשאב שמשויך לרשומה ביומן.

MonitoredResourceDescriptor מתאר את הסכימה של אובייקט MonitoredResource באמצעות שם סוג וקבוצה של תוויות. מידע נוסף זמין במאמר תוויות משאבים.

jsonPayload אובייקט (פורמט Struct) חובה המטען הייעודי של רשומה ביומן, שמוצג כאובייקט JSON. אובייקט ה-JSON כולל את השדות הבאים:
  • statusDetails
  • backendTargetProjectNumber
  • cachePolicySource
  • overrideResponseCode
  • errorService
  • errorBackendStatusDetails
  • authzPolicyInfo
  • loadBalancingScheme
  • tls
  • serviceExtensionInfo
  • orcaLoadReport
מחרוזת חובה השדה statusDetails מכיל מחרוזת שמסבירה למה מאזן העומסים החזיר את קוד הסטטוס של HTTP. מידע נוסף על מחרוזות היומן האלה זמין במאמרים בנושא הודעות הצלחה של HTTP ב-statusDetails והודעות שגיאה של HTTP ב-statusDetails.
מחרוזת חובה בשדה backendTargetProjectNumber מופיע מספר הפרויקט שבו נוצר יעד הקצה העורפי – שירות קצה עורפי או קטגוריית קצה עורפי. הפורמט של השדה הזה הוא: "projects/PROJECT_NUMBER". המידע הזה זמין רק למאזני עומסים גלובליים חיצוניים של אפליקציות שמשתמשים בתשובות שגיאה מותאמות אישית.
מחרוזת אופציונלי השדה cachePolicySource מכיל את המקור של מדיניות הקאשינג שקובעת את התנהגות הקאשינג עבור בקשה ספציפית:

CACHE_POLICY_SOURCE_ROUTE: אפשר להחיל מדיניות מטמון ברמות שונות של מפת URL, וכך לקבל שליטה מפורטת יותר על שמירת נתונים במטמון.

CACHE_POLICY_SOURCE_BACKEND: התנהגות השמירה במטמון שנקבעה על ידי הגדרת Cloud CDN בשירות הקצה העורפי או בקטגוריה.

מספר שלם חובה השדה overrideResponseCode מכיל את קוד התגובה שמוחל על התגובה שנשלחת ללקוח. המידע הזה זמין רק למאזני עומסים גלובליים חיצוניים של אפליקציות שמשתמשים בתשובות שגיאה מותאמות אישית.
מחרוזת חובה השדה errorService מכיל את שירות הקצה העורפי שסיפק את תגובת השגיאה המותאמת אישית. המידע הזה זמין רק למאזני עומסים גלובליים חיצוניים של אפליקציות שמשתמשים בתשובות שגיאה מותאמות אישית.
מחרוזת חובה השדה errorBackendStatusDetails מכיל את statusDetails של התשובה הסופית שמוצגת ללקוח. המידע הזה זמין רק למאזני עומסים גלובליים חיצוניים של אפליקציות שמשתמשים בתשובות שגיאה מותאמות אישית.
AuthzPolicyInfo חובה בשדה authzPolicyInfo מאוחסן מידע על התוצאה של מדיניות ההרשאות. המידע הזה זמין רק למאזני עומסים חיצוניים גלובליים של אפליקציות שבהם מופעלות מדיניות הרשאות. מידע נוסף זמין במאמר בנושא מה נרשם ביומן לגבי מדיניות הרשאות.
מחרוזת אופציונלי השדה loadBalancingScheme מאוכלס רק אם משתמשים בתכונה להעברה של מאזן עומסים קלאסי של אפליקציות. השדה הזה מכיל מחרוזת שמתארת את סכמת איזון העומסים ששימשה לניתוב הבקשה. הערכים האפשריים הם EXTERNAL או EXTERNAL_MANAGED.
TlsInfo חובה

השדה tls מכיל את השדה TlsInfo שמציין את מטא-נתוני ה-TLS של החיבור בין הלקוח למאזן העומסים. השדה הזה זמין רק לחיבורים מוצלחים שבהם הלקוח משתמש בהצפנת TLS/SSL. לחיצות יד של TLS שנכשלו לא נרשמות ביומן.

משתמשים בפרמטר --logging-optional-fields כדי לציין אילו רכיבים צריך לתעד:

  • tls.protocol (אופציונלי)
  • tls.cipher (אופציונלי)
  • חובה: tls.earlyDataRequest

אי אפשר להגדיר את --logging-optional-fields ל-tls כדי לציין את כל הרכיבים.

OrcaLoadReport אופציונלי

השדה orcaLoadReport מכיל חלק מהאלמנטים של דוח הטעינה של ORCA שהוחזר על ידי ה-backend, או את כולם. השדה הזה מוצג רק אם ה-backend מחזיר דוח עומס של ORCA והגדרתם את מאזן העומסים כך שיתעד את דוח העומס של ORCA.

משתמשים בפרמטר --logging-optional-fields כדי לציין אילו מהרכיבים הבאים של דוח העומס של ORCA צריכים להיכלל ביומן:

  • orcaLoadReport.cpu_utilization
  • orcaLoadReport.mem_utilization
  • orcaLoadReport.request_cost
  • orcaLoadReport.utilization
  • orcaLoadReport.rps_fractional
  • orcaLoadReport.eps
  • orcaLoadReport.named_metrics
  • orcaLoadReport.application_utilization

אפשר גם להגדיר את --logging-optional-fields לערך orcaLoadReport כדי לציין שצריך לרשום ביומן את כל הרכיבים.

serviceExtensionInfo אופציונלי

בשדה serviceExtensionInfo מאוחסן מידע על זרמי gRPC ממאזן העומסים ל-Service Extensions. מידע נוסף זמין במאמר בנושא מה נרשם ביומן לגבי תוספים.

אם הפעלתם את שער Google Tag במאזן העומסים, המאגר jsonPayload יכיל ערכים ספציפיים להחדרת תגים ולניתוב מדידה, כמו מאגר תגים serviceExtensionInfo.backend_target_name של google-tag-gateway-tag-injector.

משתמשים בפרמטר --logging-optional-fields כדי לציין אילו מהרכיבים הבאים צריך לתעד:

  • serviceExtensionInfo.backendTargetName
  • serviceExtensionInfo.backendTargetType
  • serviceExtensionInfo.extension
  • serviceExtensionInfo.perProcessingRequestInfo
  • serviceExtensionInfo.perProcessingRequestInfo.eventType
  • serviceExtensionInfo.perProcessingRequestInfo.grpcStatus
  • serviceExtensionInfo.perProcessingRequestInfo.latency
  • serviceExtensionInfo.perProcessingRequestInfo.processingEffect.
  • serviceExtensionInfo.resource

אפשר גם להגדיר את --logging-optional-fields לערך serviceExtensionInfo כדי לציין שצריך לרשום ביומן את כל הרכיבים.

פורמט השדה TlsInfo

שדה פורמט השדה סוג השדה: חובה או אופציונלי תיאור
protocol מחרוזת אופציונלי פרוטוקול TLS שהלקוחות משתמשים בו כדי ליצור חיבור עם מאזן העומסים. הערכים האפשריים הם TLSv1,‏ TLSv1.1,‏ TLSv1.2,‏ TLSv1.3 או QUIC. הערך הזה מוגדר כ-NULL אם הלקוח לא משתמש בהצפנת TLS/SSL.
cipher מחרוזת אופציונלי צופן TLS שבו הלקוחות משתמשים כדי ליצור חיבור למאזן העומסים. הערך הזה מוגדר ל-NULL אם הלקוח לא משתמש ב-HTTP(S) או אם הלקוח לא משתמש בהצפנת TLS/SSL.
earlyDataRequest בוליאני חובה הבקשה כוללת נתונים מוקדמים בלחיצת היד של TLS.

הפורמט של השדה serviceExtensionInfo

שדה פורמט השדה סוג השדה: חובה או אופציונלי תיאור
backendTargetName מחרוזת אופציונלי השם של יעד ה-backend של התוסף.
backendTargetType מחרוזת אופציונלי סוג היעד לקצה העורפי.
extension מחרוזת אופציונלי השם של התוסף בשרשרת התוספים. בשער Google Tag, הערך הזה יהיה 0-google-tag-gateway.
perProcessingRequestInfo מערך אופציונלי רשימה של ProcessingRequest נתונים של ext_proc extensions או CheckRequest נתונים של ext_authz extensions שמתרחשים בשידור gRPC.
perProcessingRequestInfo.eventType enum אופציונלי סוג האירוע של ProcessingRequest. השדה הזה יכול להכיל אחד מהערכים הבאים: REQUEST_HEADERS,‏ REQUEST_BODY,‏ RESPONSE_HEADERS או RESPONSE_BODY.
perProcessingRequestInfo.grpcStatus enum אופציונלי סטטוס האירוע של עיבוד הבקשה, שמוצג כקוד סטטוס של gRPC.
perProcessingRequestInfo.latency משך אופציונלי משך הזמן שחל משליחת הבייט הראשון של הודעת ProcessingRequest לתוסף ועד לקבלת הבייט האחרון של הודעת ProcessingResponse.
perProcessingRequestInfo.processingEffect enum אופציונלי

התוצאה של העיבוד לכל אירוע בבקשת עיבוד. השדה הזה יכול לכלול אחד מהערכים הבאים:

  • NONE: מציין שהתוכן לא שונה.
  • CONTENT_MODIFIED: מציין שהתוכן השתנה בעקבות בקשת מוטציה שהוחלה בהצלחה.
  • IMMEDIATE_RESPONSE: מציין שהתוסף שלח תגובה מיידית כדי לעצור את כל העיבוד הנוסף.
resource מחרוזת אופציונלי השם של משאב התוסף. בשער Google Tag, זה יהיה google-tag-gateway-tag-injector-extension.

תוויות משאבים

בטבלה הבאה מפורטות תוויות המשאבים של resource.type="http_load_balancer".

שדה סוג תיאור
backend_service_name מחרוזת השם של שירות הקצה העורפי.
forwarding_rule_name מחרוזת השם של אובייקט כלל ההעברה.
project_id מחרוזת המזהה של Google Cloud הפרויקט שמשויך למשאב הזה.
target_proxy_name מחרוזת השם של אובייקט ה-proxy של היעד שאליו מתייחס כלל ההעברה.
url_map_name מחרוזת השם של אובייקט מיפוי כתובות ה-URL שהוגדר לבחירת שירות קצה עורפי.
zone מחרוזת האזור שבו מאזן העומסים פועל. האזור הוא global.

הודעות הצלחה של HTTP ב-statusDetails

statusDetails (successful) משמעות קודי תגובה נפוצים שמופיעים יחד
byte_range_caching בקשת ה-HTTP מולאה באמצעות שמירת טווח בייטים במטמון ב-Cloud CDN. אפשר להשתמש בכל קוד תגובה שניתן לשמירה במטמון.
response_from_cache בקשת ה-HTTP הוגשה ממטמון של Cloud CDN. אפשר להשתמש בכל קוד תגובה שניתן לשמירה במטמון.
response_from_cache_validated קוד ההחזרה הוגדר מתוך רשומה במטמון של Cloud CDN שאומתה על ידי קצה עורפי. אפשר להשתמש בכל קוד תגובה שניתן לשמירה במטמון.
response_sent_by_backend בקשת ה-HTTP הועברה בהצלחה לשרת העורפי, והתגובה הוחזרה מהשרת העורפי. קוד תגובת HTTP מוגדר על ידי התוכנה שפועלת בקצה העורפי.

הודעות שגיאה של HTTP ב-statusDetails

statusDetails (failure) משמעות קודי סטטוס נפוצים שמצורפים
aborted_request_due_to_backend_early_response בקשה עם גוף בוטלה כי הקצה העורפי שלח תגובה מוקדמת עם קוד סטטוס. התשובה הועברה ללקוח. הבקשה הופסקה. 4XX או 5XX
backend_connection_closed_after_partial_response_sent החיבור לעורף הקצה נסגר באופן בלתי צפוי אחרי שנשלחה תגובה חלקית ללקוח.

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

קוד הסטטוס של HTTP הוא 101 אם החיבור HTTP(S) שודרג לחיבור websocket.

backend_connection_closed_before_data_sent_to_client הקצה העורפי סגר באופן לא צפוי את החיבור שלו למאזן העומסים לפני שהתגובה הועברה באמצעות פרוקסי ללקוח.

‫502, 503

קוד הסטטוס של HTTP הוא 101 אם החיבור ל-HTTP(S) שודרג לחיבור websocket.

backend_early_response_with_non_error_status הקצה העורפי שלח קוד סטטוס ללא שגיאה (1XX או 2XX) לבקשה לפני שקיבל את גוף הבקשה המלא מהלקוח. 502, 503
backend_interim_response_not_supported

הקצה העורפי שלח קוד סטטוס זמני 1XX בתגובה לבקשה של לקוח. אין תמיכה בתגובה זמנית במקרים הבאים:

  • הלקוח משתמש ב-HTTP/0.9 או ב-HTTP/1.0, שלא תומכים בתגובות ביניים של 1XX.
  • הקצה העורפי שלח תגובת 100 Continue לא צפויה. זה יכול לקרות אם הלקוח לא כלל כותרת Expect: 100-continue או אם מאזן העומסים לא מוגדר להעברת 100 Continue.
  • הקצה העורפי שלח תגובה 101 Switching Protocols ללא בקשת שדרוג תקינה מהלקוח.
  • הקצה העורפי שלח קוד סטטוס זמני לא נתמך 1XX, כמו 102 Processing או 103 Early Hints.

502, 503

backend_response_corrupted התוכן של תגובת ה-HTTP שנשלחה מהקצה העורפי מכיל קידוד העברה לא תקין של נתונים בחלקים או שהוא פגום מסיבה אחרת. כל קוד סטטוס אפשרי, בהתאם לאופי השחיתות. לרוב 502, 503.
backend_response_headers_too_long כותרות תגובת HTTP שנשלחו מהקצה העורפי חרגו מהמגבלה המותרת. מידע נוסף זמין בקטע גודל הכותרת של מאזני עומסים חיצוניים באפליקציות. 502, 503
backend_timeout

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

בחיבור websocket:

  • במאזן עומסים חיצוני גלובלי של אפליקציות, קוד סטטוס נוצר כש-GFE סוגר את חיבור ה-WebSocket במצב סרק אחרי שפג הזמן הקצוב לתפוגה של שירות ה-Backend.
  • ב-Application Load Balancer קלאסי, קוד סטטוס נוצר כש-GFE סוגר את חיבור ה-WebSocket במצב סרק או במצב פעיל, אחרי שתם הזמן הקצוב לתפוגה של שירות ה-Backend.

502, 503

קוד הסטטוס של HTTP הוא 101 אם החיבור ל-HTTP(S) שודרג לחיבור websocket.

banned_by_security_policy הבקשה נחסמה על ידי כלל חסימה מבוסס-קצב של Cloud Armor. 429
body_not_allowed הלקוח שלח בקשת HTTP עם גוף, אבל שיטת ה-HTTP שבה נעשה שימוש לא מאפשרת גוף. 400
byte_range_caching_aborted מאזן העומסים קיבל בעבר תגובה שציינה שהמשאב ניתן לשמירה במטמון ותומך בטווחים של בייטים. ‫Cloud CDN קיבל תגובה לא עקבית (לדוגמה, תגובה עם קוד סטטוס שונה מ-206 Partial Content הצפוי). זה קרה כשניסיתם לבצע מילוי של מטמון באמצעות בקשה לטווח בייטים. כתוצאה מכך, מאזן העומסים ביטל את התגובה ללקוח. 2XX
byte_range_caching_forwarded_backend_response מאזן העומסים קיבל בעבר תגובה שציינה שהמשאב ניתן לשמירה במטמון ותומך בטווחים של בייטים. ‫Cloud CDN קיבל תגובה לא עקבית (לדוגמה, תגובה עם קוד סטטוס שונה מ-206 Partial Content הצפוי). זה קרה כשניסיתם לבצע מילוי של מטמון באמצעות בקשה לטווח בייטים. מאזן העומסים העביר את התגובה הלא עקבית ללקוח.

הוחזר מהקצה העורפי – יכול להיות כל קוד סטטוס.

byte_range_caching_retrieval_abandoned הלקוח ביטל בקשה לטווח בייטים או בקשת אימות שיזם Cloud CDN.

הוחזר מהקצה העורפי – יכול להיות כל קוד סטטוס.

byte_range_caching_retrieval_from_backend_failed_after_partial_response בקשה לטווח בייטים או בקשת אימות שהופעלה על ידי Cloud CDN נתקלה בשגיאה. כדי לראות את הסטטוס המפורט של העורף, אפשר לעיין ברשומה המתאימה ביומן של Cloud Logging לבקשה שהופעלה על ידי Cloud CDN. 2XX
cache_lookup_failed_after_partial_response מאזן העומסים לא הצליח להציג תשובה מלאה ממטמון Cloud CDN בגלל שגיאה פנימית. 2XX
cache_lookup_timeout_after_partial_response הזמן הקצוב לתפוגה של זרם החיפוש במטמון של Cloud CDN הסתיים כי הלקוח לא אחזר את התוכן בזמן. 2XX
client_disconnected_after_partial_response החיבור ללקוח נותק אחרי שמאזן העומסים שלח תגובה חלקית.

הוחזר מהקצה העורפי – יכול להיות כל קוד סטטוס.

קוד הסטטוס של HTTP הוא 101 אם החיבור HTTP(S) שודרג לחיבור websocket.

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

0

קוד הסטטוס של HTTP הוא 101 אם החיבור ל-HTTP(S) שודרג לחיבור websocket.

client_timed_out החיבור של הלקוח ל-Google Front End ‏ (GFE) הופסק בגלל חוסר התקדמות בזמן שהבקשה או התגובה הועברו דרך ה-proxy. 0 או 408
client_cert_invalid_rsa_key_size גודל מפתח ה-RSA של אישור עלים או אישור ביניים של לקוח לא היה תקין. מידע נוסף זמין במאמר שגיאות שנרשמו ביומן לגבי חיבורים סגורים. 0
client_cert_unsupported_elliptic_curve_key אישור לקוח או אישור ביניים משתמשים בעקומה אליפטית שלא נתמכת. מידע נוסף זמין במאמר שגיאות שנרשמו ביומן לגבי חיבורים סגורים. 0
client_cert_unsupported_key_algorithm אישור לקוח או אישור ביניים משתמש באלגוריתם שאינו RSA או ECDSA. מידע נוסף זמין במאמר שגיאות שנרשמו ביומן לגבי חיבורים סגורים. 0
client_cert_pki_too_large ל-PKI שמשמש לאימות יש יותר מעשרה אישורים ביניים עם אותו נושא ופרטי מפתח ציבורי של הנושא. מידע נוסף זמין במאמר בנושא שגיאות שמתועדות ביומן עבור חיבורים סגורים. 0
client_cert_chain_max_name_constraints_exceeded באישור ביניים שסופק לצורך אימות היו יותר מעשר מגבלות שם. מידע נוסף זמין במאמר שגיאות שנרשמו ביומן לגבי חיבורים סגורים. 0
client_cert_chain_invalid_eku לאישור הלקוח או למוציא האישור שלו אין שימוש במפתח מורחב (EKU) שכולל את clientAuth. מידע נוסף זמין במאמר שגיאות שנרשמו ביומן לגבי חיבורים סגורים. 0
client_cert_validation_timed_out הזמן הקצוב לאימות שרשרת האישורים חלף. מידע נוסף זמין במאמר שגיאות שנרשמו ביומן לגבי חיבורים סגורים. 0
client_cert_validation_search_limit_exceeded הגעתם למגבלת העומק או האיטרציה במהלך הניסיון לאמת את שרשרת האישורים. מידע נוסף זמין במאמר שגיאות שנרשמו ביומן לגבי חיבורים סגורים. 0
client_cert_validation_not_performed הגדרתם mTLS בלי להגדיר TrustConfig. מידע נוסף זמין במאמר שגיאות שנרשמו ביומן לגבי חיבורים סגורים. 0
client_cert_not_provided הלקוח לא סיפק את האישור המבוקש במהלך הלחיצה. מידע נוסף זמין במאמר שגיאות שנרשמו ביומן לגבי חיבורים סגורים. 0
client_cert_validation_failed אימות אישור הלקוח נכשל עם TrustConfig כשמשתמשים באלגוריתמים לגיבוב כמו MD4,‏ MD5 ו-SHA-1. מידע נוסף זמין במאמר שגיאות שנרשמו ביומן לגבי חיבורים סגורים. 0
direct_response מאזן העומסים ביטל את הבקשה הזו והחזיר תגובה קבועה. יכול להיות שיוצג לכם כל קוד סטטוס של HTTP, בהתאם לאופי הבעיה. לדוגמה, קוד הסטטוס 410 של HTTP מציין שהקצה העורפי לא זמין בגלל איחור בתשלום.
denied_by_security_policy מאזן העומסים דחה את הבקשה הזו בגלל מדיניות האבטחה של Google Cloud Armor. הוגדר במדיניות האבטחה.
error_uncompressing_gzipped_body אירעה שגיאה בביטול הדחיסה של תגובת HTTP דחוסה ב-gzip. 502, 503
failed_parsing_client_headers

בקשות שמשתמשות בשיטות (לדוגמה, GET או POST) שלא תואמות ל-RFC 9110, סעיף 5.6.2 נדחות על ידי ממשק הקצה של Google‏ (GFE) בשכבה הראשונה.

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

400
failed_to_connect_to_backend מאזן העומסים לא הצליח להתחבר לקצה העורפי. זה כולל פסק זמן במהלך שלב החיבור. 502, 503
failed_to_pick_backend מאזן העומסים לא הצליח לבחור קצה עורפי תקין לטיפול בבקשה. 502, 503
failed_to_negotiate_alpn מאזן העומסים והבק-אנד לא הצליחו לנהל משא ומתן על פרוטוקול של שכבת האפליקציה (כמו HTTP/2) כדי לתקשר ביניהם באמצעות TLS. 502, 503
headers_too_long כותרות הבקשות היו גדולות יותר מהגודל המקסימלי המותר. 413
http_version_not_supported אין תמיכה בגרסת ה-HTTP. נתמכים רק הפרוטוקולים HTTP 0.9,‏ 1.0,‏ 1.1 ו-2.0. 400
internal_error שגיאה פנימית במאזן העומסים. בדרך כלל מייצג שגיאה זמנית בתשתית של מאזן העומסים. מנסים להריץ את השאילתה שוב. 4XX או 5XX
invalid_chunk_framing בקשות ותגובות שנשלחות עם הכותרת Transfer-Encoding: Chunked לא עומדות בדרישות של RFC 9112. בהתאם ל-RFC, השדות chunked_body ו-last-chunk חייבים להסתיים ב-CRLF. 400
invalid_external_origin_endpoint ההגדרה של ה-Backend החיצוני לא תקינה. בודקים את ההגדרה של NEG באינטרנט ומוודאים שהיא מציינת שם דומיין מלא (FQDN), כתובת IP ויציאה תקינים. 4XX
invalid_request_headers

הכותרות של בקשת ה-HTTP שהתקבלה מלקוח מכילות לפחות תו אחד שלא מותר לפי מפרט HTTP רלוונטי.

לדוגמה, שמות של שדות בכותרת שכוללים מירכאות כפולות (") או תווים מחוץ לטווח ASCII הרגיל (כלומר, כל בייט >= 0x80) הם לא תקינים.

למידע נוסף:

400
invalid_http2_client_header_format הכותרות של HTTP/2 מלקוח לא תקינות. מידע נוסף זמין במאמר invalid_request_headers. 400
invalid_http2_client_request_path

נתיב הבקשה HTTP/2 מלקוח מכיל לפחות תו אחד שלא מותר לפי מפרט ה-URI.

מידע נוסף זמין במאמר בנושא 3.3. הקטע 'נתיב' של RFC 3986.

400
invalid_http2_request_content_length

הכותרת Content-Length בבקשת HTTP/2 לא תקינה (לדוגמה, היא מכילה תווים לא מספריים, היא שלילית, יש כמה ערכים לא עקביים, או שאורך מטען הייעוד של גוף ההודעה לא תואם לערך בכותרת).

מפרטים מדויקים זמינים בסעיף 8.6 של RFC 9110.

400
multiple_iap_policies אי אפשר לשלב כמה כללי מדיניות של שרת proxy לאימות זהויות (IAP). אם יש לכם מדיניות IAP שמצורפת לשירות קצה עורפי ומדיניות אחרת שמצורפת לאובייקט serverless, צריך להסיר אחת מהמדיניות ולנסות שוב. אובייקטים בלי שרת כוללים את App Engine,‏ Cloud Run ופונקציות Cloud Run. 500
malformed_chunked_body גוף הבקשה לא קודד בצורה תקינה. 411
request_loop_detected מאזן העומסים זיהה לולאת בקשות. יכול להיות שהלולאה הזו נגרמת בגלל הגדרה שגויה שבה הבק-אנד העביר את הבקשה בחזרה למאזן העומסים. 502, 503
required_body_but_no_content_length בקשת ה-HTTP דורשת גוף, אבל כותרות הבקשה לא כוללות כותרת של אורך תוכן או של העברת נתונים בחלקים. 400, 403, 411
retriable_error

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

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

השגיאות האלה הן זמניות במהותן, והן צפויות להיות במסגרת הסכם רמת השירות. עם זאת, אם שיעור השגיאות עולה על 0.01% לאורך תקופה ממושכת, צריך לפנות Google Cloud לתמיכה לקבלת עזרה נוספת.

404, 502, 503
secure_url_rejected התקבלה בקשה עם כתובת URL‏ https:// דרך חיבור HTTP/1.1 לא מוצפן. 400
server_cert_chain_exceeded_limit שרשרת אישורי השרת ארוכה מדי (יותר מ-10 אישורי ביניים כלולים באישור השרת). 502, 503

server_cert_chain_invalid_eku

לאישור השרת יש שדה תוסף Extended Key Usage (EKU), אבל השדה הזה לא כולל את serverAuth.

server_cert_chain_max_name_constraints_exceeded

באישור ביניים שסופק לצורך אימות היו יותר מ-10 מגבלות שם. 502, 503
server_cert_exceeded_size_limit המטען הייעודי (payload) של אישור השרת (כולל אישורי ביניים) גדול מדי (יותר מ-16KB). 503
server_cert_invalid_rsa_key_size

לשרת או לאישור ביניים יש מפתח RSA לא תקין בגודל מסוים.

לא מתבצע אימות.

מפתחות RSA יכולים להיות באורך של 2048 עד 4096 ביט.

503
server_cert_not_provided השרת לא סיפק את האישור המבוקש במהלך הלחיצת יד. 503
server_cert_pki_too_large

תשתית ה-PKI שתשמש לאימות מכילה יותר מעשרה אישורים ביניים שמשותפים להם אותו נושא ופרטי מפתח ציבורי של הנושא.

לא מתבצע אימות.

503
server_cert_trust_config_not_found לא נמצא TrustConfig תואם. 503
server_cert_unsupported_elliptic_curve_key

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

לא מתבצע אימות.

העקומות התקפות הן P-256 ו-P-384.

503
server_cert_unsupported_key_algorithm

שרת או אישור ביניים משתמשים באלגוריתם שאינו RSA או ECDSA.

לא מתבצע אימות.

503
server_cert_validation_internal_error שגיאה פנימית באימות שרשרת האישורים. 503
server_cert_validation_not_performed

הגדרתם mTLS בלי להגדיר משאב TrustConfig.

503
server_cert_validation_search_limit_exceeded

הגעתם למגבלת העומק או האיטרציה בזמן הניסיון לאמת את שרשרת האישורים.

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

503
server_cert_validation_timed_out הזמן הקצוב פג במהלך הניסיון לאמת את שרשרת האישורים. 503
server_cert_validation_unavailable השירות לא יכול לבצע אימות של שרשרת האישורים. 503
ssl_certificate_san_verification_failed מאזן העומסים לא מוצא Subject Alternative Name‏ (SAN) באישור ה-SSL שמוצג על ידי ה-backend שתואם לשם המארח שהוגדר. 502, 503
ssl_certificate_chain_verification_failed אישור ה-SSL שהוצג על ידי ה-backend נכשל באימות של אישור ה-SSL. 502, 503
throttled_by_security_policy הבקשה נחסמה על ידי כלל הגבלת קצב ב-Cloud Armor. 429
unsupported_method הלקוח סיפק שיטת בקשת HTTP שלא נתמכת. 400
unsupported_100_continue בקשת הלקוח כללה את הכותרת 'Expect: 100-continue' בפרוטוקול שלא תומך בה. 400
upgrade_header_rejected בקשת ה-HTTP של הלקוח הכילה את כותרת השדרוג ונדחתה. 400
websocket_closed חיבור ה-WebSocket נסגר. 101
websocket_handshake_failed לחיצת היד של ה-WebSocket נכשלה. כל קוד סטטוס אפשרי בהתאם לאופי הכשל בלחיצת היד.
request_body_too_large גוף בקשת ה-HTTP חרג מהגודל המקסימלי שנתמך על ידי ה-backend. לא רלוונטי לשרתי קצה וירטואליים. 413
handled_by_identity_aware_proxy התשובה הזו נוצרה על ידי IAP במהלך אימות הזהות של הלקוח לפני מתן הגישה.

200, 302, 400, 401, 403, 500, 502, 503

429 (throttled by IAP)

serverless_neg_routing_failed אי אפשר לשלוח את הבקשה ל-NEG ללא שרת. השגיאה הזו יכולה לקרות אם אי אפשר להגיע לאזור שצוין ב-NEG, או אם אי אפשר למצוא את שם המשאב (לדוגמה, השם של פונקציות Cloud Run). 404, 502, 503
fault_filter_abort השגיאה הזו יכולה להתרחש אם הלקוח הגדיר מסנן תקלות ומסנן התקלות הופעל עבור הבקשה הנתונה. הערך צריך להיות בין 200 ל-599.
early_data_rejected

הבקשה שנשלחה בנתונים מוקדמים של TLS הייתה לא חוקית.

מצב כזה יכול לקרות במקרים הבאים, אבל לא רק:

  • הפרמטר TargetHttpsProxy מוגדר ל-TLS early data עם הערך STRICT, אבל הבקשה כללה פרמטרים של שאילתה.
  • הערך של TargetHttpsProxy הוא STRICT או PERMISSIVE, אבל הבקשה השתמשה בשיטת HTTP לא אידמפוטנטית (כמו POST או PUT).
425
service_extension_error

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

יכול להיות שהבעיה הזו מתרחשת אם תוסף ה-Wasm מגיב לאט וחורג מהמגבלה של אלפית השנייה לשליחת התגובה.

425

צפייה ביומנים של אימות אישורי לקוח ל-mTLS

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

שאילתה במסוף

  1. נכנסים לדף Logs Explorer במסוף Google Cloud .

    כניסה לדף Logs Explorer

  2. לוחצים על המתג Show query.

  3. מדביקים את הטקסט הבא בשדה השאילתה. מחליפים את FORWARDING_RULE_NAME בשם של כלל ההעברה.

    jsonPayload.statusDetails=~"client_cert"
    jsonPayload.@type="type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
    resource.labels.forwarding_rule_name=FORWARDING_RULE_NAME
    
  4. לוחצים על Run query.

יומני בקשות של מדיניות הרשאות

אובייקט authz_info במטען הייעודי (payload) של JSON של רשומה ביומן של איזון העומסים מכיל מידע על מדיניות ההרשאות. אתם יכולים להגדיר מדדים מבוססי-יומן לנתוני תנועה שאושרו או נדחו על ידי המדיניות הזו. פרטים נוספים על יומן הרישום של מדיניות ההרשאות

שדה סוג תיאור
authz_info.policies[] אובייקט רשימת כללי המדיניות שתואמים לבקשה.
authz_info.policies[].name מחרוזת השם של מדיניות ההרשאות שתואמת לבקשה.

השם ריק מהסיבות הבאות:

  • אף מדיניות ALLOW לא תואמת לבקשה, והבקשה נדחית.
  • אף מדיניות DENY לא תואמת לבקשה, והבקשה מותרת.
authz_info.policies[].result enum התוצאה יכולה להיות ALLOWED או DENIED.
authz_info.policies[].details מחרוזת הפרטים כוללים את המידע הבא:
  • allowed_as_no_deny_policies_matched_request
  • denied_as_no_allow_policies_matched_request
  • denied_by_authz_extension
  • denied_by_cloud_iap
authz_info.overall_result enum התוצאה יכולה להיות ALLOWED או DENIED.

רישום ביומן לקטגוריות קצה עורפי

הרישום ביומן מופעל באופן אוטומטי למאזני עומסים עם בקטנד מסוג Backend Bucket. אי אפשר לשנות או להשבית את הרישום ביומן עבור קטגוריות של קצה עורפי.

רישום ביומן של Cloud Armor

הטבלה של statusDetail הודעות שגיאה של HTTP מכילה הודעות שרלוונטיות ל-Cloud Armor. מידע נוסף על מה שמתועד ביומנים של Cloud Armor זמין במאמר שימוש ברישום ביומן של בקשות.

רישום ביומן לפריסות של VPC משותף

בדרך כלל, היומנים והמדדים של Application Load Balancer מיוצאים לפרויקט שבו מוגדר כלל ההעברה. לכן, אדמינים של שירותים – בעלים או משתמשים של פרויקטים שבהם נוצר שירות הקצה העורפי – לא יקבלו גישה ליומנים ולמדדים של מאזן העומסים כברירת מחדל. אפשר להשתמש בתפקידים ב-IAM כדי לתת את ההרשאות האלה לאדמינים של שירותים. במאמר הענקת גישה ל-Monitoring מוסבר על התפקידים הזמינים ב-IAM ועל השלבים למתן גישה.

רישום ביומן של שער Google Tag למפרסמים

אם אתם משתמשים בשער Google Tag עם מאזן עומסים גלובלי חיצוני של אפליקציות (ALB), אתם יכולים להשתמש ב-Cloud Logging וב-Cloud Monitoring כדי לאמת את ההגדרה ולאבחן בעיות. ההגדרה מנוהלת באמצעות Google Ads, אבל עיבוד הבקשות והחדרת Google Tag שמתבצעים על ידי השער מתועדים ברישום ביומן ובמעקב אחרי מאזן עומסים גלובלי חיצוני של אפליקציות. מידע נוסף מופיע במאמר רישום נתונים ביומן ומעקב אחרי הביצועים של מאזן עומסים גלובלי חיצוני של אפליקציות (ALB).

  1. במסוף Google Cloud , משתמשים בכלי לבחירת פרויקטים כדי לבחור את הפרויקט.
  2. כדי לראות את היומנים, עוברים לדף Logs Explorer:

    כניסה לדף Logs Explorer

  3. כדי לעקוב אחרי הזרקות תגים וניתוב של נתוני מדידה, מדביקים את הטקסט הבא בשדה Query.

    • מעקב אחרי שינויים בתוכן. כששער Google Tag מחדיר תגי Google לתגובות ה-HTML של האתר, ההחדרות של Google Tag נרשמות ביומני מאזן העומסים. כדי לוודא שהחדרת התגים האלה בוצעה בהצלחה, בודקים את מטען ה-JSON של היומן. בקשות שהתגובות שלהן ב-HTML שונו על ידי השער מכילות אובייקט serviceExtensionInfo במטען הייעודי (payload) של JSON, כאשר השדות extension ו-resource מסתיימים ב--google-tag-gateway.

      jsonPayload.serviceExtensionInfo.extension=~ "google-tag-gateway$"
      
    • מעקב אחרי ניתוב נתוני המדידה. אחרי פריסת Google Tag באתר, אפשר לזהות את הבקשות של נתיב המדידה ביומני איזון העומסים של האפליקציה החיצונית. לשם כך, מסננים את הרשומות שבהן backend_service_name מתחיל ב-google-tag-gateway-.

      resource.backend_service_name=~ "^google-tag-gateway-"
      

מידע על פתרון בעיות בשערי Google Tag זמין במאמר בנושא פתרון בעיות בהחדרת הקוד של שער Google Tag.

אינטראקציה עם היומנים

אפשר לקיים אינטראקציה עם היומנים של מאזן העומסים החיצוני של אפליקציות (ALB) באמצעות Cloud Logging API. ‫Logging API מספק דרכים לסנן באופן אינטראקטיבי יומנים שמוגדרים בהם שדות ספציפיים. הוא מייצא את היומנים התואמים ל-Cloud Logging, ל-Cloud Storage, ל-BigQuery או ל-Pub/Sub. מידע נוסף על Logging API זמין במאמר סקירה כללית על Logging API.

מעקב

מאזן העומסים מייצא נתוני מעקב אל Monitoring.

אפשר להשתמש במדדי מעקב כדי:

  • הערכת ההגדרה, השימוש והביצועים של מאזן עומסים
  • פתרון בעיות
  • שיפור השימוש במשאבים וחוויית המשתמש

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

צפייה במרכזי בקרה מוגדרים מראש ב-Cloud Monitoring

‫Cloud Monitoring מספק מרכזי בקרה מוגדרים מראש למעקב אחרי מאזני העומסים. לוחות הבקרה האלה מאוכלסים אוטומטית על ידי Monitoring.

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

כדי לגשת למרכזי הבקרה המוגדרים מראש:

  1. נכנסים לדף Monitoring במסוף Google Cloud .

    מעבר למעקב

  2. בחלונית הניווט 'מעקב', לוחצים על מרכזי בקרה.

  3. בקטע Categories (קטגוריות), לוחצים על GCP.

    • כדי לראות רשימה של לוחות בקרה עבור כל מאזני העומסים שלכם ב- Google Cloud , בוחרים בלוח הבקרה שנקרא Google Cloud Load Balancers (מאזני העומסים של Google Cloud). כדי לראות את לוח הבקרה של מאזן עומסים ספציפי, מאתרים את מאזן העומסים ברשימה ולוחצים על השם שלו.

    • כדי לראות את לוחות הבקרה המוגדרים מראש רק עבור מאזני העומסים החיצוניים של האפליקציות, בוחרים את לוח הבקרה שנקרא מאזני עומסים חיצוניים מסוג HTTP(S). בדף הזה מוצג לוח בקרה שבו מופיעים יחסי התגובה 5XX וחביון ה-Backend של כל מאזני העומסים החיצוניים של האפליקציות בפרויקט. בנוסף, הוא מספק רשימה של לוחות בקרה לכל מאזני העומסים החיצוניים של האפליקציות בפרויקט.

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

      • תרשימים שמולאו מראש ומציגים פירוט של התגובות לפי קטגוריות של קודי סטטוס (5xx, 4xx, 3xx, 2xx)
      • זמן האחזור הכולל
      • זמן האחזור של הקצה העורפי
      • זמן הלוך ושוב (RTT) של הקצה הקדמי
      • מספר הבקשות
      • קישור ליומנים של מאזן העומסים
  4. כדי לראות את לוחות הבקרה של שירותי צד שלישי, חוזרים לדף Dashboards. בקטע קטגוריות, לוחצים על אחר.

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

הגדרת כללי מדיניות התראות


לחצו על תראו לי איך כדי לקרוא הסבר מפורט על המשימה ישירות במסוף Google Cloud :

תראו לי איך


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

  1. נכנסים לדף  Alerting במסוף Google Cloud :

    כניסה אל התראות

    אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שבה הכותרת המשנית היא Monitoring.

  2. אם לא יצרתם ערוצי התראות ואתם רוצים לקבל התראות, לוחצים על Edit Notification Channels (עריכת ערוצי התראות) ומוסיפים את ערוצי ההתראות. אחרי שמוסיפים את הערוצים, חוזרים לדף התראות.
  3. בדף Alerting, לוחצים על Create policy.
  4. כדי לבחור את המדד, מרחיבים את התפריט Select a metric ומבצעים את הפעולות הבאות:
    1. כדי להגביל את התפריט לרשומות רלוונטיות, מזינים Global External Application Load Balancer Rule בסרגל הסינון. אם לא מוצאים תוצאות אחרי סינון התפריט, משביתים את המתג Show only active resources & metrics.
    2. בקטע Resource type, בוחרים באפשרות Global External Application Load Balancer Rule.
    3. בוחרים קטגוריית מדד ומדד, ואז לוחצים על החלה.
  5. לוחצים על הבא.
  6. ההגדרות בדף Configure alert trigger קובעות מתי ההתראה תופעל. בוחרים סוג תנאי, ואם צריך, מציינים סף. מידע נוסף זמין במאמר בנושא יצירת כללי מדיניות להתראות על סמך סף מדד.
  7. לוחצים על הבא.
  8. אופציונלי: כדי להוסיף התראות למדיניות ההתראות, לוחצים על ערוצי התראות. בתיבת הדו-שיח, בוחרים ערוץ התראות אחד או יותר מהתפריט ולוחצים על אישור.
  9. אופציונלי: מעדכנים את משך הזמן עד לסגירה אוטומטית של אירוע. השדה הזה קובע מתי מערכת Monitoring סוגרת אירועים בהיעדר נתוני מדדים.
  10. אופציונלי: לוחצים על תיעוד, ואז מוסיפים את המידע שרוצים לכלול בהודעת ההתראה.
  11. לוחצים על שם ההתראה ומזינים שם למדיניות ההתראה.
  12. לוחצים על יצירת מדיניות.
מידע נוסף זמין במאמר סקירה כללית על התראות.

הגדרת לוחות בקרה מותאמים אישית ב-Cloud Monitoring

אפשר ליצור לוחות בקרה מותאמים אישית ב-Cloud Monitoring למדדים של איזון העומסים:

  1. נכנסים לדף Monitoring במסוף Google Cloud .

    מעבר למעקב

  2. לוחצים על מרכזי בקרה > יצירת מרכז בקרה.

  3. לוחצים על הוספת תרשים ומזינים שם לתרשים.

  4. כדי לזהות את סדרת הזמנים שתוצג, בוחרים סוג משאב וסוג מדד:

    1. בקטע Resource & Metric, לוחצים על התרשים ואז בקטע Select a metric בוחרים מבין האפשרויות הזמינות:
      • במאזן עומסים גלובלי חיצוני של אפליקציות, בוחרים את סוג המשאב Global External Application Load Balancer Rule.
    2. לוחצים על אישור.
  5. כדי לציין מסנני מעקב, לוחצים על מסננים > הוספת מסנן.

  6. לוחצים על Save.

תדירות הדיווח על מדדים ושמירת הנתונים

מדדים של מאזני עומסים חיצוניים של אפליקציות מיוצאים ל-Cloud Monitoring באצוות של דקה אחת. נתוני המעקב נשמרים למשך שישה (6) שבועות.

לוח הבקרה מספק ניתוח נתונים במרווחים שמוגדרים כברירת מחדל: שעה אחת (1H), שש שעות (6H), יום אחד (1D), שבוע אחד (1W) ושישה שבועות (6W). אתם יכולים לבקש ניתוח באופן ידני בכל מרווח זמן שבין 6 שבועות לדקה אחת.

מדדי מעקב

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

המדדים הבאים של מאזני עומסים גלובליים חיצוניים של אפליקציות מדווחים ל-Cloud Monitoring.

מדד שם תיאור
השיעור שהוגדר בקצה העורפי network.googleapis.com/loadbalancer/backend/configured_rate הקצב המקסימלי בבקשות לשנייה שמוגדר לכל קבוצת קצה עורפי. התוצאה הזו מתקבלת מהכפלת קיבולת היעד בערך של הכפלת הקיבולת, אם צוין.
ניצול משאבים שהוגדר בקצה העורפי network.googleapis.com/loadbalancer/backend/configured_utilization קיבולת השימוש המקסימלית ב-CPU כשבר, שמוגדרת לכל קבוצת שרתים עורפיים. התוצאה הזו מתקבלת מהכפלת קיבולת היעד במקדם קנה המידה של הקיבולת, אם הוא צוין.
שיעור השגיאות בקצה העורפי network.googleapis.com/loadbalancer/backend/error_rate השגיאות שמוצגות על ידי כל קבוצת קצה עורפי לשנייה.
הקיבולת של הקצה העורפי network.googleapis.com/loadbalancer/backend/fullness מידת העומס הנוכחית בכל קבוצת קצה עורפי באחוזים, על סמך מצב האיזון של מאזן העומסים.
זמני אחזור בקצה העורפי loadbalancing.googleapis.com/https/backend_latencies

התפלגות של זמן האחזור של הקצה העורפי. זמן האחזור של הקצה העורפי הוא הזמן במילישניות בין הבייט האחרון של הבקשה שנשלחה לקצה העורפי לבין הבייט האחרון של התגובה שהתקבלה ב-proxy. הוא כולל את הזמן שלוקח לשרת העורפי לעבד את הבקשה ואת הזמן שלוקח לשלוח את התגובה בחזרה לשרת ה-proxy.

מדדים מותאמים אישית של איזון עומסים בקצה העורפי network.googleapis.com/loadbalancer/backend/lb_custom_metric השימוש הנוכחי בכל קבוצת קצה עורפי, על סמך המדדים המותאמים אישית שהגדרתם.
שיעור בקצה העורפי network.googleapis.com/loadbalancer/backend/rate הבקשות שמתקבלות בכל קבוצת שרתים עורפיים לשנייה.
ניצול של הקצה העורפי network.googleapis.com/loadbalancer/backend/utilization השימוש המצטבר במעבד של המכונות הווירטואליות בקבוצה כשבר.
בקשה בהמתנה שהוגדרה loadbalancer/backend/configured_in_flight_requests מספר הבקשות המקסימלי שמתבצעות לכל קבוצת שרתים לעורף. בקשות פעילות קובעות איך העומס מתחלק בין בקשות שפועלות יותר משנייה.
בקשה במהלך הטיסה loadbalancer/backend/in_flight_requests מספר השאילתות שמתבצעות בכל קבוצת שרתים.
מספר הבקשות loadbalancing.googleapis.com/https/request_count מספר הבקשות שמוצגות על ידי מאזן העומסים החיצוני של האפליקציות
מספר הבייטים בבקשה loadbalancing.googleapis.com/https/request_bytes_count מספר הבייטים שנשלחו כבקשות מלקוחות אל מאזן העומסים החיצוני של אפליקציות (ALB)
מספר הבייטים בתשובות loadbalancing.googleapis.com/https/response_bytes_count מספר הבייטים שנשלחו כתשובות ממאזן העומסים החיצוני של אפליקציות (ALB) ללקוחות
זמני האחזור הכוללים loadbalancing.googleapis.com/https/total_latencies

התפלגות של זמן האחזור הכולל. הזמן הכולל לתגובה הוא הזמן באלפיות השנייה שחלף בין הבייט הראשון של הבקשה שהתקבל על ידי ה-proxy לבין הבייט האחרון של התגובה שנשלחה על ידי ה-proxy. הוא כולל: הזמן שנדרש ל-Proxy לעבד את הבקשה, הזמן שנדרש לשליחת הבקשה מה-Proxy אל ה-Backend, הזמן שנדרש ל-Backend לעבד את הבקשה, הזמן שנדרש לשליחת התגובה בחזרה אל ה-Proxy והזמן שנדרש ל-Proxy לעבד את התגובה ולשלוח אותה אל הלקוח.

הנתון לא כולל את זמן ה-RTT בין הלקוח לבין השרת הפרוקסי. בנוסף, הפסקות בין בקשות באותו חיבור שמשתמשות ב-Connection: keep-alive לא משפיעות על המדידה. בדרך כלל, המדידה הזו מצטמצמת לאחוזון ה-95 בתצוגות של Cloud Monitoring.

בחיבורי WebSocket, השדה הזה מתייחס למשך הזמן הכולל של החיבור.*

דוגמה: למאזן עומסים יש בקשה אחת לשנייה מבריטניה, עם זמן אחזור של 100 אלפיות השנייה, ו-9 בקשות לשנייה מארה"ב, עם זמן אחזור של 50 אלפיות השנייה. במהלך דקה מסוימת היו 60 בקשות מבריטניה ו-540 בקשות מארה"ב. מעקב אחרי מדדים שומר על ההתפלגות בכל המאפיינים. אפשר לבקש מידע כמו:

  • זמן האחזור הכולל החציוני (300/600) – 50 אלפיות השנייה
  • זמן האחזור החציוני בבריטניה (30/60) – 100 אלפיות השנייה
  • זמן האחזור הכולל באחוזון ה-95 (570/600) – 100 אלפיות השנייה
‫RTT בקצה הקדמי loadbalancing.googleapis.com/https/frontend_tcp_rtt

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

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

חלק מקוד התגובה שמשויך לסיווג חלק מהתשובות הכוללות של מאזן עומסים של אפליקציות (ALB) חיצוני שנמצאות בכל סוג של קוד תגובה (2xx, 4xx וכו'). ב-מעקב, הערך הזה זמין רק במרכזי שליטה שמוגדרים כברירת מחדל. האפשרות הזו לא זמינה במרכזי בקרה מותאמים אישית. אפשר להשתמש ב-Monitoring API כדי להגדיר התראות לגביו.
מספר הבקשות לשרת העורפי loadbalancing.googleapis.com/https/backend_request_count מספר הבקשות שנשלחו ממאזן העומסים החיצוני של האפליקציות אל השרתים לעיבוד נתונים.
מספר הבייטים של בקשות לשרת העורפי loadbalancing.googleapis.com/https/backend_request_bytes_count מספר הבייטים שנשלחו כבקשות ממאזן העומסים החיצוני של האפליקציות אל שרתי הבק-אנד.
מספר הבייטים של התגובה מהקצה העורפי loadbalancing.googleapis.com/https/backend_response_bytes_count מספר הבייטים שנשלחו כתגובות מהבק-אנד (כולל המטמון) למאזן העומסים החיצוני של האפליקציות.

* כדי לנטר חיבורי websocket, צריך ליצור שירות backend במיוחד ל-websockets.

יכול להיות שסכום ה-RTT של חזית האתר והחביון של העורף לא יהיה קטן או שווה לחביון הכולל. הסיבה לכך היא שלמרות שאנחנו מבצעים בדיקה של RTT דרך הסוקט מ-GFE ללקוח בזמן האישור של תגובת ה-HTTP, אנחנו מסתמכים על דיווח של ליבת המערכת לגבי חלק מהמדידות האלה, ואין לנו אפשרות לוודא שלליבת המערכת תהיה מדידת RTT לגבי תגובת ה-HTTP הנתונה. התוצאה הסופית היא ערך RTT מוחלק שמושפע גם מתגובות HTTP קודמות, מ-SYN/ACK ומלחיצות ידיים של SSL שלא משפיעות על התזמונים בפועל של בקשת ה-HTTP הנוכחית.

סינון מאפיינים לפי מדדים

אפשר להחיל מסננים על מדדים של מאזני עומסים חיצוניים של אפליקציות.

המדדים מצטברים לכל מאזן עומסים קלאסי של אפליקציות (ALB) ולכל מאזן עומסים גלובלי חיצוני של אפליקציות (ALB). אפשר לסנן מדדים מצטברים לפי המאפיינים הבאים עבור resource.type="http_load_balancer" או resource.type="https_lb_rule". חשוב לזכור שלא כל המאפיינים זמינים לכל המדדים.

מאפיין (property) תיאור
backend_scope Google Cloud ההיקף (אזור או אזור זמינות) של קבוצת המופעים של שירות ה-Backend שסיפקה את החיבור.

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

  • FRONTEND_5xx: אירעה שגיאה פנימית לפני ש-GFE הצליח לבחור קצה עורפי. ה-GFE החזיר 5xx ללקוח.
  • INVALID_BACKEND: ל-GFE לא הייתה אפשרות למצוא קצה עורפי תקין להקצאת הבקשה, ולכן הוא החזיר קוד סטטוס 5xx למי ששלח את הבקשה.
  • NO_BACKEND_SELECTED: אירעה שגיאה או הפרעה לפני שנבחר בק-אנד, לפני שהתרחשה הפניה לכתובת URL אחרת, או לפני שמאזן עומסים קלאסי של אפליקציות (ALB) עם בק-אנדים בלי שרתים החזיר תגובה מסוג 200 OK.
  • ‫MULTIPLE_BACKENDS: הבקשה טופלה על ידי כמה שרתים אחוריים. המצב הזה יכול לקרות כש-Cloud CDN הציג את הבקשה באופן חלקי מהמטמון שלו, וגם שלח בקשה אחת או יותר של טווח בייטים לשרת העורפי. אפשר להשתמש בפירוט backend_scope כדי להציג באופן חזותי כל בקשה ממאזן העומסים לשרת העורפי.

כשבוחרים בפילוח הזה, בתרשימים מוצגים מדדי בק-אנד (load balancer-to-backends), ולא מדדי קצה קדמי (client-to-load balancer).

backend_type

השם של קבוצת השרתים העורפיים שטיפלה בבקשה של הלקוח. יכול להיות INSTANCE GROUP, NETWORK_ENDPOINT_GROUP או UNKNOWN אם לא הוקצה קצה עורפי. אם לא הייתה קבוצת קצה עורפי זמינה או אם הבקשה נשלחה על ידי ישות אחרת, יוצג אחד מהערכים הבאים במקום קבוצת קצה עורפי.

  • FRONTEND_5XX: אירעה שגיאה פנימית לפני ש-GFE הצליח לבחור בקצה העורפי. ה-GFE החזיר 5xx ללקוח.
  • INVALID_BACKEND: ל-GFE לא הייתה אפשרות למצוא קצה עורפי תקין להקצאת הבקשה, ולכן הוא החזיר קוד סטטוס 5xx למי ששלח את הבקשה.
  • NO_BACKEND_SELECTED: אירעה שגיאה או הפרעה לפני שנבחר בק-אנד, לפני שהתרחשה הפניה לכתובת URL אחרת, או לפני שמאזן עומסים קלאסי של אפליקציות (ALB) עם בק-אנדים בלי שרתים החזיר תגובה מסוג 200 OK.
  • ‫MULTIPLE_BACKENDS: הבקשה טופלה על ידי כמה שרתים אחוריים. המצב הזה יכול לקרות כש-Cloud CDN הציג את הבקשה באופן חלקי מהמטמון שלו, וגם שלח בקשה אחת או יותר של טווח בייטים לשרת העורפי. אפשר להשתמש בפירוט backend_scope כדי להציג באופן חזותי כל בקשה ממאזן העומסים לשרת העורפי.
backend_target_type השם של שירות הקצה העורפי שטיפל בבקשה. יכול להיות BACKEND_SERVICE, BACKEND_BUCKET, UNKNOWN אם לא הוקצה קצה עורפי, או NO_BACKEND_SELECTED אם התרחשה שגיאה או הפרעה לפני שנבחר קצה עורפי, התרחשה הפניה לכתובת URL אחרת, או מאזן עומסים קלאסי של אפליקציות עם קצוות עורפיים ללא שרתים החזיר תגובת 200 OK.
matched_url_path_rule כלל הנתיב של מפת URL שתאם לקידומת של בקשת HTTP(S) (עד 50 תווים).
forwarding_rule_name השם של כלל ההעברה שהלקוח השתמש בו כדי לשלוח את הבקשה.
url_map_name

כלל נתיב מפת URL או כלל מסלול שהוגדרו כחלק ממפתח מפת URL. אפשר להשתמש בערכים UNMATCHED או UNKNOWN כערכי ברירת מחדל.

  • UNMATCHED מתייחס לבקשה שלא תואמת לאף כלל של נתיב URL, ולכן url_map_name משתמש בכלל הנתיב שמוגדר כברירת מחדל.
  • UNKNOWN מציין שגיאה פנימית.
target_proxy_name השם של אובייקט ה-proxy של יעד HTTP(S) שאליו מפנה כלל ההעברה.
backend_target_name השם של יעד ה-Backend. היעד יכול להיות שירות קצה עורפי או מאגר קצה עורפי. הפונקציה מחזירה UNKNOWN אם לא הוקצה קצה עורפי.
backend_name השם של קבוצת שרתי העורף, של ה-bucket או של ה-NEG. הקוד UNKNOWN מוחזר אם לא הוקצה בק-אנד, או NO_BACKEND_SELECTED אם אירעה שגיאה או הפרעה לפני שנבחר בק-אנד, התרחשה הפניה לכתובת URL אחרת או אם מאזן עומסים קלאסי של אפליקציות (ALB) עם קצוות עורפיים בלי שרתים החזיר תגובה מסוג 200 OK.
backend_scope_type

סוג ההיקף של קבוצת הבק-אנד. יכול להיות GLOBAL,‏ REGION,‏ ZONE,‏ MULTIPLE_BACKENDS או NO_BACKEND_SELECTED אם התרחשה שגיאה או הפרעה לפני שנבחר בק-אנד, התרחשה הפניה לכתובת URL, או אם מאזן עומסים של אפליקציות (ALB) קלאסי עם בק-אנדים בלי שרתים החזיר תגובת 200 OK, או פלטים אפשריים אחרים של backend_type.

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

proxy_continent היבשת של ה-GFE ב-HTTP(S) שסיימה את החיבור ב-HTTP(S) – לדוגמה, America, ‏ Europe,‏ Asia
protocol הפרוטוקול שבו הלקוח משתמש, אחד מהערכים HTTP/1.0, HTTP/1.1, HTTP/2.0, QUIC/HTTP/2.0, UNKNOWN.
response_code קוד הסטטוס של ה-HTTP של הבקשה.
response_code_class קוד מצב ה-HTTP של הבקשה: 200,‏ 300, ‏ 400, ‏ 500 או 0 אם אין קוד.
cache_result תוצאת המטמון להצגת בקשת HTTP באמצעות שרת proxy: ‏ HIT,‏ MISS,‏ DISABLED,‏ PARTIAL_HIT (לבקשה שמוצגת חלקית מהמטמון וחלקית מהקצה העורפי) או UNKNOWN.
client_country המדינה של הלקוח ששלח את בקשת ה-HTTP – לדוגמה, United States או Germany.
load_balancing_scheme סכמת איזון העומסים שבה נעשה שימוש. אם משתמשים במאזן עומסים קלאסי של אפליקציות (ALB), הערך הוא EXTERNAL. אם משתמשים במאזן עומסים גלובלי חיצוני של אפליקציות (ALB), הערך הוא EXTERNAL_MANAGED.

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