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

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

תיאור הבעיה

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

הודעת שגיאה

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

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

אבחון

בקטע הזה מוסבר איך לאבחן נכון מצב של פסק זמן (timeout) בתהליך לחיצת היד של TLS/SSL. הוראות ל-Edge Private Cloud ול-Public Cloud מפורטות כאן.

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

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

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

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

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

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

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

         

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

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

שלבים נוספים לאבחון בעיות למשתמשים ב-Edge Private Cloud בלבד

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

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

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

      telnet BackendServer-IPaddress 443

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

      telnet BackendServer-HostName 443

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

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

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

   /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 Private ו-Public Cloud

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

שלבים נוספים לאבחון בעיות למשתמשי Edge Private Cloud ו-Edge Public Cloud

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

1. אם אתם משתמשי Private Cloud, אתם יכולים ללכוד את מנות ה-TCP/IP בשרת העורפי או במעבד ההודעות. מומלץ לתעד אותם בשרת העורפי, כי החבילות מפוענחות בשרת העורפי.
2. אם אתם משתמשים ב-Public Cloud, אין לכם גישה ל-Message Processor. עם זאת, יכול להיות שתיעוד של מנות 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. מידע על השימוש בפקודה לבדיקת תעבורת נתונים של Message Processor זמין במאמר tcpdump.

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

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

   

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

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 Monitoring. לדוגמה, יכול להיות שתרצו להגדיר התראה שתתקבל אם מספר התקלות מסוג messaging.adaptors.http.BadGateway יעבור סף מסוים.

רזולוציה

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

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

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

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

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

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