502 Bad Gateway - Socket ניתוק

אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע

תיאור הבעיה

אפליקציית הלקוח מקבלת קוד סטטוס של HTTP‏ 502 Bad Gateway עם הקוד ECONNRESET כתגובה לקריאות ל-API ב-Edge Microgateway.

הודעת שגיאה

הלקוח יראה את קוד התגובה הבא:

HTTP/1.1 502 Bad Gateway

התשובה תכלול את הודעת השגיאה הבאה:

{"message":"socket hang up","code":"ECONNRESET"}

גורמים אפשריים

שלבים נפוצים לאבחון

1. בודקים את היומנים של Edge Microgateway:

   /var/tmp/edgemicro-`hostname`-*.log

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

   2021-06-23T03:52:24.110Z [error][0:8000][3][myorg][test]
   [emg_badtarget/flakey/hangup][][][6b089a00-d3d6-11eb-95aa-911f1ee6c684]
   [microgateway-core][][GET][502][socket hang up][ECONNRESET][]

3. אם רמת הרישום ביומן מוגדרת ל-warn או ל-info, יופיע גם המסר [warn] שכולל את שם המארח של שרת היעד והיציאה ברכיב השני. בדוגמה הזו, זהו X.X.X.X:8080, ואפשר להשתמש בו מאוחר יותר כדי ללכוד את tcpdump.

   2021-06-23T03:52:24.109Z
   [warn][X.X.X.X:8080][3][myorg][test][emg_badtarget/flakey/hangup]
   [][][6b089a00-d3d6-11eb-95aa-911f1ee6c684][plugins-middleware]
   [targetRequest error][GET][][socket hang up][ECONNRESET][395]

4. קוד השגיאה [socket hang up][ECONNRESET] מציין ששרת היעד סגר את החיבור עם Edge Microgateway. אפשר לחפש את השגיאה ביומנים כדי לדעת כמה פעמים היא מתרחשת.

הסיבה: הגדרה שגויה של הזמן הקצוב לתפוגה של הודעת keep-alive

אבחון

1. פועלים לפי השלבים שבקטע שלבי אבחון נפוצים ובודקים אם קיבלתם את השגיאה [socket hang up][ECONNRESET].

2. אם כן, כדאי להמשיך לבדוק את הנושא בעזרת tcpdump, כמו שמוסבר בהמשך:

שימוש ב-tcpdump

1. מריצים את הפקודה הבאה כדי ללכוד tcpdump בין Edge Microgateway לבין שרת הקצה העורפי במערכת ההפעלה של המארח של Edge Microgateway:

   tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
   

2. ניתוח הנתונים שtcpdump נאספו:

   פלט לדוגמה של tcpdump: ( הצגת תמונה גדולה יותר)

   

   בדוגמה שלמעלה tcpdump, אפשר לראות את הפרטים הבאים:

   1. במנה 250288, הלקוח שולח בקשה מסוג POST.
   2. בחבילה 250371, השרת משיב עם 200 OK.
   3. במנה 250559, הלקוח שולח ACK.
   4. בחבילה 250560, השרת שולח את ההודעה Continuation.
   5. במנה 250561, הלקוח שולח ACK.
   6. בחבילה 262436, השרת שולח FIN, ACK ללקוח שיוזם את סגירת החיבור. שימו לב שזה בערך חמש שניות אחרי המנה הקודמת (250561).
   7. במנה 262441, הלקוח שולח בקשה נוספת של POST. עם זאת, הפעולה נכשלת כי השרת כבר התחיל לסגור את החיבור. התשובה היא RST בחבילה 262441.

   באותו חיבור נעשה שימוש חוזר לפחות פעם אחת בהצלחה בדוגמה הזו, אבל בבקשה הסופית, השרת יוזם סגירה של החיבור אחרי חמש שניות של זמן השהיה, שמתרחשת באותו זמן שבו הלקוח שלח בקשה חדשה. המשמעות היא שסביר להניח שזמן הקצוב לתפוגה של הודעת keep-alive בשרת העורפי קצר יותר מהערך שהוגדר בלקוח או שווה לו. כדי לוודא את זה, אפשר לעיין במאמר השוואה בין הזמן הקצוב לתפוגה של הודעת keep-alive ב-Edge Microgateway ובשרת הקצה העורפי.

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

1. ל-Edge Microgateway אין מאפיין ספציפי של זמן קצוב לתפוגה של הודעת keep-alive. הערך נקבע לפי מערכת ההפעלה שבה הוא פועל. דוגמאות נפוצות הן Windows,‏ Linux וקונטיינרים של Docker.
2. יכול להיות שההגדרה הזו מותאמת אישית במערכת ההפעלה. צריך לפנות לאדמין. כברירת מחדל, מערכות הפעלה של Linux כוללות פסק זמן של שעתיים לחיבור פעיל.
3. לאחר מכן, בודקים את מאפיין הזמן הקצוב לתפוגה של הודעת keep-alive שהוגדר בשרת הקצה העורפי. נניח שהשרת העורפי מוגדר עם ערך של 10 שניות.
4. אם קובעים שערך הזמן הקצוב לתפוגה של הודעת keep-alive במערכת ההפעלה גבוה יותר מערך המאפיין של הזמן הקצוב לתפוגה של הודעת keep-alive בשרת הקצה העורפי, כמו בדוגמה שלמעלה, אז זה הגורם לשגיאות 502.

רזולוציה

חשוב לוודא שערך המאפיין של הזמן הקצוב לתפוגה של הודעת keep-alive תמיד נמוך יותר במערכת ההפעלה שבה פועל Edge Microgateway בהשוואה לערך שלו בשרת העורפי.

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

שיטה מומלצת

מומלץ מאוד שהרכיבים במורד הזרם תמיד יכללו סף נמוך יותר של זמן קצוב לתפוגה של הודעות keep-alive בהשוואה לשרתים במעלה הזרם, כדי למנוע מרוץ תהליכים ושגיאות מסוג 502. כל קפיצה במורד הזרם צריכה להיות נמוכה מכל קפיצה במעלה הזרם. ב-Edge Microgateway, מומלץ לפעול לפי ההנחיות הבאות:

1. הזמן הקצוב לתפוגה של הודעת keep-alive באפליקציית הלקוח או במאזן העומסים צריך להיות קצר יותר מהזמן הקצוב לתפוגה של הודעת keep-alive ב-Edge Microgateway.

   כדי להגדיר את הזמן הקצוב לתפוגה של הודעת keep-alive ב-Edge Microgateway, מוסיפים את הערך keep_alive_timeout לקובץ ~/.edgemicro/org-env-config.yaml.

   edgemicro:
     keep_alive_timeout: 65000

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

הסיבה: שרת היעד סוגר את החיבור לפני הזמן

אבחון

1. פועלים לפי השלבים שמוסברים במאמר שלבים נפוצים לאבחון ובודקים אם קיבלתם את השגיאה [socket hang up][ECONNRESET].
2. אם כן, כדאי להמשיך לבדוק את העניין בעזרת tcpdump כמו שמוסבר בהמשך.

   הודעת השגיאה [targetRequest error][GET][][socket hang up][ECONNRESET] בדוגמה שלמעלה מציינת שהשגיאה הזו התרחשה בזמן ש-Edge Microgateway שלח את הבקשה לשרת העורפי (היעד). כלומר, Edge Microgateway שלח את בקשת ה-API לשרת הקצה העורפי והמתין לתגובה. עם זאת, שרת הקצה העורפי סגר את החיבור באופן פתאומי לפני ש-Edge Microgateway קיבל תגובה.

3. בודקים את יומני השרת של העורף כדי לראות אם יש שגיאות או מידע שיכלו לגרום לשרת העורף לסיים את החיבור באופן פתאומי. אם מופיעות שגיאות או פרטים, עוברים אל פתרון הבעיה ומתקנים את הבעיה בשרת העורפי.
4. אם לא מצאתם שגיאות או מידע בשרת העורפי, אוספים את הפלט tcpdump בשרת Edge Microgateway:

   tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
   

5. ניתוח הנתונים שtcpdump נאספו:

   פלט לדוגמה של tcpdump: ( הצגת תמונה גדולה יותר)

   

   בדוגמה שלמעלה tcpdump, אפשר לראות את הפרטים הבאים:

   1. בחבילה 4, ‏ Edge Microgateway שלח בקשת GET לשרת היעד.
   2. במנה 5, שרת היעד הגיב עם ACK כדי לאשר את הבקשה.
   3. אבל בחבילה 6, במקום להגיב עם מטען תגובה, שרת היעד שולח FIN, ACK שמתחיל את סגירת החיבור.
   4. החל מחבילה 7, החיבור נסגר באופן הדדי. החיבור נסגר לפני שהתגובה נשלחה, ולכן Edge Microgateway יחזיר את שגיאת ה-HTTP 502 ללקוח.
   5. שימו לב שחותמת הזמן של חבילת 8, 2021-06-23T03:52:24.110Z תואמת לחותמת הזמן שבה השגיאה נרשמה ביומני Edge Microgateway. לעתים קרובות אפשר להשתמש בחותמות הזמן בקובצי היומן ובtcpdump כדי לקשר בין השגיאות לבין החבילות בפועל.

   רזולוציה

   מתקנים את הבעיה בשרת העורפי בהתאם.

   אם הבעיה נמשכת ואתם צריכים עזרה בפתרון בעיות ב-502 Bad Gateway Error או שאתם חושדים שמדובר בבעיה ב-Edge Microgateway, כדאי לעבור אל איסוף מידע לצורך אבחון.

   צריך לאסוף פרטי אבחון

   אם הבעיה נמשכת גם אחרי שמבצעים את ההוראות שלמעלה, צריך לאסוף את פרטי האבחון הבאים ואז לפנות לתמיכה של Apigee Edge:

   • קובצי יומן: תיקיית ברירת המחדל היא /var/tmp, אבל יכול להיות שהיא תוחלף בקובץ הראשי config.yaml (logging > dir parameter). מומלץ לשנות את log > level ל-info לפני שמעבירים את קובצי היומן לתמיכה של Apigee.
   • קובץ תצורה: התצורה העיקרית של Edge Microgateway נמצאת בקובץ ה-YAML בתיקייה של Edge Microgateway שמוגדרת כברירת מחדל, $HOME/.edgemicro. יש קובץ תצורה שמוגדר כברירת מחדל שנקרא default.yaml, ועוד קובץ לכל סביבה ORG-ENV-config.yaml. עליך להעלות את הקובץ הזה במלואו עבור הארגון והסביבה שהושפעו.