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

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

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

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

• מגדירים את הוראת gzip_proxied בצורה מתאימה (למשל, ל-any), ו
• מגדירים את ההוראה gzip_vary לערך on.

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

• משתמשים במסנן DEFLATE, וגם
• מוסיפים Vary Accept-Encoding לכותרת התגובה באמצעות מודול mod_headers.

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

פתרון בעיות שקשורות ל-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.

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

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

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

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

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

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

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

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

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

חשוב לוודא:

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

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

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

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

הבקשות נכשלות ומתקבלת שגיאת 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.