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

מוצג המסמך של Apigee Edge.
כניסה למסמכי העזרה של Apigee X. info

תיאור הבעיה

אפליקציית הלקוח מקבלת את השגיאה 502 Bad Gateway. מעבד ההודעות מחזירה את השגיאה הזו לאפליקציית הלקוח כשהיא לא מקבלת תגובה משרת קצה עורפי.

הודעת שגיאה

אפליקציית הלקוח מקבלת את קוד התגובה הבא:

HTTP/1.1 502 Bad Gateway

בנוסף, יכול להיות שתופיע הודעת השגיאה הבאה:

{
 "fault": {
    "faultstring":"Bad Gateway",
    "detail":{
        "errorcode":"messaging.adaptors.http.flow.BadGateway"
    }
 }
}

סיבה אפשרית

הסיבות האפשריות לבעיה הזו מפורטות בטבלה הבאה:

סיבה: זמן קצוב לתפוגה של לחיצת יד בפרוטוקול TLS/SSL

ב-Apigee Edge אפשר להגדיר חיבור TLS/SSL לשרת הקצה העורפי כדי לאפשר תקשורת TLS בין מעבד ההודעות של Edge לבין שרת קצה עורפי.

לחיצת יד בפרוטוקול TLS/SSL כוללת כמה שלבים. השגיאה הזו מתרחשת בדרך כלל כשהזמן פג לחיצת היד של TLS/SSL בין מעבד ההודעות לשרת לקצה העורפי.

אבחון

בקטע הזה נסביר איך לאבחן בצורה נכונה זמן קצוב לתפוגה של לחיצת יד TLS/SSL. מופיעות ההוראות עבור 'ענן פרטי' ו'ענן ציבורי' של Edge.

בדיקת הפלט של סשנים של מעקב

בשלבים הבאים מוסבר איך לבצע אבחון ראשוני של הבעיה באמצעות הכלי Apigee Edge Trace.

1. בממשק המשתמש של Edge, מפעילים סשן מעקב בשביל שרת ה-proxy של ה-API המושפע.

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

   1. קובעים אם השגיאה 502 Bad Gateway מתרחשת אחרי 55 שניות, הוא פרק הזמן הקצוב לתפוגה שמוגדר כברירת מחדל במעבד ההודעות. אם אתם רואים השגיאה התרחשה אחרי 55 שניות, המשמעות היא שהזמן הקצוב לתפוגה היה הוא כנראה הגורם לבעיה.
   2. בודקים אם השגיאה כוללת את השגיאה: messaging.adaptors.http.BadGateway. שוב, השגיאה הזו בדרך כלל מצביעה על זמן קצוב פג.

   3. אם אתם משתמשים ב-Edge Private Cloud, שימו לב לערך השדה X-Apigee.Message-ID בפלט המעקב כפי שמוצג בהמשך. משתמש ב-Private Cloud יכול להשתמש בערך המזהה הזה כדי לבצע פעולות נוספות לפתרון בעיות, כפי שמוסבר בהמשך.

      1. לוחצים על הסמל Analytics Data Record (תיעוד נתונים מ-Analytics) בנתיב המעקב:

         

      2. גוללים למטה ומתעדים את הערך בשדה שנקרא X-Apigee.Message-ID.

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

שלבי אבחון נוספים למשתמשי Edge בענן הפרטי בלבד

אם אתם משתמשים ב-Apigee Edge Private Cloud, תוכלו לבצע את השלבים הבאים כדי לבדוק מה גורם לשגיאה של לחיצת היד. בשלב הזה בודקים את קובץ היומן של Message Processor כדי למצוא מידע רלוונטי. אם אתם משתמשים ב-Edge Public Cloud, אתם יכולים לדלג על הקטע הזה ולעבור אל שלבים נוספים לאבחון למשתמשים בענן פרטי ובענן ציבורי.

1. בודקים אם אפשר להתחבר לשרת הקצה העורפי הספציפי ישירות מכל אחד ממעבדי ההודעות באמצעות הפקודה telnet:

   1. אם שרת הקצה העורפי מתמקד בכתובת IP אחת, צריך להשתמש בפקודה הבאה:

      telnet BackendServer-IPaddress 443

   2. אם שרת הקצה העורפי מקבל כמה כתובות IP, צריך להשתמש בשם המארח של שרת הקצה העורפי בפקודת telnet כפי שמתואר בהמשך:

      telnet BackendServer-HostName 443

   אם הצלחת להתחבר לשרת העורפי ללא שגיאות, אפשר לעבור לשלב הבא.

   אם הפקודה telnet נכשלת, עליכם לפנות לצוות הרשת כדי לבדוק את הקישוריות בין מעבד ההודעות לבין השרת העורפי.

2. בודקים את קובץ היומן של Message Processor כדי למצוא עדות לכשל לחיצת יד. פותחים את הקובץ:

   /opt/apigee/var/log/edge-message-processor/system.log

   ומחפשים את מזהה ההודעה הייחודי (הערך של X-Apigee.Message-ID שנמצא בקובץ המעקב). כאן אפשר לבדוק אם מוצגת הודעת שגיאה של לחיצת יד עם מזהה ההודעה כמו בדוגמה הבאה:

   org:xxx env:xxx api:xxx rev:x messageid:<MESSAGE_ID> NIOThread@1 ERROR HTTP.CLIENT -
   HTTPClient$Context.handshakeTimeout() : SSLClientChannel[Connected: Remote:X.X.X.X:443
   Local:X.X.X.X]@739028 useCount=1 bytesRead=0 bytesWritten=0 age=55221ms lastIO=55221ms
   isOpen=true handshake timeout
   

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

אם הודעת לחיצת היד לא מופיעה בקובץ היומן, צריך לעבור למאמר נדרש איסוף של פרטי אבחון

שלבים נוספים לאבחון למשתמשים בענן הפרטי ובענן הציבורי של Edge

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

1. אם אתם משתמשים בענן פרטי, תוכלו לתעד את חבילות ה-TCP/IP בשרת הקצה העורפי או ב-Message Processor. מומלץ לתעד אותם בשרת הקצה העורפי, כי החבילות מפענחות בשרת הקצה העורפי.
2. אם אתם משתמשים בענן הציבורי, אין לכם גישה להודעה מעבד מידע; עם זאת, תיעוד מנות ה-TCP/IP בשרת העורפי עשוי לעזור לזהות בעיה.

3. אחרי שמחליטים איפה לתעד את חבילות ה-TCP/IP, משתמשים בפרטים הבאים tcpdump הפקודה כדי לתעד חבילות TCP/IP.

   tcpdump -i any -s 0 host <IP address> -w <File name>
   

   • אם לוקחים את חבילות ה-TCP/IP בשרת הקצה העורפי, צריך להשתמש בשדה הציבורי כתובת ה-IP של מעבד ההודעות בפקודה tcpdump. לקבלת עזרה בשימוש כדי לבדוק את תעבורת הנתונים של שרת הקצה העורפי, ראו tcpdump.

   • אם אתם מקבלים את חבילות ה-TCP/IP במעבד ההודעות, צריך להשתמש בכתובת ה-IP הציבורית של שרת הקצה העורפי בפקודה tcpdump. לקבלת עזרה בשימוש בפקודה כדי לבדוק את תעבורת הנתונים של מעבד ההודעות, ראו tcpdump.

   • אם יש מספר כתובות IP לשרת עורפי או למעבד הודעות, אז צריך לנסות להשתמש בפקודת tcpdump אחרת. מידע נוסף על הכלי הזה ועל וריאציות אחרות של הפקודה הזו זמין במאמר tcpdump.

4. ניתוח חבילות ה-TCP/IP באמצעות הכלי Wireshark או כלי דומה. בצילום המסך הבא מוצגות חבילות TCP/IP ב-Wireshark.

   

5. שימו לב בפלט של Wireshark, שלחיצת היד תלת-כיוונית של TCP מסתיימת בהצלחה בשלוש החבילות הראשונות.

6. מעבד ההודעות שולח את "Client Hello" בחבילה מס' 4.

7. מכיוון שאין אישור משרת הקצה העורפי, מעבד ההודעות משדר מחדש את ההודעה 'Client Hello' כמה פעמים בחבילות 5,‏ 6 ו-7 אחרי המתנה למרווח זמן מוגדר מראש.

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

9. כפי שמוצג בסשן לדוגמה ב-Wireshark, החיבור לקצה העורפי בוצע בהצלחה (שלב 1), אבל חלף הזמן הקצוב לחיצת היד של SSL כי שרת הקצה העורפי אף פעם לא הגיב.

אם ביצעתם את השלבים לפתרון בעיות במדריך הזה וגיליתם הזמן הקצוב לתפוגה גרם לשגיאת לחיצת היד של TLS/SSL, יש לעבור אל הקטע פתרון.

שימוש ב-API Monitoring כדי לזהות בעיה

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

הסבר על תרחיש לדוגמה שמראה איך לפתור בעיות מסוג 5xx בממשקי ה-API באמצעות מעקב אחר ממשקי API. לדוגמה, אפשר להגדיר התראה כדי לקבל הודעה כשמספר השגיאות מסוג messaging.adaptors.http.BadGateway חורג מסף מסוים.

רזולוציה

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

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

אם אין הגבלות של חומת אש ו/או הבעיה עדיין נמשכת, עוברים אל נדרש איסוף של פרטי האבחון.

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

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

1. אם אתם משתמשים בענן ציבורי, עליכם לספק את הפרטים הבאים:
   1. שם הארגון
   2. שם הסביבה
   3. שם ה-API של ה-Proxy
   4. פקודה מלאה של curl כדי לשחזר את השגיאה
   5. קובץ מעקב שמציג את השגיאה
   6. חבילות TCP/IP שתועדו בשרת הקצה העורפי
2. אם אתם משתמשים בענן פרטי, עליכם לספק את הפרטים הבאים:
   1. זוהה הודעת שגיאה מלאה
   2. חבילת API Proxy
   3. קובץ מעקב שמציג את השגיאה
   4. יומני מעבד הודעות /opt/apigee/var/log/edge-message-processor/logs/system.log
   5. חבילות TCP/IP שתועדו בשרת הקצה העורפי או ב-Message Processor.
3. פרטים על הקטעים שניסית במדריך הזה ועל תובנות אחרות שיעזרו לנו לפתור את הבעיה במהירות.