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

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

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

יכול להיות שתראו את השגיאה הבאה כשתיצרו מאזן עומסים:

Validation failed for instance group INSTANCE_GROUP:

backend services 1 and 2 point to the same instance group
but the backends have incompatible balancing_mode. Values should be the same.

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

למידע נוסף, קראו את המאמרים הבאים:

פתרון בעיות כלליות בחיבור

שגיאות '5XX' לא מוסברות

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

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

זיהוי המקור של שגיאות מסוג '5XX' באמצעות Cloud Logging

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

כדי לקבוע אם תגובת HTTP 5XX הועברה מקצה עורפי או נוצרה על ידי שרת proxy של מאזן העומסים, בודקים את השדה statusDetails ב-Cloud Logging.

  • אם statusDetails הוא response_sent_by_backend, מאזן העומסים העביר את תגובת 5XX מהקצה העורפי. פתרון בעיות בקצוות העורפיים.
  • אם statusDetails היא הודעת שגיאה אחרת, התגובה 5XX נוצרת על ידי מאזן העומסים.

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

לפני שמתחילים לפתור בעיות, צריך לוודא שה-backend תקין

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

  1. מוודאים שיש כלל חומת אש שמוגדר כך שמאפשר בדיקות תקינות. אם אין כזה, בדיקות התקינות נכשלות, וביומנים של מאזן העומסים עשוי להופיע statusDetails של failed_to_pick_backend.
  2. מוודאים שהתנועה של בדיקת תקינות מגיעה למכונות הווירטואליות של ה-Backend. כדי לעשות את זה, מפעילים את הרישום ביומן של בדיקת התקינות ומחפשים רשומות יומן שהושלמו בהצלחה. יכול להיות שבמאזני עומסים חדשים לא תראו מיד רשומות ביומן של בדיקות תקינות שעברו בהצלחה. יכול להיות שהסיבה לכך היא שמצב התקינות הראשוני של ה-backend עדיין לא השתנה מUNHEALTHY למצב אחר. רשומות יומן של בדיקת תקינות מוצלחת מוצגות רק אחרי שכלי הבדיקה של בדיקת התקינות מקבל תגובה מסוג HTTP 200 OK מהקצה העורפי.

אם בדיקות תקינות נכשלות, צריך לפתור את הבעיה באפליקציית ה-Backend ובכללי חומת האש. אם בדיקות תקינות עוברות אבל עדיין מופיעות שגיאות 5XX, צריך לבדוק את השדה statusDetails ב-Cloud Logging כדי לזהות את מקור השגיאה, כמו שמתואר בקטע הבא.

פתרון בעיות על סמך statusDetails

אם שגיאות HTTP 5XX נמשכות, צריך להשתמש בשדה statusDetails ב-Cloud Logging כדי לזהות את הסיבה ולפתור את הבעיה בהתאם.

  • מאזן העומסים הגלובלי החיצוני של אפליקציות (ALB) ומאזן העומסים החיצוני האזורי של אפליקציות (ALB) יוצרים קודי סטטוס משמעותיים של HTTP, כמו HTTP 503 Service Unavailable ו-HTTP 504 Gateway Timeout.

  • מאזן העומסים הקלאסי של אפליקציות (ALB) תמיד משתמש בקוד הסטטוס HTTP 502 Bad Gateway לכל השגיאות שנוצרות על ידי מאזן העומסים.

statusDetails סיבה אפשרית ופתרון
failed_to_pick_backend
failed_to_pick_backend_by_hash		 הסיבה: שרת GFE בשכבה השנייה לא הצליח לבחור קצה עורפי תקין כדי להפנות אליו את הבקשה.

השגיאה הזו יכולה להופיע מהסיבות הבאות:

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

פתרון:

  • כדי לוודא שהשרתים העורפיים תקינים, פועלים לפי השלבים שמפורטים במאמר בדיקת תקינות השרת העורפי.
  • מוודאים שבודקים את תקינות השרת מוגדרים בצורה נכונה עם היציאה, הנתיב והפרוטוקול הנכונים.
  • מוודאים שכללי חומת האש של השרתים העורפיים מאפשרים תעבורת נתונים של בדיקות תקינות 177.222.80.0/23מהבודקים של בדיקות התקינות.
  • אם יש לכם כמה קבוצות של מכונות עורפיות לא תקינות, חשוב לדעת שהמעבר לגיבוי אוטומטי או המעבר לקיבולת עודפת מוגבל למספר מצומצם של קבוצות חלופיות של מכונות. אם אתם רואים את השגיאה failed_to_pick_backend או failed_to_pick_backend_by_hash למרות שקבוצות המופעים תקינות, צריך לרוקן את קבוצות המופעים הלא תקינות על ידי הגדרת הקיבולת שלהן לאפס. כך מאלצים את מאזן העומסים להעביר את התעבורה לקבוצות של מופעים תקינים.
failed_to_connect_to_backend הגורם: שרת GFE בשכבה השנייה לא הצליח ליצור חיבור למופע של קצה עורפי (לא הייתה אפשרות לקבל SYN-ACK). השגיאה הזו יכולה להיגרם גם משגיאה פנימית ב-GFE שלא מאפשרת להתחבר לקצה העורפי, או מהפסקת חשמל אזורית או משיבוש ברשת (למשל, חיתוך של סיב אופטי) שלא מאפשרים ל-GFE בשכבה הראשונה לתקשר עם GFE בשכבה השנייה.

פתרון:

  • מוודאים שכללי חומת האש במכונות הווירטואליות של ה-Backend או ברשת ה-VPC מאפשרים תעבורת נתונים ל-Backend מטווחים של GFE בשכבה השנייה 177.222.80.0/23.
  • מוודאים שהאפליקציה במופעים של ה-Backend פועלת ומאזינה ליציאה שהוגדרה בשירות לקצה העורפי.
  • בודקים את המדדים של שרת עורפי (backend instance) (מעבד, זיכרון, חיבורים) כדי לזהות סימנים של מיצוי משאבים.
backend_connection_closed_before_data_sent_to_client הסיבה: החיבור בין GFE בשכבה השנייה לבין ה-backend נסגר באופן לא צפוי לפני שהתגובה נשלחה ללקוח. הבעיה הזו יכולה להיגרם בגלל שרת האינטרנט של הבק-אנד או בגלל מכשיר ביניים. זה יכול לקרות גם כשמשתמשים ב-GKE אם הפודים מצטמצמים או מסיימים את הפעולה, והעורפים של מאזן העומסים הם מסוג NEGs.

פתרון:

  • מגדירים את הזמן הקצוב לתפוגה של HTTP keepalive בשרת האינטרנט של העורף (כמו Apache או Nginx) כך שיהיה ארוך יותר מהזמן הקצוב לתפוגה של מאזן העומסים (600 שניות). הערך המומלץ הוא 620 שניות.
  • אם אתם משתמשים ב-GKE, זה קורה כשה-Pods מצטמצמים או מסיימים את הפעולה, והקצה העורפי של מאזן העומסים הוא NEG. כדי לפתור את הבעיה, כדאי להגדיל את הערך של terminationGracePeriodSeconds בהגדרות של ה-pod או הפריסה, כדי לאפשר לחיבורים הקיימים להיסגר בצורה תקינה. הערך האידיאלי הוא:

    Tgrace > TpreStop + Tdrain + Tbuffer

    כאשר:

    • ‫TpreStop הוא משך ההשהיה של ה-hook של preStop של הקונטיינר, שבדרך כלל הוא 120 שניות כדי לאפשר הסרה של נקודת הקצה מ-NEG.
    • ‫Tdrain הוא הזמן הקצוב לתפוגה של ניתוק החיבור לשירות הקצה העורפי, שבדרך כלל הוא 60 שניות.
    • ‫Tbuffer הוא חיץ נוסף של 30-45 שניות שמאפשר כיבוי בטוח של ה-Pod.
    בהגדרות רגילות, הערך המומלץ הוא לפחות 210 שניות (3.5 דקות).
  • בודקים ביומני הרישום של אפליקציות ה-Backend אם יש שגיאות שעלולות לגרום לסגירת החיבור.
  • בודקים את המדדים של שרת עורפי (backend instance) (מעבד, זיכרון, חיבורים) כדי לזהות סימנים של מיצוי משאבים.
backend_timeout הסיבה: GFE בשכבה השנייה יצר חיבור עם העורף, אבל העורף לא שלח תגובה במסגרת הזמן הקצוב לתפוגה של שירות העורף שהוגדר.

פתרון:

  • אם האפליקציה שלכם צריכה יותר זמן לעיבוד בקשות, הגדילו את הזמן הקצוב לתפוגה של שירות לקצה העורפי.
  • בודקים אם יש בעיות בביצועים במופעי ה-Backend (מעבד, קלט/פלט, עיכובים באפליקציה) שעשויות למנוע תגובה בזמן.
  • אם העומס על ה-Backends גבוה מדי, כדאי להגדיל את משאבי ה-Backend או לבצע אופטימיזציה של האפליקציה.
retriable_error הסיבה: שגיאת 503 יכולה להתרחש אם כלים של תשתית כקוד (IaC) (כמו Terraform) מעדכנים כללים של מאזן עומסים באופן שמסיר זמנית כללים של מפת URL לפני הוספה שלהם מחדש, או בגלל בעיות חולפות ברשת הפנימית של Google או בתצורה שלה במהלך השקות או דחיפות של תצורה.

פתרון:

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

פתרון שגיאות HTTP 408

בתעבורת נתונים של HTTP, משך הזמן המקסימלי שמוקצב ללקוח כדי להשלים את שליחת הבקשה שלו שווה לזמן הקצוב לתפוגה של שירות לקצה העורפי. אם אתם רואים תגובות HTTP 408 עם jsonPayload.statusDetail client_timed_out, המשמעות היא שלא הייתה התקדמות מספקת בזמן שהבקשה מהלקוח הועברה דרך שרת proxy או שהתגובה מהקצה העורפי הועברה דרך שרת proxy. אם הבעיה נובעת מלקוחות שחווים בעיות בביצועים, אפשר לפתור אותה על ידי הגדלת הזמן הקצוב לתפוגה של שירות לקצה העורפי.

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

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

  • חיבור 1, מהלקוח המקורי למאזן העומסים (GFE או רשת משנה של proxy בלבד)
  • חיבור 2, ממאזן העומסים (GFE או רשת משנה של proxy בלבד) למכונה וירטואלית או לנקודת קצה בעורף

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

מקבלים שגיאת הרשאה כשמנסים להציג אובייקט בקטגוריה של Cloud Storage

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

כתובת ה-URL לא מציגה את האובייקט הצפוי ב-Cloud Storage

האובייקט של Cloud Storage שיוצג נקבע על סמך מיפוי כתובות ה-URL וכתובת ה-URL שביקשתם. אם נתיב הבקשה ממופה לקטגוריית קצה עורפי במפת URL, האובייקט ב-Cloud Storage נקבע על ידי הוספת נתיב הבקשה המלא לקטגוריה של Cloud Storage שצוינה במפת URL.

לדוגמה, אם ממפים את /static/* ל-gs://[EXAMPLE_BUCKET], הבקשה ל-https://<GCLB IP or Host>/static/path/to/content.jpg תנסה להציג את gs://[EXAMPLE_BUCKET]/static/path/to/content.jpg. אם האובייקט לא קיים, במקום האובייקט תופיע הודעת השגיאה הבאה:


NoSuchKey
The specified key does not exist.

הדחיסה לא עובדת

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

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

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

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

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

פתרון בעיות שקשורות ל-HTTP/2 בשרתי הקצה העורפי

מוודאים ששרת עורפי (backend instance) תקין ותומך בפרוטוקול HTTP/2. כדי לוודא זאת, אפשר לבדוק את הקישוריות לשרת העורפי (backend instance) באמצעות HTTP/2. מוודאים שהמכונה הווירטואלית משתמשת בחבילות הצפנה שתואמות למפרט HTTP/2. לדוגמה, פרוטוקול HTTP/2 לא מאפשר שימוש בסטים מסוימים של אלגוריתמים להצפנה (cipher suite) מסוג TLS 1.2. אפשר לעיין ברשימה השחורה של סט אלגוריתמים להצפנה (cipher suite) ב-TLS 1.2.

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

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

פתרון בעיות שקשורות לקצה עורפי חיצוני ול-NEG באינטרנט

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

התנועה לא מגיעה לנקודות הקצה

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

  • נקודת הקצה מצורפת ל-NEG של האינטרנט.
  • אפשר לפענח את ה-FQDN המשויך באמצעות DNS (אם משתמשים בסוג נקודת קצה FQDN).
  • אפשר לגשת לנקודת הקצה דרך האינטרנט.

אם התנועה לא מגיעה לנקודת הקצה, מה שגורם לקוד שגיאה 502, צריך לשלוח שאילתה לרשומת ה-DNS TXT‏ _cloud-eoips.googleusercontent.com באמצעות כלי כמו dig או nslookup. שימו לב ל-CIDR (אחרי ip4:) וודאו שהטווחים האלה מותרים בחומת האש או ברשימת בקרת הגישה (ACL) בענן.

אחרי הגדרת backend חיצוני, בקשות ל-backend חיצוני נכשלו עם שגיאת 5xx

  • מסמנים את האפשרות רישום ביומן.
  • מוודאים שקבוצת נקודות הקצה ברשת מוגדרת עם כתובת ה-IP:היציאה או FQDN:היציאה הנכונים עבור ה-Backend החיצוני.
  • אם אתם משתמשים ב-FQDN, ודאו שאפשר לתרגם אותו באמצעות Google Public DNS. כדי לוודא שאפשר לתרגם את ה-FQDN באמצעות Google Public DNS, אפשר לפעול לפי השלבים האלה או להשתמש בממשק האינטרנט ישירות.
  • אם אתם ניגשים למאזן העומסים רק דרך כתובת ה-IP החיצונית שלו, ושרת האינטרנט של המקור מצפה לשם מארח, צריך לוודא שאתם שולחים כותרת HTTP Host תקינה לבק-אנד על ידי הגדרת כותרת בקשה בהתאמה אישית.
  • אם אתם מתקשרים עם קצה עורפי באמצעות HTTPS או HTTP2 (כפי שמוגדר בשדה protocol של שירות הקצה העורפי) שהוגדר כנקודת קצה חיצונית של קצה עורפי INTERNET_FQDN_PORT, ודאו שהמקור שלכם מציג אישור TLS (SSL) תקין וששם הדומיין המלא (FQDN) המוגדר תואם ל-SAN (שם חלופי של בעלים (subject)) ברשימת ה-SAN של האישורים. אישור תקף הוא אישור שנחתם על ידי רשות אישורים ציבורית והתוקף שלו לא פג.
  • כשמשתמשים בנקודות קצה חיצוניות של קצה עורפי INTERNET_FQDN_PORT, מאזן העומסים לא מקבל אישורים בחתימה עצמית ודוחה אותם.
  • כשמשתמשים ב-HTTPS או ב-HTTP/2 עם נקודות קצה מסוג INTERNET_IP_PORT, לא מתבצעת אימות של אישור ה-SSL או בדיקה של SAN. המשמעות היא שאפשר להשתמש באישורים בחתימה עצמית. כשמשתמשים ב-SSL, מומלץ להשתמש בנקודות קצה של INTERNET_FQDN_PORT כדי לוודא שאפשר לאמת את אישורי השרת ואת שמות ה-SAN.

פתרון בעיות בהחדרת הקוד של שער Google Tag

שער Google Tag לא מוסיף תגים בצורה נכונה או גורם לשגיאות.

כדי לפתור את הבעיה הזו, צריך להשתמש ב Cloud de Confiance מסוף Logs Explorer כדי לנתח את היומנים שנוצרו על ידי מאזן העומסים. בעיות בשער של Google Tag לא משפיעות על קוד התגובה הכולל של HTTP או על statusDetails של בקשת דף האינטרנט. תגובת ה-HTTP תישלח ללא שינוי גם אם ההטמעה של Google Tag תיכשל. כדי לזהות שגיאות בשער, בודקים את grpcStatus של ההרצה של הפלאגין במטען ה-JSON של מאזן העומסים.

מוודאים ש-Cloud Logging מופעל בשירותי הקצה העורפי שמציגים את תוכן האתר בדומיינים שבהם שער Google Tag פעיל. כדי להגדיר את זה במסוף, עוברים אל איזון עומסים > עריכה > הגדרת קצה עורפי. Cloud de Confiance מידע נוסף זמין במאמר הפעלת רישום ביומן בשירות קצה עורפי קיים. צריך להגדיר לשירות הקצה העורפי הזה שיעור דגימה של רישום ביומן שגדול מ-0.0.

  1. במסוף Cloud de Confiance , נכנסים לדף Logs Explorer ובוחרים את הפרויקט הנכון.

    כניסה לדף Logs Explorer

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

  3. כדי לראות יומנים של בקשות שטופלו על ידי תוסף ההזרקה של שער Google Tag, משתמשים בשאילתה הזו:

    resource.type="http_load_balancer" logName="projects/PROJECT_ID/logs/requests"  \
jsonPayload.serviceExtensionInfo.extension="0-google-tag-gateway"

    מחליפים את PROJECT_ID במזהה הפרויקט.

  4. כדי לזהות שגיאות פוטנציאליות, בודקים את השדה jsonPayload.serviceExtensionInfo.perProcessingRequestInfo.grpcStatus. כאן מוצג הסטטוס של תוסף שער Google Tag עצמו.

    • ‫OK: התוסף סיים את העיבוד ללא שגיאת gRPC.
    • כל ערך אחר מלבד OK (לדוגמה, INTERNAL, ‏ UNAVAILABLE, ‏ DEADLINE_EXCEEDED): הערך הזה מציין שיש שגיאה בהרצה של התוסף שער Google Tag.

  5. כדי למצוא יומנים שבהם התוסף שער Google Tag דיווח על שגיאה, משתמשים בשאילתה הבאה:

    resource.type="http_load_balancer" logName="projects/PROJECT_IDlogs/requests" \
jsonPayload.serviceExtensionInfo.extension="0-google-tag-gateway" NOT jsonPayload.serviceExtensionInfo.perProcessingRequestInfo.grpcStatus="OK"

  6. כשהשאילתה הקודמת מחזירה תוצאות, בודקים את כל רשומת היומן כדי לקשר בין סטטוס התוסף לבין תוצאת הבקשה:

    • כשל בהרחבת שער Google Tag: אם מופיע grpcStatus שונה מ-OK (במיוחד באירוע RESPONSE_BODY), המשמעות היא שבתהליך החדרה של התג אירעה שגיאה. קוד ה-gRPC הספציפי מספק רמזים (לדוגמה, DEADLINE_EXCEEDED מציין פסק זמן).
    • ההשפעה על בקשת המשתמש: אם הערך של grpcStatus לתוסף של שער Google Tag הוא לא OK, בודקים את httpRequest.status ואת jsonPayload.statusDetails באותו רשומה ביומן. לדוגמה, אם הערך OK grpcStatus משולב עם httpRequest.status: 500 ו-jsonPayload.statusDetails: service_extensions_error, זה מצביע על כך שהמשתמש קיבל שגיאת שרת בגלל כשל בהרחבת שער Google Tag.
    • תדירות הבעיה: ניתוח של חותמות הזמן והתדירות של יומני השגיאות האלה עוזר לקבוע אם בעיות בהחדרת שער Google Tag הן מתמשכות, לסירוגין או קשורות לאירועים ספציפיים.

אם נתקלתם בבעיות במהלך ההגדרה שלא מוסברות במסמכי התיעוד, תוכלו לפנות לתמיכה של Google Ads.