אתם צופים במסמכי העזרה של 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 | זמן קצוב חלף במהלך לחיצת היד של TLS/SSL בין מעבד ההודעות לבין שרת הקצה העורפי. | משתמשים בענן הפרטי ובענן הציבורי של Edge |
סיבה: זמן קצוב לתפוגה של לחיצת יד בפרוטוקול TLS/SSL
ב-Apigee Edge אפשר להגדיר חיבור TLS/SSL לשרת הקצה העורפי כדי לאפשר תקשורת TLS בין מעבד ההודעות של Edge לבין שרת קצה עורפי.
לחיצת יד בפרוטוקול TLS/SSL כוללת כמה שלבים. השגיאה הזו מתרחשת בדרך כלל כשהזמן פג לחיצת היד של TLS/SSL בין מעבד ההודעות לשרת לקצה העורפי.
אבחון
בקטע הזה נסביר איך לאבחן בצורה נכונה זמן קצוב לתפוגה של לחיצת יד TLS/SSL. מוצגות הוראות לענן פרטי Edge ולענן ציבורי.
בדיקת הפלט של סשן המעקב
בשלבים הבאים נסביר איך לבצע אבחון ראשוני של הבעיה באמצעות הכלי Apigee Edge Trace.
- בממשק המשתמש של Edge, מפעילים סשן מעקב בשביל שרת ה-proxy של ה-API המושפע.
אם ברשימת המעקב של בקשת ה-API שנכשלה מוצגים הפרטים הבאים, סביר להניח שאירעה שגיאת זמן קצוב לתפוגה של לחיצת יד בפרוטוקול TLS או SSL. הסיבה הסבירה לשגיאה היא שחומת האש של שרת הקצה העורפי חוסמת את התנועה מ-Apigee.
- בודקים אם השגיאה 502 Bad Gateway מתרחשת אחרי 55 שניות, שהיא פרק הזמן שמוגדרת כברירת מחדל כזמן קצוב לתפוגה במעבד ההודעות. אם השגיאה התרחשה אחרי 55 שניות, סביר להניח שהסיבה לבעיה היא זמן קצוב לתפוגה.
- בודקים אם השגיאה כוללת את השגיאה: messaging.adaptors.http.BadGateway. שוב, השגיאה הזו בדרך כלל מצביעה על זמן קצוב פג.
אם אתם משתמשים ב-Edge Private Cloud, שימו לב לערך של השדה X-Apigee.Message-ID בפלט המעקב, כפי שמופיע בהמשך. משתמש ב-Private Cloud יכול להשתמש בערך המזהה הזה כדי לבצע פעולות נוספות לפתרון בעיות, כפי שמוסבר בהמשך.
לוחצים על הסמל Analytics Data Recorded (נתוני Analytics שתועדו) בנתיב המעקב:
גוללים למטה ובודקים את הערך בשדה שנקרא X-Apigee.Message-ID.
כדי לוודא שהסיבה לשגיאה היא זמן קצוב לתפוגה של לחיצת יד TLS/SSL, פועלים לפי השלבים שמפורטים בקטעים הבאים, בהתאם לענן שבו אתם משתמשים – ענן ציבורי או ענן פרטי.
שלבים נוספים לאבחון למשתמשים ב-Edge Private Cloud בלבד
אם אתם משתמשים בענן הפרטי של Apigee Edge, תוכלו לבצע את השלבים הבאים כדי לבדוק מה הגורם לשגיאה בלחיצת היד. בשלב הזה בודקים את קובץ היומן של Message Processor כדי למצוא מידע רלוונטי. אם אתם משתמשים ב-Edge Public Cloud, אתם יכולים לדלג על הקטע הזה ולעבור אל שלבים נוספים לאבחון למשתמשים בענן פרטי ובענן ציבורי.
בודקים אם אפשר להתחבר לשרת הקצה העורפי הספציפי ישירות מכל אחד ממעבדי ההודעות באמצעות הפקודה
telnet
:אם שרת הקצה העורפי מתמקד בכתובת IP אחת, צריך להשתמש בפקודה הבאה:
telnet BackendServer-IPaddress 443
אם שרת הקצה העורפי מקבל כמה כתובות IP, צריך להשתמש בשם המארח של שרת הקצה העורפי בפקודת telnet כפי שמתואר בהמשך:
telnet BackendServer-HostName 443
אם הצלחתם להתחבר לשרת הקצה העורפי ללא שגיאות, ממשיכים לשלב הבא.
אם הפקודה
telnet
נכשלת, צריך לעבוד עם צוות הרשת כדי לבדוק את הקישוריות בין מעבד ההודעות לשרת הקצה העורפי.בודקים את קובץ היומן של 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 Private Cloud וב-Edge Public Cloud
אם הודעת לחיצת היד לא מופיעה בקובץ היומן, עוברים לקטע חובה לאסוף מידע אבחוני.
שלבים נוספים לאבחון למשתמשים בענן הפרטי ובענן הציבורי של Edge
כדי לזהות את הבעיה בצורה מדויקת יותר, אפשר להשתמש בכלי tcpdump כדי לנתח את חבילות ה-TCP/IP ולבדוק אם חל תוקף זמן קצוב במהלך לחיצת היד של TLS/SSL.
- אם אתם משתמשים בענן פרטי, תוכלו לתעד את חבילות ה-TCP/IP בשרת הקצה העורפי או במעבד ההודעות. מומלץ לתעד אותם בשרת הקצה העורפי, כי החבילות מפענחות בשרת הקצה העורפי.
- אם אתם משתמשים ב-Public Cloud, אין לכם גישה למעבד ההודעות. עם זאת, תיעוד החבילות של TCP/IP בשרת הקצה יכול לעזור לכם לאתר את הבעיה.
אחרי שמחליטים איפה לתעד את חבילות ה-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.
מנתחים את חבילות ה-TCP/IP באמצעות הכלי Wireshark או כלי דומה. בצילום המסך הבא מוצגות חבילות TCP/IP ב-Wireshark.
שימו לב בתוצאה של Wireshark שלחיצת היד של TCP בשלושה שלבים מסתיימת בהצלחה ב-3 החבילות הראשונות.
לאחר מכן, מעבד ההודעות שולח את ההודעה 'Client Hello' בחבילה מס' 4.
מכיוון שאין אישור משרת הקצה העורפי, מעבד ההודעות מעביר מחדש את ההודעה "Client Hello" כמה פעמים במנות 5, 6 ו-7 לאחר המתנה של פרק זמן מוגדר מראש.
כשמעבד ההודעות לא מקבל אישור אחרי 3 ניסיונות חוזרים, הוא שולח את הודעת FIN, ACK לשרת העורפי כדי לציין שהוא סוגר את החיבור.
כפי שמוצג בסשן לדוגמה ב-Wireshark, החיבור לקצה העורפי בוצע בהצלחה (שלב 1), אבל חלף הזמן הקצוב לחיצת היד של SSL כי שרת הקצה העורפי אף פעם לא הגיב.
אם ביצעתם את השלבים לפתרון בעיות שמפורטים במדריך הזה והגעתם למסקנה שזמן קצוב לתפוגה גרם לשגיאה של לחיצת היד ב-TLS/SSL, עוברים לקטע פתרון.
שימוש במעקב אחר API כדי לזהות בעיה
בעזרת API Monitoring אפשר לבודד במהירות אזורים בעייתיים כדי לאבחן בעיות של שגיאות, ביצועים וזמן אחזור ואת המקור שלהן, כמו אפליקציות למפתחים, שרתי proxy ל-API, יעדים לקצה העורפי או פלטפורמת ה-API.
הסבר על תרחיש לדוגמה שמראה איך לפתור בעיות מסוג 5xx בממשקי ה-API באמצעות מעקב אחר ממשקי API. לדוגמה, כדאי להגדיר התראה כדי לקבל הודעה כשמספר השגיאות מסוג messaging.adaptors.http.BadGateway חורג מסף מסוים.
רזולוציה
בדרך כלל הזמן הקצוב לתפוגה של לחיצת יד של SSL מתרחש בגלל הגבלות של חומת אש על שרת הקצה העורפי שחוסם את תעבורת הנתונים מ-Apigee Edge. אם פעלתם לפי שלבי האבחון והגעתם למסקנה שהסיבה לשגיאה של לחיצת היד היא זמן קצוב לתפוגה, עליכם לפנות לצוות הרשת כדי לזהות את הסיבה ולתקן את ההגבלות בחומת האש.
חשוב לזכור שאפשר להחיל את ההגבלות של חומת האש בשכבות שונות של הרשת. חשוב לוודא שההגבלות בכל שכבות הרשת בנוגע לכתובות ה-IP של מעבד ההודעות הוסרו, כדי להבטיח זרימת תנועה חלקה בין Apigee Edge לבין שרת הקצה העורפי.
אם אין הגבלות בחומת האש ו/או שהבעיה נמשכת, עוברים אל חובה לאסוף נתוני אבחון.
חובה לאסוף פרטי אבחון
אם הבעיה נמשכת גם אחרי ביצוע ההוראות שלמעלה, עליך לאסוף את פרטי האבחון הבאים. פונים לתמיכה של Apigee Edge ומשתפים את הנתונים:
- אם אתם משתמשים ב-Public Cloud, עליכם לספק את הפרטים הבאים:
- שם הארגון
- שם הסביבה
- שם שרת ה-proxy ל-API
- צריך להשלים את פקודת ה-curl כדי לשחזר את השגיאה
- קובץ מעקב שבו מוצגת השגיאה
- חבילות TCP/IP שתועדו בשרת הקצה העורפי
- אם אתם משתמשים בענן פרטי, עליכם לספק את הפרטים הבאים:
- הודעת השגיאה המלאה שזוהתה
- חבילת proxy ל-API
- קובץ מעקב שבו מוצגת השגיאה
- יומני מעבד הודעות /opt/apigee/var/log/edge-message-processor/logs/system.log
- מנות TCP/IP שנלכדו בשרת הקצה העורפי או במעבד ההודעות.
- פרטים על הקטעים במדריך הזה שניסית, ותובנות נוספות שיעזרו לנו לפתור את הבעיה מהר יותר.