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

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

רישום ביומן

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

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

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

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

הבקשות והתגובות התואמות שמטופלות על ידי מכונות וירטואליות (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.

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

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

המסוף

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

כניסה לדף איזון עומסים
לוחצים על השם של מאזן העומסים.
לוחצים על עריכה.
לוחצים על Backend Configuration (הגדרת ה-Backend).
בוחרים באפשרות יצירת שירות לקצה העורפי.
ממלאים את שדות החובה של שירות לקצה העורפי.
בקטע Logging (רישום ביומן), מסמנים את תיבת הסימון Enable logging (הפעלת רישום ביומן).
מגדירים שבר Sample rate. אפשר להגדיר מספר מ-0.0 עד 1.0, כאשר 0.0 אומר שלא מתבצעת רישום של בקשות ו-1.0 אומר שמתבצע רישום של 100% מהבקשות. ערך ברירת המחדל הוא 1.0.
אופציונלי: כדי לכלול את כל השדות האופציונליים ביומנים, בקטע Optional fields (שדות אופציונליים), לוחצים על Include all optional fields (כלול את כל השדות האופציונליים).
כדי לסיים את העריכה של שירות לקצה העורפי, לוחצים על עדכון.
כדי לסיים את העריכה של מאזן העומסים, לוחצים על עדכון.

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

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

המסוף

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

כניסה לדף איזון עומסים
לוחצים על השם של מאזן העומסים.
לוחצים על עריכה.
לוחצים על Backend Configuration (הגדרת ה-Backend).
לוחצים על עריכה לצד שירות ה-Backend.
בקטע Logging (רישום ביומן), מסמנים את תיבת הסימון Enable logging (הפעלת רישום ביומן).
בשדה תדירות הדגימה, מגדירים את הסתברות הדגימה. אפשר להגדיר מספר מ-0.0 עד 1.0, כאשר 0.0 אומר שלא מתבצעת רישום של בקשות ו-1.0 אומר שמתבצע רישום של 100% מהבקשות. ערך ברירת המחדל הוא 1.0.
אופציונלי: כדי לכלול את כל השדות האופציונליים ביומנים, בקטע Optional fields (שדות אופציונליים), לוחצים על Include all optional fields (כלול את כל השדות האופציונליים).
כדי לסיים את העריכה של שירות לקצה העורפי, לוחצים על עדכון.
כדי לסיים את העריכה של מאזן העומסים, לוחצים על עדכון.

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

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

המסוף

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

כניסה לדף איזון עומסים
לוחצים על השם של מאזן העומסים.
לוחצים על עריכה.
לוחצים על Backend Configuration (הגדרת ה-Backend).
לוחצים על עריכה לצד שירות ה-Backend.
כדי להשבית את הרישום ביומן לחלוטין, בקטע Logging (רישום ביומן), מבטלים את הסימון בתיבה Enable logging (הפעלת רישום ביומן).
אם לא משביתים את הרישום ביומן, אפשר להגדיר שבר אחר של שיעור הדגימה. אפשר להגדיר מספר מ-0.0 עד 1.0, כאשר 0.0 אומר שלא מתבצעת רישום של בקשות ו-1.0 אומר שמתבצע רישום של 100% מהבקשות. ערך ברירת המחדל הוא 1.0. לדוגמה, 0.2 אומר ש-20% מהבקשות שנדגמו יוצרות יומנים.
כדי לסיים את העריכה של שירות לקצה העורפי, לוחצים על עדכון.
כדי לסיים את העריכה של מאזן העומסים, לוחצים על עדכון.

‫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 \
    --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 מציין שהשירות לקצה העורפי הוא גלובלי. השתמשו בשדה הזה לשירותים לקצה העורפי שמשמשים עם מאזן עומסים קלאסי של אפליקציות (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, בוחרים באפשרות Cloud HTTP Load Balancer > All forwarding rules.
כדי להציג יומנים של כלל העברה אחד, בוחרים שם של כלל העברה אחד.
כדי לראות את היומנים של מפת 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` `overrideResponseCode` `errorService` `errorBackendStatusDetails` `authzPolicyInfo` `loadBalancingScheme` `tls` `orca_load_report`
	מחרוזת	חובה	בשדה `statusDetails` יש מחרוזת שמסבירה למה מאזן העומסים החזיר את קוד הסטטוס של HTTP. מידע נוסף על מחרוזות היומן האלה זמין במאמרים בנושא הודעות הצלחה של HTTP ב-statusDetails והודעות שגיאה של HTTP ב-statusDetails.
	מחרוזת	חובה	בשדה `backendTargetProjectNumber` מופיע מספר הפרויקט שבו נוצר יעד הקצה העורפי – שירות קצה עורפי או קטגוריית קצה עורפי. הפורמט של השדה הזה הוא: `"projects/PROJECT_NUMBER"`. המידע הזה זמין רק למאזני עומסים גלובליים חיצוניים של אפליקציות שמשתמשים בתשובות שגיאה מותאמות אישית.
	מספר שלם	חובה	השדה `overrideResponseCode` מכיל את קוד התגובה של הביטול שהוחל על התגובה שנשלחה ללקוח. המידע הזה זמין רק למאזני עומסים גלובליים חיצוניים של אפליקציות שמשתמשים בתשובות שגיאה מותאמות אישית.
	מחרוזת	חובה	השדה `errorService` מכיל את שירות הקצה העורפי שסיפק את תגובת השגיאה המותאמת אישית. המידע הזה זמין רק למאזני עומסים גלובליים חיצוניים של אפליקציות שמשתמשים בתשובות שגיאה מותאמות אישית.
	מחרוזת	חובה	השדה `errorBackendStatusDetails` מכיל את `statusDetails` של התשובה הסופית שמוצגת ללקוח. המידע הזה זמין רק למאזני עומסים גלובליים חיצוניים של אפליקציות שמשתמשים בתשובות שגיאה מותאמות אישית.
	AuthzPolicyInfo	חובה	בשדה `authzPolicyInfo` מאוחסן מידע על התוצאה של מדיניות ההרשאות. המידע הזה זמין רק למאזני עומסים גלובליים חיצוניים של אפליקציות שבהם מופעלות מדיניות הרשאות. מידע נוסף זמין במאמר בנושא מה נרשם ביומן לגבי מדיניות הרשאות.
	מחרוזת	אופציונלי	השדה `loadBalancingScheme` מאוכלס רק אם משתמשים בתכונה להעברה של מאזן עומסים של אפליקציות (ALB) קלאסי. השדה הזה מכיל מחרוזת שמתארת את סכמת איזון העומסים ששימשה לניתוב הבקשה. הערכים האפשריים הם `EXTERNAL` או `EXTERNAL_MANAGED`.
	TlsInfo	חובה	השדה `tls` מכיל את השדה TlsInfo שמציין את מטא-נתוני ה-TLS של החיבור בין הלקוח לבין מאזן העומסים. השדה הזה זמין רק אם הלקוח משתמש בהצפנת TLS/SSL. משתמשים בפרמטר `--logging-optional-fields` כדי לציין אילו רכיבים צריך לתעד: `tls.protocol` (אופציונלי) `tls.cipher` (אופציונלי) חובה: `tls.earlyDataRequest` אי אפשר להגדיר את `--logging-optional-fields` ל-`tls` כדי לציין את כל הרכיבים.
	OrcaLoadReport	אופציונלי	השדה `orca_load_report` מכיל חלק מהאלמנטים של דוח הטעינה של 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` כדי לציין שצריך לרשום ביומן את כל הרכיבים.

הערה: הפניות (קוד סטטוס של תגובת HTTP‏ 302 Found) שמונפקות ממאזן העומסים לא נרשמות ביומן. ההפניות האוטומטיות מתועדות ביומן של מופעי ה-Backend.

פורמט השדה TlsInfo

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

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

בטבלה הבאה מפורטות תוויות המשאבים של 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)	משמעות	קודי סטטוס נפוצים שמופיעים יחד עם קוד הסטטוס 200
`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`	הזמן הקצוב לתשובה הסתיים בשרת העורפי. בחיבור websocket: במאזן עומסים חיצוני גלובלי של אפליקציות, קוד סטטוס נוצר כש-GFE סוגר את חיבור ה-WebSocket במצב סרק אחרי שפג הזמן הקצוב לתפוגה של שירות לקצה העורפי. ב-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‏ (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`
`config_not_found`	חסרה הגדרת פרויקט במאזן העומסים. הבעיה הזו יכולה להתרחש לסירוגין אחרי שמבצעים שינויים בהגדרות שמוסיפים משאב חדש. סיבה נוספת לשגיאה היא שכשל בתקשורת בין GFE בשכבה הראשונה לבין GFE בשכבה השנייה. הסיבה לכך יכולה להיות שגיאה פנימית, כמו השקה בתהליך, עומס יתר במאזן העומסים או בעיות בהגדרות לסירוגין. השגיאות האלה הן זמניות במהותן, והן צפויות להיות במסגרת הסכם רמת השירות. עם זאת, אם שיעור השגיאות גבוה מ-0.01%, צריך לפנות אל Google Cloud התמיכה כדי לקבל עזרה נוספת.	`404`, `502`, `503`
`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) בשכבה הראשונה. קוד הכשל הזה רלוונטי רק למאזני עומסים גלובליים חיצוניים של אפליקציות (ALB) ולמאזני עומסים קלאסיים של אפליקציות (ALB).	`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`) הם לא תקינים. למידע נוסף: ‫5.5. הקטע Field Values (ערכי שדות) ב-RFC 9110 ‫ "5. בקטע Field Syntax (תחביר השדה) של RFC 9112 ‫8.2.1. הקטע 'תוקף השדה' ב-RFC 9113	`400`
`invalid_http2_client_header_format`	הכותרות של HTTP/2 מלקוח לא תקינות. מידע נוסף זמין במאמר `invalid_request_headers`.	`400`
`invalid_http2_client_request_path`	נתיב הבקשה HTTP/2 מלקוח מכיל לפחות תו אחד שלא מותר לפי מפרט ה-URI. מידע נוסף זמין במאמר בנושא '3.3. הקטע Path (נתיב) של RFC 3986.	`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 בלי שרת (serverless). השגיאה הזו יכולה להתרחש אם אי אפשר להגיע לאזור שצוין ב-NEG, או אם אי אפשר למצוא את שם המשאב (לדוגמה, השם של פונקציות Cloud Run).	`404`, `502`, `503`
`fault_filter_abort`	השגיאה הזו יכולה להתרחש אם הלקוח הגדיר מסנן תקלות, והמסנן הופעל עבור הבקשה הנתונה.	הערך צריך להיות בין `200` ל-`599`.
`early_data_rejected`	הבקשה שנשלחה בנתונים מוקדמים של TLS לא הייתה תקינה. מצב כזה יכול לקרות במקרים הבאים, אבל לא רק בהם: הפרמטר `TargetHttpsProxy` של נתוני TLS מוקדמים מוגדר לערך `STRICT`, אבל הבקשה כללה פרמטרים של שאילתה. הערך של `TargetHttpsProxy` הוא `STRICT` או `PERMISSIVE`, אבל הבקשה השתמשה בשיטת HTTP לא אידמפוטנטית (כמו POST או PUT).	425
`service_extension_error`	אירעה שגיאה בקריאה לתוסף שירות שמשמש את מאזן העומסים. יכול להיות שהסיבה לכך היא שהתוסף Wasm מגיב לאט ועובר את המגבלה של אלפית השנייה לשליחת התגובה.	425

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

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

שאילתה במסוף

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

כניסה לדף Logs Explorer
לוחצים על המתג Show query.

מדביקים את הטקסט הבא בשדה השאילתה. מחליפים את 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

לוחצים על 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.

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

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

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

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

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

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

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

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

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

כניסה ל-Monitoring
בחלונית הניווט 'מעקב', לוחצים על מרכזי בקרה.
בקטע Categories (קטגוריות), לוחצים על GCP.
- כדי לראות רשימה של לוחות בקרה עבור כל מאזני העומסים שלכם ב- Google Cloud Google Cloud, בוחרים בלוח הבקרה שנקרא Google Cloud Load Balancers. כדי לראות את לוח הבקרה של מאזן עומסים ספציפי, מאתרים את מאזן העומסים ברשימה ולוחצים על השם שלו.
- כדי לראות את לוחות הבקרה המוגדרים מראש רק עבור מאזני העומסים החיצוניים של האפליקציות, בוחרים את לוח הבקרה שנקרא מאזני עומסים חיצוניים מסוג HTTP(S). בדף הזה מוצג לוח בקרה שבו אפשר לראות את יחסי התגובה 5XX ואת זמן האחזור של ה-backend לכל מאזני העומסים החיצוניים של האפליקציות בפרויקט. בנוסף, הוא מספק רשימה של לוחות בקרה לכל מאזני העומסים החיצוניים של האפליקציות בפרויקט.
  
  אפשר ללחוץ על כל מאזן עומסים כדי לעבור ללוח הבקרה שלו. כל לוח בקרה כולל את הפרטים הבאים:
  - תרשימים שמולאו מראש ומציגים פירוט של התגובות לפי קטגוריות של קודי סטטוס (5xx, 4xx, 3xx, 2xx)
  - זמן האחזור הכולל
  - זמן האחזור של הקצה העורפי
  - זמן הלוך ושוב (RTT) בקצה הקדמי
  - מספר הבקשות
  - קישור ליומנים של מאזן העומסים
כדי לראות את לוחות הבקרה של שירותי צד שלישי, חוזרים לדף לוחות בקרה. בקטע קטגוריות, לוחצים על אחר.
- כדי לראות את לוח הבקרה של שירות ספציפי של צד שלישי, מאתרים אותו ברשימה ולוחצים על השם שלו.

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

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

תראו לי איך

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

נכנסים לדף Alerting במסוף Google Cloud :
עוברים אל התראות

אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שכותרת המשנה שלה היא Monitoring.
אם עדיין לא יצרתם ערוצי התראות ואתם רוצים לקבל התראות, לוחצים על Edit Notification Channels ומוסיפים את ערוצי ההתראות. אחרי שמוסיפים את הערוצים, חוזרים לדף התראות.
בדף Alerting, לוחצים על Create policy.
כדי לבחור את המדד, מרחיבים את התפריט 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. בוחרים קטגוריית מדד ומדד, ואז לוחצים על החלה.
לוחצים על הבא.
ההגדרות בדף Configure alert trigger קובעות מתי ההתראה תופעל. בוחרים סוג תנאי, ואם צריך, מציינים סף. מידע נוסף זמין במאמר יצירת כללי מדיניות להתראות על סמך סף מדד.
לוחצים על הבא.
אופציונלי: כדי להוסיף התראות למדיניות ההתראות, לוחצים על ערוצי התראות. בתיבת הדו-שיח, בוחרים ערוץ התראות אחד או יותר מהתפריט ולוחצים על אישור.
אופציונלי: מעדכנים את משך הזמן עד לסגירה אוטומטית של אירוע. השדה הזה קובע מתי מערכת Monitoring סוגרת אירועים בהיעדר נתונים של מדדים.
אופציונלי: לוחצים על תיעוד, ואז מוסיפים את המידע שרוצים לכלול בהודעת ההתראה.
לוחצים על שם ההתראה ומזינים שם למדיניות ההתראה.
לוחצים על יצירת מדיניות.

מידע נוסף מופיע במאמר סקירה כללית על התראות.

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

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

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

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

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

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

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

מדדי מעקב

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

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

סינון הטבלה:

מדד	שם	תיאור
קצב נתונים שהוגדר בקצה העורפי (תצוגה מקדימה)	`network.googleapis.com/loadbalancer/backend/configured_rate`	הקצב המקסימלי בבקשות לשנייה שמוגדר לכל קבוצת עורפי קצה. זו התוצאה של שינוי קנה המידה של קיבולת היעד לפי capacity scaler, אם צוין.
ניצול הקיבולת שהוגדרה בשרת העורפי (תצוגה מקדימה)	`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.
מדדים מותאמים אישית לאיזון עומסים בקצה העורפי (גרסת Preview)	`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`	מספר הבקשות שמועברות על ידי מאזן העומסים החיצוני של אפליקציות (ALB)
מספר הבייטים בבקשה	`loadbalancing.googleapis.com/https/request_bytes_count`	מספר הבייטים שנשלחו כבקשות מלקוחות למאזן העומסים החיצוני של האפליקציות
מספר הבייטים בתשובות	`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 אלפיות השנייה
זמן תגובה של הקצה הקדמי^†	`loadbalancing.googleapis.com/https/frontend_tcp_rtt`	התפלגות של זמן התגובה של חזית האתר. זמן ה-RTT של חזית האתר הוא משך הזמן במילישניות שנדרש לנתונים כדי לעבור מהלקוח אל ה-proxy ובחזרה. הוא כולל את הזמן שלוקח לבקשה לעבור מהלקוח לשרת ה-proxy ובחזרה מה-proxy ללקוח. הערך הזה לא מתעדכן במהלך משך החיים של החיבור. לדוגמה, הגדרת חיבור (TCP) עם לחיצת יד תלת-כיוונית תימשך 1.5 RTT. כשבקשות מעובדות, מאזן העומסים מבצע דגימה ומחשב את הממוצע של הזמן שנדרש לנתונים כדי לעבור הלוך ושוב בין הלקוח לבין ה-proxy, ואז מתעד ערך מוחלק של RTT. ה-RTT המוחלק הוא אלגוריתם שמטפל בשינויים ובאנומליות שעשויים להתרחש במדידות של ה-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`	מספר הבייטים שנשלחו כתגובות מהבק-אנד (כולל מטמון) למאזן העומסים החיצוני של אפליקציות (ALB).

^* כדי לבצע מעקב אחר חיבורי WebSocket, צריך ליצור שירות לקצה העורפי במיוחד ל-WebSocket.

‫^† יכול להיות שסכום ה-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 ההיקף (אזור או אזור זמינות) של קבוצת המופעים של שירות הקצה העורפי שסיפק את החיבור. אם לא הייתה זמינה קבוצת מופעים או שהבקשה טופלה על ידי ישות אחרת, יוצג אחד מהערכים הבאים במקום האזור או האזור של קבוצת מופעים של שירות קצה עורפי. ‫`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, ולכן `UNMATCHED` משתמש בכלל הנתיב שמוגדר כברירת מחדל.`url_map_name` ‫`UNKNOWN` מציין שגיאה פנימית.
`target_proxy_name`	השם של אובייקט ה-proxy של יעד HTTP(S) שאליו מפנה כלל ההעברה.
`backend_target_name`	השם של יעד ה-Backend. היעד יכול להיות שירות לקצה העורפי או קטגוריית קצה עורפי. הפונקציה מחזירה `UNKNOWN` אם לא הוקצה קצה עורפי.
`backend_name`	השם של קבוצת שרתים עורפיים (backend instance), של מאגר הנתונים או של ה-NEG. הקוד `UNKNOWN` מוחזר אם לא הוקצה בק-אנד, או `NO_BACKEND_SELECTED` אם אירע אירוע שגיאה או הפרעה לפני שנבחר בק-אנד, התרחשה הפניה לכתובת URL אחרת או אם מאזן עומסים קלאסי של אפליקציות עם בק-אנדים בלי שרתים החזיר תגובה מסוג `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`.

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

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

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