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

כרגע מוצג התיעוד של Apigee Edge.
כניסה למסמכי התיעוד של Apigee X. מידע

תיאור הבעיה

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

הודעת השגיאה

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

HTTP/1.1 502 Bad Gateway

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

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

סיבה אפשרית

הגורם האפשרי לבעיה הזו מפורט בטבלה הבאה:

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

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

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

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

אבחון

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

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

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

1. בממשק המשתמש של Edge, מפעילים סשן מעקב לשרת ה-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 בפלט של נתוני המעקב, כמו שמוצג בהמשך. משתמשי ענן פרטי יכולים להשתמש בערך המזהה הזה להמשך פתרון בעיות, כמו שמוסבר בהמשך.

      1. לוחצים על הסמל נתוני Analytics מתועדים בנתיב המעקב:

         

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

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

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

אם אתם משתמשים בענן הפרטי של Apigee Edge, אתם יכולים לבצע את השלבים הבאים כדי לאמת את הגורם לשגיאה בלחיצת היד. בשלב הזה, בודקים את קובץ היומן של מעבד ההודעות כדי למצוא מידע רלוונטי. אם אתם משתמשים ב-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 ו-Public Cloud

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

1. אם אתם משתמשים בענן פרטי, תוכלו לתעד את חבילות ה-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. לקבלת עזרה בשימוש בפקודה לבדיקת התנועה במעבד ההודעות, ראו 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 Monitoring מאפשר לבודד במהירות אזורים בעייתיים כדי לאבחן שגיאות, ביצועים וזמן אחזור ואת המקור שלהן, כמו אפליקציות למפתחים, שרתי proxy ב-API, יעדים לקצה העורפי או פלטפורמת ה-API.

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

רזולוציה

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

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

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

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

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

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