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

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

פתרון בעיות נפוצות באמצעות Network Analyzer

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

הכלי Network Analyzer זמין במסוף Google Cloud כחלק מ-Network Intelligence Center.

מעבר אל Network Analyzer

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

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

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 לא מוסברות

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

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

לתגובות עם שגיאת HTTP שבהן statusDetails לא תואם למחרוזת היומן response_sent_by_backend:

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

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

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

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

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

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

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

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

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

    2. בודקים את הערך של השדה statusDetails:

      • אם statusDetails מחזירה הודעת הצלחה, כמו response_sent_by_backend, סימן שהקצה העורפי הוא זה שמחזיר תגובות HTTP 502. בודקים את היומנים בקצה העורפי וממשיכים לפתור את הבעיות בהתאם לשירות שפועל בקצה העורפי.
      • אם הפקודה statusDetails מחזירה הודעת שגיאה, אפשר להיעזר ברשימת הפתרונות הבאה לבעיות נפוצות שקשורות לתגובות 5xx:
      הודעת השגיאה statusDetail סיבות אפשריות ופתרונות
      failed_to_connect_to_backend

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

      המלצות:

      • מגדירים את היציאה של בדיקת התקינות לשימוש ב היציאה למילוי הבקשה. המשמעות היא שהמערכת העורפית תסווג כלא תקינה לפני שהיא תעמוד בדרישות להצגת תנועה אמיתית.
      • משתמשים בפקודה הבאה כדי לוודא שיש שירות שפועל ביציאה עם השם של שירות ה-Backend: 
        $ netstat -tnl | grep PORT
      failed_to_pick_backend

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

      backend_connection_closed_before_data_sent_to_client הקצה העורפי סגר באופן לא צפוי את החיבור שלו למאזן העומסים לפני שהתגובה הועברה באמצעות פרוקסי ללקוח. זה יכול לקרות אם מאזן העומסים שולח תנועה לישות אחרת. יכול להיות שהגורם השני הוא מאזן עומסים של צד שלישי עם פסק זמן ל-TCP שהוא קצר יותר מפסק הזמן של מאזן העומסים. פרטים נוספים זמינים במאמר Timeouts and retries.
      backend_timeout עבר יותר מדי זמן עד שהקצה העורפי הגיב. יכול להיות שהזמן הקצוב לתפוגה של שירות הקצה העורפי קצר מדי בשביל שהשירות יגיב. כדאי לשקול להגדיל את הזמן הקצוב לתפוגה של שירות לקצה העורפי או לבדוק למה לוקח לשירות כל כך הרבה זמן להגיב.

  4. מוודאים שפרמטר ההגדרה keepalive של תוכנת שרת ה-HTTP שפועלת במופע העורפי לא קטן מפרק הזמן הקצוב לתפוגה של keepalive במאזן העומסים, שהערך שלו קבוע על 10 דקות (600 שניות) ולא ניתן להגדרה.

    מאזן העומסים יוצר קוד תגובה HTTP 5XX כשהחיבור לקצה העורפי נסגר באופן בלתי צפוי במהלך שליחת בקשת ה-HTTP או לפני קבלת תגובת ה-HTTP המלאה. זה יכול לקרות כי פרמטר ההגדרה keepalive של תוכנת שרת האינטרנט שפועלת במופע העורפי קטן יותר מהזמן הקצוב הקבוע לתפוגה של keepalive במאזן העומסים. מוודאים שהזמן הקצוב לתפוגה של keepalive בהגדרות של תוכנת שרת ה-HTTP בכל שרת קצה עורפי מוגדר לערך שגדול מעט מ-10 דקות (הערך המומלץ הוא 620 שניות).

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

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

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

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

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

כתובות ה-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.

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

מאזן עומסים חיצוני של אפליקציות לא דוחס או מפסיק לדחוס תשובות בעצמו, אבל הוא יכול להציג תשובות שנוצרו על ידי שירות ה-Backend שלכם שנדחסו באמצעות כלים כמו 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) המוגדר תואם לשם חלופי של בעלים (subject) (SAN) ברשימת ה-SAN של האישורים. אישור תקף הוא אישור שנחתם על ידי רשות אישורים ציבורית והתוקף שלו לא פג.
  • כשמשתמשים בנקודות קצה חיצוניות של קצה עורפי INTERNET_FQDN_PORT, מאזן העומסים לא מקבל אישורים בחתימה עצמית ודוחה אותם.
  • כשמשתמשים ב-HTTPS או ב-HTTP/2 עם נקודות קצה מסוג INTERNET_IP_PORT, לא מתבצעת בדיקה של אישור ה-SSL או של SAN. המשמעות היא שאפשר להשתמש באישורים בחתימה עצמית. כשמשתמשים ב-SSL, מומלץ להשתמש בנקודות קצה של INTERNET_FQDN_PORT כדי לוודא שאפשר לאמת את אישורי השרת ואת שמות ה-SAN.

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

חשוב לוודא:

  • הפעלתם את Cloud CDN בשירות הקצה העורפי שמכיל את ה-NEG שמפנה לקצה העורפי החיצוני, על ידי הגדרת enableCDN לערך true.
  • התשובות שמוגשות על ידי הקצה העורפי החיצוני עומדות בדרישות הקאשינג של Cloud CDN. לדוגמה, אתם שולחים Cache-Control: public, max-age=3600 כותרות תגובה מהמקור.

פתרון בעיות ב-NEG ללא שרת

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

הבקשות נכשלות ומתקבלת שגיאת 404

מוודאים שהמשאב הבסיסי בלי שרת (כמו App Engine, פונקציות של Cloud Run או שירות של Cloud Run) עדיין פועל. אם משאב ללא שרת נמחק אבל ה-NEG ללא שרת עדיין קיים, מאזן העומסים החיצוני של האפליקציה ימשיך לנסות לנתב בקשות לשירות שלא קיים. התוצאה היא תגובה עם שגיאת 404.

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

טיפול בחוסר התאמה של מסכות כתובות URL

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

‫Cloud Run: אם יש אי התאמה במסכת כתובת ה-URL, מאזן העומסים מחזיר שגיאת HTTP 404 (לא נמצא).

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

‫API Gateway: במקרה של אי התאמה של מסכת כתובת URL, מאזן העומסים מחזיר שגיאת HTTP 404 (לא נמצא).

‫App Engine: במקרה של אי התאמה במסכת כתובת ה-URL,‏ App Engine משתמש ב-dispatch.yaml ובלוגיקת הניתוב שמוגדרת כברירת מחדל ב-App Engine כדי לקבוע לאיזה שירות לשלוח את הבקשה.

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

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

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

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

  1. במסוף Google Cloud , נכנסים לדף 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.