רישום ביומן ומעקב אחרי מאזן עומסים גלובלי חיצוני של אפליקציות (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,orca_load_report.cpu_utilization,orca_load_report.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. כדי לסיים את העריכה של שירות ה-Backend, לוחצים על עדכון.

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

gcloud

יוצרים שירות backend ומפעילים את הרישום ביומן באמצעות הפקודה 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. לדוגמה, orca_load_report.cpu_utilization,orca_load_report.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. כדי לסיים את העריכה של שירות ה-Backend, לוחצים על עדכון.

  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. לדוגמה, orca_load_report.cpu_utilization,orca_load_report.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. כדי לסיים את העריכה של שירות ה-Backend, לוחצים על עדכון.

  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. לדוגמה, orca_load_report.cpu_utilization,orca_load_report.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 מציין שהשירות לקצה העורפי הוא גלובלי. משתמשים בשדה הזה לשירותים לקצה העורפי שמשמשים עם מאזן עומסים קלאסי של אפליקציות.
  • ‫--no-enable-logging משבית את הרישום ביומן עבור שירות הקצה העורפי הזה.

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

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

איפה

  • ‫--global מציין שהשירות לקצה העורפי הוא גלובלי. משתמשים בשדה הזה לשירותים לקצה העורפי שמשמשים עם מאזן עומסים קלאסי של אפליקציות.
  • --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) חובה המטען הייעודי (payload) של הרשומה ביומן, שמוצג כאובייקט JSON. אובייקט ה-JSON כולל את השדות הבאים:
  • statusDetails
  • backendTargetProjectNumber
  • cachePolicySource
  • overrideResponseCode
  • errorService
  • errorBackendStatusDetails
  • authzPolicyInfo
  • loadBalancingScheme
  • tls
  • serviceExtensionInfo
  • orca_load_report
מחרוזת חובה השדה 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.

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

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

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

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

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

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

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

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

אם הפעלתם את Google Tag Gateway במאזן העומסים, התג 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 שהוגדר לבחירת שירות backend.
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 לבקשה בהקשר שבו לא נתמכות תשובות זמניות.

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

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

בחיבור 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 שמצורפת לשירות backend ומדיניות אחרת שמצורפת לאובייקט 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) של אישור השרת (כולל אישורי ביניים) גדול מדי (יותר מ-‎16 KB). 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 משותף

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

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

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

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

אפשר לקיים אינטראקציה עם היומנים של מאזן העומסים החיצוני של האפליקציות באמצעות 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 .

    כניסה ל-Monitoring

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

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

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

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

    כניסה ל-Monitoring

  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 מספר הבייטים שנשלחו כבקשות מלקוחות אל מאזן העומסים החיצוני של אפליקציות
מספר הבייטים בתשובות loadbalancing.googleapis.com/https/response_bytes_count מספר הבייטים שנשלחו כתשובות ממאזן העומסים החיצוני של האפליקציות ללקוחות
זמני האחזור הכוללים 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 בחלק הקדמי של האתר. זמן הלוך ושוב (RTT) בחלק הקדמי של האתר הוא משך הזמן במילישניות שלוקח לנתונים לעבור מהלקוח לשרת הפרוקסי ובחזרה. הוא כולל את הזמן שלוקח לבקשה לעבור מהלקוח לשרת ה-proxy ובחזרה משרת ה-proxy ללקוח. הערך הזה לא מתעדכן במהלך משך החיים של החיבור. לדוגמה, הגדרת חיבור (TCP) עם לחיצת יד תלת-כיוונית תימשך 1.5 RTT.

כשבקשות מעובדות, מאזן העומסים מבצע דגימה ומחשב את הממוצע של הזמן שנדרש לנתונים כדי לעבור הלוך ושוב בין הלקוח לבין ה-proxy, ואז מתעד ערך RTT מוחלק. האלגוריתם של RTT מוחלק מתמודד עם שינויים ואנומליות שעשויים להתרחש במדידות של RTT.
חלק מהתגובה שמשויך לסיווג חלק מהתשובות הכוללות של מאזן עומסים חיצוני של אפליקציות שנמצאות בכל סוג של קוד תשובה (2xx, 4xx וכו'). ב-Monitoring, הערך הזה זמין רק בלוחות בקרה שמוגדרים כברירת מחדל. האפשרות הזו לא זמינה במרכזי בקרה מותאמים אישית. אפשר להשתמש ב-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 שסיפקה את החיבור.

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

  • ‫FRONTEND_5xx: אירעה שגיאה פנימית לפני ש-GFE הצליח לבחור קצה עורפי. ה-GFE החזיר 5xx ללקוח.
  • INVALID_BACKEND: ל-GFE לא הייתה אפשרות למצוא קצה עורפי תקין להקצאת הבקשה, ולכן הוא החזיר קוד סטטוס 5xx למי ששלח את הבקשה.
  • NO_BACKEND_SELECTED: אירעה שגיאה או הפרעה לפני שנבחר קצה עורפי, לפני שהתרחשה הפניה לכתובת URL או לפני שמאזן עומסים קלאסי של אפליקציות עם קצוות עורפיים ללא שרתים החזיר תגובה מסוג 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 או לפני שמאזן עומסים קלאסי של אפליקציות עם קצוות עורפיים ללא שרתים החזיר תגובה מסוג 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 אחרת או אם איזון עומסים קלאסי של אפליקציות עם קצוות עורפיים ללא שרתים החזיר תגובה מסוג 200 OK.
backend_scope_type

סוג ההיקף של קבוצת הבק-אנד. יכול להיות GLOBAL,‏ REGION,‏ ZONE,‏ MULTIPLE_BACKENDS או NO_BACKEND_SELECTED אם התרחשה שגיאה או הפרעה לפני שנבחר קצה עורפי, התרחשה הפניה לכתובת URL או שאזן עומסים קלאסי של אפליקציות עם קצוות עורפיים ללא שרתים החזיר תגובה מסוג 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.

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