במדריך הזה מוסבר איך לפתור בעיות בהגדרות של מאזני עומסים חיצוניים של אפליקציות. לפני שאתם בודקים בעיות, כדאי שתכירו את הדפים הבאים:
- סקירה כללית על מאזן עומסים חיצוני של אפליקציות (ALB)
- רישום ביומן ומעקב אחרי מאזן עומסים גלובלי וקלאסי של אפליקציות (ALB)
- רישום נתונים ביומן ומעקב אחרי הביצועים של מאזן עומסים חיצוני אזורי של אפליקציות (ALB)
פתרון בעיות נפוצות באמצעות Network Analyzer
Network Analyzer עוקב באופן אוטומטי אחרי הגדרות רשת VPC ומזהה הגדרות שגויות או לא אופטימליות. הוא מזהה כשלים ברשת, מספק מידע על שורש הבעיה ומציע פתרונות אפשריים. במאמר תובנות של Network Analyzer שבמסמכי התיעוד של 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 מה-backend. פותרים את הבעיה בקצוות העורפיים. - אם
statusDetailsהיא הודעת שגיאה אחרת, התגובה 5XX נוצרת על ידי מאזן העומסים.
שינויים בהגדרות של מאזן העומסים החיצוני הגלובלי של אפליקציות (ALB), כמו הוספה או הסרה של שירות לקצה העורפי, יכולים לגרום לתקופה קצרה שבה מוצגות תגובות HTTP 502 עם statusDetails בתור failed_to_pick_backend. זה מצב תקין בזמן הפצת השינויים בהגדרות ל-GFE ברחבי העולם.
לפני שמתחילים לפתור בעיות, צריך לבדוק את תקינות הקצה העורפי
לפני שפותרים שגיאות 5XX, צריך לוודא שה-backends תקינים ושהם עוברים את בדיקות התקינות. אם ה-backends לא תקינים, ה-GFE בשכבה השנייה לא יכול להעביר אליהם בקשות, מה שעלול לגרום לשגיאות 5XX גם אם כל השאר מוגדר בצורה נכונה.
- מוודאים שמוגדר כלל חומת אש שמאפשר בדיקות תקינות. אם אין כלל כזה, בדיקות התקינות נכשלות וביומנים של מאזן העומסים יכול להופיע
statusDetailsשלfailed_to_pick_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_backendfailed_to_pick_backend_by_hash |
הסיבה: ה-GFE בשכבה השנייה לא הצליח לבחור קצה עורפי תקין לניתוב הבקשה.
השגיאה הזו יכולה להופיע מהסיבות הבאות:
הפתרון:
|
failed_to_connect_to_backend |
הסיבה: ה-GFE בשכבה השנייה לא הצליח ליצור חיבור עם מכונה לקצה העורפי (לא הצליח לקבל SYN-ACK). השגיאה הזו יכולה להיגרם גם בגלל שגיאה פנימית ב-GFE שמונעת ממנו להתחבר לקצה העורפי, או בגלל הפסקה אזורית או שיבוש ברשת (כמו סיב אופטי שנחתך) שמונעים מ-GFE בשכבה הראשונה לתקשר עם GFE בשכבה השנייה.
הפתרון:
|
backend_connection_closed_before_data_sent_to_client |
הסיבה: החיבור בין ה-GFE בשכבה השנייה לבין הקצה העורפי נסגר באופן בלתי צפוי לפני שהתגובה נשלחה ללקוח. הבעיה הזו יכולה להיגרם על ידי שרת האינטרנט בקצה העורפי או מכשיר ביניים.
היא יכולה להתרחש גם כשמשתמשים ב-GKE אם הפודים מצטמצמים אנכית בהתאם לעומס (scale down) או מסתיימים, וה-backends של מאזן העומסים הם מסוג NEG.
הפתרון:
|
backend_timeout |
הסיבה: שרת GFE בשכבה השנייה יצר חיבור עם הקצה העורפי, אבל הקצה העורפי לא שלח תשובה במסגרת זמן הקצוב לתפוגה של שירות הקצה העורפי שהוגדר.
הפתרון:
|
retriable_error |
הסיבה: שגיאת 503 יכולה להתרחש אם כלים של תשתית כקוד (כמו Terraform) מעדכנים את הכללים של מאזן העומסים באופן שמסיר באופן זמני את הכללים של מפת URL לפני שהם מתווספים מחדש, או בגלל בעיות פנימיות זמניות ברשת או בהגדרות של Google במהלך השקות או דחיפות של הגדרות.
הפתרון:
|
פתרון שגיאות HTTP 408
בתנועת HTTP, משך הזמן המקסימלי להשלמת שליחת הבקשה של הלקוח שווה לזמן הקצוב לתפוגה של שירות לקצה העורפי. אם אתם רואים תגובות HTTP 408 עם jsonPayload.statusDetail client_timed_out, זה אומר שלא הייתה התקדמות מספקת בזמן שהבקשה מהלקוח או התגובה מה-backend הועברו דרך שרת 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. אם האובייקט לא קיים, תופיע הודעת השגיאה הבאה במקום האובייקט:
NoSuchKeyThe specified key does not exist.
הדחיסה לא עובדת
מאזן עומסים חיצוני של אפליקציות (ALB) לא דוחס או מחלץ תגובות בעצמו, אבל הוא יכול להציג תגובות שנוצרו על ידי שירות לקצה העורפי ונדחסו באמצעות כלים כמו gzip או DEFLATE.
אם התגובות שמוצגות על ידי מאזן העומסים לא דחוסות אבל אמורות להיות דחוסות, ודאו שתוכנת שרת האינטרנט שפועלת במכונות שלכם מוגדרת לדחוס תגובות. כברירת מחדל, תוכנות מסוימות של שרתי אינטרנט משביתות באופן אוטומטי את הדחיסה של בקשות שכוללות כותרת Via, שמציינת שהבקשה הועברה על ידי שרת proxy. מכיוון שמדובר בשרת proxy, מאזן העומסים החיצוני של אפליקציות מוסיף כותרת Via לכל בקשה, כפי שנדרש במפרט ה-HTTP.
כדי להפעיל דחיסה, יכול להיות שתצטרכו לשנות את הגדרת ברירת המחדל של שרת האינטרנט, כך שהוא ידחוס את התשובות גם אם לבקשה יש כותרת Via.
כדי להגדיר קצוות עורפיים של nginx שיציגו תשובות דחוסות דרך שרת proxy באמצעות מאזן עומסים חיצוני של אפליקציות (ALB):
- מגדירים את ההוראה
gzip_proxiedבאופן מתאים (לדוגמה, לערךany), וגם - מגדירים את ההוראה
gzip_varyלערךon.
כדי להגדיר שרתי בק-אנד של Apache שיציגו תגובות דחוסות דרך שרת proxy באמצעות מאזן עומסים של אפליקציות (ALB) חיצוני:
- משתמשים במסנן
DEFLATE, וגם - מוסיפים את
Vary Accept-Encodingלכותרת התגובה באמצעות המודולmod_headers.
פתרון בעיות בקצוות עורפיים לא תקינים
פתרון בעיות שקשורות ל-HTTP/2 בקצוות העורפיים
מוודאים ששרת עורפי (backend instance) תקין ותומך בפרוטוקול HTTP/2. כדי לוודא שהשרת העורפי תומך ב-HTTP/2, אפשר לבדוק את הקישוריות אליו באמצעות HTTP/2. מוודאים שהמכונה הווירטואלית משתמשת בסט אלגוריתמים להצפנה (cipher suite) שתואם למפרט של HTTP/2. לדוגמה, סטים מסוימים של אלגוריתמים להצפנה (cipher suite) מסוג TLS 1.2 אסורים ב-HTTP/2. עיינו ברשימת החסימה של סט אלגוריתמים להצפנה (cipher suite) ב-TLS 1.2.
אחרי שמוודאים שה-VM משתמש בפרוטוקול HTTP/2, צריך לוודא שהגדרת חומת האש מאפשרת לבודק התקינות ולמאזן העומסים לעבור.
אם אין בעיות בהגדרת חומת האש, צריך לוודא שמאזן העומסים מוגדר לתקשר עם היציאה הנכונה ב-VM.
פתרון בעיות של ניתוקים בחיבור ללקוחות שפועלים מאחורי NAT ברמת ספק (CGNAT)
כשלקוח מתחבר למאזן עומסים חיצוני של אפליקציות (ALB) דרך מכשיר ביניים עם שמירת מצב, כמו NAT ברמת ספק (CGNAT), ה-CGNAT עוקב אחרי כל חיבור TCP פעיל בטבלת מצבים. בהרבה CGNATs נאכף זמן קצוב קצר לתפוגה במצב חוסר פעילות – קצר יותר גם מזמן הקצוב לתפוגה של keepalive ב-HTTP של הלקוח במאזן העומסים (610 שניות כברירת מחדל) וגם מהזמן הקצוב לתפוגה של חיבור במצב חוסר פעילות במאגר החיבורים של הלקוח ב-HTTP.
אם החיבור נשאר במצב של חוסר פעילות למשך זמן ארוך יותר מזמן הקצוב לתפוגה של CGNAT, ה-CGNAT מסיר את רשומת החיבור מטבלת המצבים שלו בלי לשלוח חבילת TCP FIN או RST לאף אחת מנקודות הקצה. מכיוון שגם הלקוח וגם מאזן העומסים עדיין מחשיבים את החיבור כפתוח, בקשת ה-HTTP הבאה שהלקוח שולח דרך החיבור הזה נדחית על ידי ה-CGNAT, והבקשה נכשלת.
כדי למנוע ניתוקים שקטים של לקוחות שפועלים מאחורי CGNAT או מכשירים אחרים עם שמירת מצב, אתם יכולים לבצע אחת מהפעולות הבאות:
מקצרים את זמן הקצוב לתפוגה של חיבורים לא פעילים במאגר החיבורים של צד הלקוח ב-HTTP, כך שיהיה קצר יותר גם מהזמן הקצוב לתפוגה של חיבורים לא פעילים ב-CGNAT וגם מהזמן הקצוב לתפוגה של אותות Keepalive ב-HTTP של צד הלקוח במאזן העומסים. כך צד הלקוח יסגור חיבורים לא פעילים בצורה תקינה לפני שתוקף מצב ה-NAT יפוג.
מגדירים אותות חיים (keepalive) ברמת האפליקציה (כמו מסגרות
PINGתקופתיות של HTTP/2) במרווחים קצרים יותר מהזמן הקצוב לתפוגה של CGNAT (אבל לפחות 30 שניות בין מסגרותPINGבחיבורים לא פעילים כדי להימנע מהגבלת קצב של יצירת בקשות). מסגרותPINGשל HTTP/2 לא מאפסות את הזמן הקצוב לתפוגה של keepalive ב-HTTP של הלקוח במאזן העומסים כשאין זרמים פעילים, אבל הן שומרות על מיפוי ה-NAT המתווך פעיל, כך שהחיבור נשאר תקין או יכול להיסגר בצורה תקינה.מקצרים את מרווח הזמן של TCP keepalive במערכת ההפעלה בצד הלקוח (לדוגמה,
net.ipv4.tcp_keepalive_timeב-Linux) לערך קצר יותר מזמן הקצוב לתפוגה של חוסר פעילות ב-CGNAT, כדי שדגימות TCP יוצאות תקופתיות ימנעו את הזמן הקצוב לתפוגה של מיפוי ה-NAT. חשוב לזכור ששאילתות TCP keepalive מעובדות בשכבת התעבורה, ולא מאפסות את זמן הקצוב לתפוגה של HTTP keepalive של הלקוח במאזן העומסים.
פתרון בעיות ב-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, מה שגורם לקצה העורפי להמתין ללא הגבלת זמן. לפי מפרט gRPC over HTTP/2, חובה לציין את סוף הסטרימינג (EOS) באמצעות הדגל END_STREAM בפריים האחרון של DATA שהתקבל.
כדי למנוע את הבעיה הזו, שבה שרת בק-אנד נתקע והחיבור נשאר פתוח עד שהלקוח סוגר אותו בכוח על ידי שליחת RST_STREAM, אפשר להשתמש באחד מהפתרונות הבאים:
להוסיף השהיה קצרה (לדוגמה, 10 אלפיות השנייה או יותר) בצד הלקוח לפני הסגירה החלקית של הסטרימינג. כך מאזן העומסים לא יכול למזג את הפריימים, כי הפריים
HEADERSכבר הועבר.צריך לוודא שהלקוח שולח לפחות הודעת נתונים אחת לפני סגירה חלקית של הסטרימינג.
אם אפשר, עברו למאזן עומסים אזורי חיצוני של אפליקציות (ALB), שלא ממזג את המסגרת
HEADERSעם מסגרתDATAריקה, ומעביר אותן בנפרד.
פתרון בעיות בקצה עורפי חיצוני ובקבוצות של נקודות קצה ברשת (NEG) באינטרנט
לפני שאתם בודקים את הבעיות, כדאי שתכירו את הדפים הבאים:
- סקירה כללית על קבוצות NEG באינטרנט
- הגדרת מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) עם קצה עורפי חיצוני (קבוצת נקודות קצה ברשת באינטרנט)
- הגדרת מאזן עומסים חיצוני אזורי של אפליקציות (ALB) עם קצה עורפי חיצוני (קבוצת נקודות קצה באינטרנט)
התנועה לא מגיעה לנקודות הקצה (endpoints)
אחרי שמגדירים שירות, אפשר להגיע לנקודת הקצה החדשה דרך מאזן העומסים החיצוני של אפליקציות (ALB) כשמתקיימים התנאים הבאים:
- נקודת הקצה מצורפת ל-NEG באינטרנט.
- אפשר לפענח את ה-DNS של ה-FQDN המשויך (אם אתם משתמשים בנקודת קצה מסוג FQDN).
- אפשר לגשת לנקודת הקצה דרך האינטרנט.
אם התנועה לא יכולה להגיע לנקודת הקצה, וכתוצאה מכך מתקבל קוד השגיאה 502, צריך לשלוח שאילתה לרשומת ה-TXT של ה-DNS של _cloud-eoips.googleusercontent.com באמצעות כלי כמו dig או nslookup. שימו לב ל-CIDR (אחרי ip4:) וודאו שהטווחים האלה מותרים על ידי חומת האש או רשימת בקרת הגישה (ACL) לענן.
אחרי שמגדירים בקצה העורפי החיצוני, הבקשות לקצה העורפי החיצוני נכשלות עם שגיאת 5xx
- מסמנים את האפשרות רישום ביומן.
- מוודאים שקבוצת נקודות הקצה ברשת מוגדרת עם כתובת ה-IP והיציאה או ה-FQDN והיציאה הנכונים של הקצה העורפי החיצוני.
- אם אתם משתמשים ב-FQDN, ודאו שאפשר לתרגם אותו באמצעות Google Public DNS. כדי לוודא שאפשר לתרגם את ה-FQDN באמצעות Google Public DNS, אתם יכולים לפעול לפי השלבים האלה או להשתמש ישירות בממשק האינטרנט.
- אם אתם ניגשים למאזן העומסים רק בכתובת ה-IP החיצונית שלו, ושרת האינטרנט של המקור מצפה לשם מארח, ודאו שאתם שולחים כותרת מארח HTTP חוקית לקצה העורפי על ידי הגדרה של כותרת בקשה בהתאמה אישית.
- אם אתם מתקשרים עם קצה עורפי באמצעות HTTPS או HTTP2 (כפי שמוגדר בשדה
protocolשל שירות הקצה העורפי) שמוגדר כנקודת קצה חיצונית של קצה עורפי מסוגINTERNET_FQDN_PORT, ודאו שהמקור מציג אישור TLS (SSL) תקף ושה-FQDN שהוגדר תואם ל-SAN (שם חלופי של בעלים) ברשימת ה-SAN של האישורים. אישור תקף הוא אישור שחתום על ידי רשות אישורים ציבורית ועדיין לא פג תוקפו. - כשמשתמשים בנקודות קצה של בקאנד חיצוני ב-
INTERNET_FQDN_PORT, מאזן העומסים לא מקבל אישורי חתימה עצמית והם נדחים. - כשמשתמשים ב-HTTPS או ב-HTTP/2 עם נקודות קצה מסוג
INTERNET_IP_PORT, לא מתבצע אימות של אישור SSL או בדיקת SAN. כלומר, אפשר להשתמש באישורים בחתימה עצמית. כשמשתמשים ב-SSL, מומלץ להשתמש בנקודות קצה (endpoints) שלINTERNET_FQDN_PORTכדי לוודא שאפשר לאמת את אישורי השרת ואת ה-SAN.
התשובות מהקצה העורפי החיצוני שלי לא נשמרות במטמון על ידי Cloud CDN
חשוב לוודא ש:
- הפעלתם את Cloud CDN בשירות לקצה העורפי שמכיל את ה-NEG שמפנה לקצה העורפי החיצוני, על ידי הגדרת enableCDN כ-true.
- התשובות שמוצגות על ידי הקצה העורפי החיצוני עומדות בדרישות השמירה במטמון של Cloud CDN. לדוגמה, אתם שולחים כותרות תגובה מסוג
Cache-Control: public, max-age=3600מהמקור.
פתרון בעיות בקבוצות NEG ללא שרת (serverless)
לפני שאתם בודקים את הבעיות, כדאי שתכירו את הדפים הבאים:
- סקירה כללית על קבוצות NEG ללא שרת (serverless)
- הגדרת מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) עם קבוצות NEG ללא שרת (serverless)
הבקשות נכשלות ומתקבלת שגיאה 404
מוודאים שהמשאב הבסיסי בלי שרת (כמו שירות App Engine, פונקציות Cloud Run או Cloud Run) עדיין פועל. אם המשאב ללא שרת נמחק אבל קבוצת נקודות הקצה ללא שרת עדיין קיימת, מאזן העומסים החיצוני של האפליקציה ימשיך לנסות לנתב בקשות לשירות שלא קיים. התוצאה היא תגובת 404.
באופן כללי, מאזן עומסים חיצוני של אפליקציות (ALB) לא יכול לזהות אם המשאב הבסיסי ללא שרת פועל כמו שצריך. כלומר, אם השירות שלכם באזור מסוים מחזיר שגיאות אבל התשתית הכוללת של Cloud Run, פונקציות Cloud Run או App Engine באותו אזור פועלת כרגיל, מאזן העומסים של אפליקציות (ALB) החיצוני לא יפנה באופן אוטומטי את התנועה לאזורים אחרים. חשוב לבדוק ביסודיות גרסאות חדשות של השירותים לפני שמנתבים אליהם את תנועת המשתמשים.
טיפול באי-התאמות של מסכת כתובות URL
אם החלת מסכת כתובת ה-URL שהוגדרה על כתובת URL של בקשת משתמש לא מניבה שם שירות, או אם היא מניבה שם שירות שלא קיים, מאזן העומסים עשוי לטפל בחוסר ההתאמה הזה באופן שונה בהתאם לפלטפורמת המחשוב בלי שרת שבה משתמשים.
Cloud Run: אם יש אי-התאמה למסכת כתובת ה-URL, מאזן העומסים מחזיר שגיאת HTTP 404 (Not Found).
פונקציות Cloud Run: אם יש חוסר התאמה במסכת כתובת ה-URL, מאזן העומסים מחזיר שגיאת HTTP 404 (לא נמצא).
API Gateway: אם יש אי-התאמה למסכת כתובת ה-URL, מאזן העומסים מחזיר שגיאת HTTP 404 (לא נמצא).
App Engine: אם יש אי-התאמה למסכת כתובת ה-URL, App Engine משתמש ב-dispatch.yaml ובלוגיקת הניתוב שמוגדרת כברירת מחדל ב-App Engine כדי לקבוע לאיזה שירות לשלוח את הבקשה.
פתרון בעיות בהחדרת הקוד של שער Google Tag
שער Google Tag לא מוסיף תגים בצורה נכונה או גורם לשגיאות.
כדי לפתור את הבעיה, צריך להשתמש ב-Logs Explorer במסוף Google Cloud כדי לנתח את היומנים שנוצרו על ידי מאזן העומסים. בעיות בשער של Google Tag לא משפיעות על קוד התגובה הכולל של HTTP או על statusDetails של הבקשה לדף האינטרנט. תגובת ה-HTTP תישלח ללא שינוי גם אם הזרקת Google Tag תיכשל. כדי לזהות שגיאות בשער, בודקים את grpcStatus של הפעלת הפלאגין במטען הייעודי (payload) של ה-JSON של מאזן העומסים.
מוודאים ש-Cloud Logging מופעל בשירותי הקצה העורפי שמספקים את תוכן האתר לדומיינים שבהם שער Google Tag פעיל. כדי להגדיר את זה במסוף Google Cloud , עוברים אל איזון עומסים > Edit > Backend configuration.
מידע נוסף זמין במאמר הפעלת רישום ביומן בשירות קיים לקצה העורפי.
צריך להגדיר לשירות הקצה העורפי הזה תדירות דגימה של רישום ביומן שגדולה מ-0.0.
במסוף Google Cloud , נכנסים לדף Logs Explorer ובוחרים את הפרויקט הרצוי.
משנים את טווח התאריכים כך שיכלול את התקופה שבה לדעתכם התרחשו הבעיות. מידע נוסף זמין במאמר שימוש בבורר טווח תאריכים.
כדי לראות את היומנים של הבקשות שטופלו על ידי הפלאגין להזרקת שער Google Tag, משתמשים בשאילתה הזו:
resource.type="http_load_balancer" logName="projects/PROJECT_ID/logs/requests" \ jsonPayload.serviceExtensionInfo.extension="0-google-tag-gateway"
מחליפים את
PROJECT_IDבמזהה הפרויקט.כדי לזהות שגיאות אפשריות, בודקים את השדה
jsonPayload.serviceExtensionInfo.perProcessingRequestInfo.grpcStatus. כאן מוצג הסטטוס של תוסף שער Google Tag עצמו.-
OK: התוסף סיים את העיבוד בלי שגיאת gRPC. - כל ערך אחר חוץ מ-
OK(לדוגמה,INTERNAL,UNAVAILABLE,DEADLINE_EXCEEDED): מציין שגיאה בהפעלת התוסף של שער Google Tag.
-
כדי למצוא יומנים שבהם התוסף של שער 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"
כשהשאילתה הקודמת מחזירה תוצאות, בודקים את כל רשומת היומן כדי להתאים בין סטטוס התוסף לתוצאת הבקשה:
- כשל בתוסף של שער Google Tag: ערך
grpcStatusשונה מ-OK(במיוחד באירועRESPONSE_BODY) מציין שאירעה שגיאה בתהליך החדרת התג. קוד ה-gRPC הספציפי מספק רמזים (לדוגמה,DEADLINE_EXCEEDEDמציין זמן קצוב לתפוגה). - ההשפעה על בקשת המשתמש: אם הערך של
grpcStatusבתוסף השער של Google Tag הוא לאOK, צריך לבדוק אתhttpRequest.statusואתjsonPayload.statusDetailsבאותה רשומה ביומן. לדוגמה, אם הערך שלgrpcStatusהוא לאOK, בשילוב עםhttpRequest.status: 500ו-jsonPayload.statusDetails: service_extensions_error, זה מצביע על כך שהמשתמש קיבל שגיאה בחיבור לשרת בגלל כשל בתוסף השער של Google Tag. - תדירות הבעיה: ניתוח חותמות הזמן והתדירות של יומני השגיאות האלה עוזר לקבוע אם הבעיות בהחדרת שער Google Tag הן מתמשכות, לסירוגין או קשורות לאירועים ספציפיים.
- כשל בתוסף של שער Google Tag: ערך
אם נתקלתם בבעיות במהלך ההגדרה שלא הצלחתם לפתור בעזרת המאמרים, אתם יכולים לפנות לתמיכה של Google Ads.