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

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

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

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

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

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

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

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

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

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

כתובות ה-IP של המקור והיעד של כל חיבור שונות בהתאם לסוג מאזן העומסים החיצוני של האפליקציות שבו אתם משתמשים. פרטים נוספים זמינים במאמר בנושא כתובות ה-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 תקין ותומך בפרוטוקול HTTP/2. כדי לוודא זאת, אפשר לבדוק את הקישוריות למופע של ה-Backend באמצעות HTTP/2. מוודאים שהמכונה הווירטואלית משתמשת בחבילות הצפנה שתואמות למפרט HTTP/2. לדוגמה, פרוטוקול HTTP/2 לא מאפשר שימוש בסטים מסוימים של אלגוריתמים להצפנה (cipher suite) מסוג TLS 1.2. אפשר לעיין ברשימה השחורה של סט אלגוריתמים להצפנה (cipher suite) ב-TLS 1.2.

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

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

פתרון בעיות שקשורות ל-gRPC

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

מאזן העומסים הגלובלי החיצוני של האפליקציות מבצע אופטימיזציה של תעבורת HTTP/2 על ידי מיזוג של מסגרת HEADERS ומסגרת DATA הריקה (עם END_STREAM) מהלקוח למסגרת HEADERS אחת עם END_STREAM לפני העברתה אל העורף. זו אופטימיזציה רגילה של HTTP/2 לפי RFC 7540. מאזן העומסים מבצע את המיזוג הזה של פריימים כשהם מגיעים כמעט בו-זמנית (0 אלפיות השנייה של עיכוב).

חלק מההטמעות של שרת gRPC (כמו grpc-go) לא תומכות בקבלת הדגל END_STREAM בפריים HEADERS, ולכן ה-Backend ממתין ללא הגבלת זמן. במפרט של gRPC over HTTP/2 נדרש באופן מוחלט שסוף הזרם (EOS) יצוין באמצעות הדגל END_STREAM בפריים DATA האחרון שהתקבל.

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

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

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

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

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

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

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

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

  • נקודת הקצה מצורפת ל-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 (שם חלופי לנושא) ברשימת ה-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 Gateway, משתמשים בשאילתה הזו:

    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 Gateway.

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

    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.