כרגע מוצג התיעוד של Apigee Edge.
כניסה למסמכי התיעוד של
Apigee X. מידע
תיאור הבעיה
אפליקציית הלקוח מקבלת קוד סטטוס HTTP של 502
עם ההודעה
Bad Gateway
כתגובה לקריאות ל-API.
המשמעות של קוד מצב ה-HTTP 502
היא שהלקוח לא מקבל תגובה חוקית מהשרתים העורפיים שאמורים למלא את הבקשה.
הודעות שגיאה
אפליקציית הלקוח מקבלת את קוד התגובה הבא:
HTTP/1.1 502 Bad Gateway
בנוסף, עשויה להופיע הודעת השגיאה הבאה:
{ "fault": { "faultstring": "Unexpected EOF at target", "detail": { "errorcode": "messaging.adaptors.http.UnexpectedEOFAtTarget" } } }
גורמים אפשריים
אחת הסיבות הטיפוסיות לשגיאה 502 Bad Gateway Error
היא השגיאה Unexpected EOF
, שעשויות להיגרם מהסיבות הבאות:
סיבה | פרטים | צעדים שניתנו עבור |
---|---|---|
שרת היעד שהוגדר באופן שגוי | שרת היעד לא מוגדר כראוי לתמיכה בחיבורי TLS/SSL. | משתמשי Edge הציבוריים והפרטיים |
חריגת EOF משרת הקצה העורפי | שרת הקצה העורפי עשוי לשלוח EOF באופן פתאומי. | למשתמשי ענן פרטי של Edge בלבד |
הזמן הקצוב לתפוגה שמוגדר באופן שגוי | שמירת זמנים קצובים לתפוגה פעילים שהוגדרו באופן שגוי ב-Apigee ובשרת הקצה העורפי. | משתמשי Edge הציבוריים והפרטיים |
שלבים נפוצים באבחון
כדי לאבחן את השגיאה, אפשר להשתמש בכל אחת מהשיטות הבאות:
מעקב באמצעות API
כדי לאבחן את השגיאה באמצעות API Monitoring:
באמצעות API Monitoring אפשר לבדוק את השגיאות של 502
על ידי ביצוע השלבים שמתוארים במאמר בדיקת בעיות. כלומר:
- עוברים למרכז הבקרה חקירה.
- צריך לבחור את קוד הסטטוס בתפריט הנפתח ולוודא שבחרת את תקופת הזמן הנכונה שבה אירעו השגיאות מסוג
502
. - אם מוצג מספר גבוה של שגיאות
502
, לוחצים על התיבה במטריצה. - בצד שמאל, לוחצים על הצגת יומנים כדי להציג את השגיאות
502
, שייראו בערך כך: - מקור התקלה הוא
target
- קוד התקלה הוא
messaging.adaptors.http.UnexpectedEOFAtTarget
כאן אפשר לראות את הפרטים הבאים:
ערך זה מציין שהשגיאה 502
נגרמה על ידי היעד עקב EOF לא צפוי.
בנוסף, כדאי לרשום את Request Message ID
של השגיאה 502
כדי להמשיך
את הבדיקה.
כלי המעקב
כדי לאבחן את השגיאה באמצעות כלי המעקב:
- מפעילים את
סשן המעקב ומבצעים את הקריאה ל-API כדי לשחזר את הבעיה
502 Bad Gateway
. - בוחרים אחת מהבקשות שנכשלו ובודקים את המעקב.
- אפשר לנווט בשלבים השונים של המעקב ולאתר את המיקום שבו אירעה הכשל.
-
הכשל אמור להופיע לאחר שליחת הבקשה לשרת היעד באופן הבא:
-
קובעים את הערך של X-Apigee.fault-source ו-X-Apigee.fault-code בשלב של AX (נתוני Analytics שנרשמו) במסגרת המעקב.
אם הערכים של X-Apigee.fault-source ו-X-Apigee.fault-code תואמים לערכים שמוצגים בטבלה הבאה, אפשר לוודא שהשגיאה
502
מגיעה משרת היעד:כותרות תגובה Value X-Apigee.fault-source target
X-Apigee.fault-code messaging.adaptors.http.flow.UnexpectedEOFAtTarget
כמו כן, כדאי לרשום את
X-Apigee.Message-ID
של השגיאה502
כדי להמשיך בבדיקת הבעיה.
יומני הגישה של NGINX
כדי לאבחן את השגיאה באמצעות NGINX:
אפשר גם לעיין ביומני הגישה של NGINX כדי לקבוע את הסיבה לקוד הסטטוס 502
. האפשרות הזו שימושית במיוחד אם הבעיה התרחשה בעבר או אם הבעיה מתרחשת לסירוגין ולא ניתן לתעד את נתוני המעקב בממשק המשתמש. כדי למצוא את המידע הזה ביומני הגישה של NGINX, צריך לפעול לפי השלבים הבאים:
- כדאי לבדוק את יומני הגישה של NGINX.
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
- חיפוש שגיאות
502
לשרת ה-API הספציפי במהלך פרק זמן ספציפי (אם הבעיה אירעה בעבר) או לבקשות שעדיין נכשלות עם502
. - אם יש שגיאות מסוג
502
, צריך לבדוק אם השגיאה נגרמת על ידי היעד ששולחUnexpected EOF
. אם הערכים של X-Apigee.fault-source ו-X- Apigee.fault-code תואמים לערכים שמוצגים בטבלה שלמטה, השגיאה502
נגרמת כאשר היעד סגר את החיבור באופן בלתי צפוי:כותרות תגובה Value X-Apigee.fault-source target
X-Apigee.fault-code messaging.adaptors.http.flow.UnexpectedEOFAtTarget
הנה רשומה לדוגמה שמציגה את השגיאה
502
שנגרמה על ידי שרת היעד:
בנוסף, מומלץ לרשום את מזהי ההודעות של השגיאות 502
כדי שנוכל לבדוק את הנושא לעומק.
הסיבה: שרת היעד הוגדר באופן שגוי
שרת היעד לא מוגדר כראוי לתמיכה בחיבורי TLS/SSL.
אבחון
- משתמשים בAPI Monitoring, בכלי המעקב או ביומני הגישה של NGINX כדי לאתר את מזהה ההודעה, קוד השגיאה ומקור התקלה של השגיאה
502
. - יש להפעיל את המעקב בממשק המשתמש עבור ה-API המושפע.
- אם במעקב אחר בקשת ה-API שנכשלה מופיע המידע הבא:
- השגיאה
502 Bad Gateway
מופיעה מיד לאחר ההתחלה של תהליך היעד של הבקשה. - ב-
error.class
מוצגmessaging.adaptors.http.UnexpectedEOF.
סביר להניח שהבעיה הזו נגרמת על ידי הגדרה שגויה של שרת יעד.
- השגיאה
- מקבלים את ההגדרה של שרת היעד באמצעות קריאה ל-Edge Management API:
- אם אתם משתמשים ב-Public Cloud, השתמשו ב-API הזה:
curl -v https://api.enterprise.apigee.com/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>
- אם אתם משתמשים בענן פרטי, השתמשו ב-API הזה:
curl -v http://<management-server-host>:<port #>/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>
דוגמה להגדרה
TargetServer
שגויה:<TargetServer name="target1"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> </TargetServer >
- אם אתם משתמשים ב-Public Cloud, השתמשו ב-API הזה:
-
ההגדרה של
TargetServer
באיור היא דוגמה לאחת מההגדרות השגויות האפשריות, כפי שמוסבר בהמשך:נניח ששרת היעד
mocktarget.apigee.net
מוגדר לקבל חיבורים מאובטחים (HTTPS) ביציאה443
. עם זאת, כשבוחנים את ההגדרה של שרת היעד, אין מאפיינים או סימונים אחרים שמציינים שהוא מיועד לחיבורים מאובטחים. כתוצאה מכך, Edge יתייחס לבקשות ה-API שמועברות לשרת היעד הספציפי כבקשות HTTP (לא מאובטחות). לכן Edge לא יתחיל את תהליך לחיצת היד של SSL עם שרת היעד הזה.מכיוון ששרת היעד מוגדר לקבל רק בקשות HTTPS (SSL) ב-
443
, הוא ידחה את הבקשה מ-Edge או יסגור את החיבור. כתוצאה מכך, מתקבלת שגיאתUnexpectedEOFAtTarget
במעבד ההודעות. מעבד ההודעות ישלח את502 Bad Gateway
כתשובה ללקוח.
רזולוציה
יש לוודא ששרת היעד מוגדר כראוי בהתאם לדרישות שלך.
בדוגמה שמתוארת למעלה, כדי לשלוח בקשות לשרת יעד מאובטח (HTTPS/SSL), עליך לכלול את מאפייני SSLInfo
כאשר הדגל enabled
מוגדר ל-true
. מותר להוסיף את מאפייני SSLInfo
של שרת יעד בתוך ההגדרה של
נקודת הקצה של היעד, אבל מומלץ להוסיף את המאפיינים SSLInfo
כחלק מההגדרה של
שרת היעד כדי למנוע בלבול.
- אם השירות לקצה העורפי דורש תקשורת SSL חד-כיוונית, אז:
- צריך להפעיל את ה-TLS/SSL בהגדרה של
TargetServer
. לשם כך, צריך לכלול את מאפייניSSLInfo
שבהם הדגלenabled
מוגדר כ-True, כפי שמוצג בהמשך:<TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> <SSLInfo> <Enabled>true</Enabled> </SSLInfo> </TargetServer>
- אם רוצים לאמת את האישור של שרת היעד ב-Edge, צריך גם
לכלול את ה-Truststore (שמכיל את האישור של שרת היעד) כמו שמוצג בהמשך:
<TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> <SSLInfo> <Ciphers/> <ClientAuthEnabled>false</ClientAuthEnabled> <Enabled>true</Enabled> <IgnoreValidationErrors>false</IgnoreValidationErrors> <Protocols/> <TrustStore>mocktarget-truststore</TrustStore> </SSLInfo> </TargetServer>
- צריך להפעיל את ה-TLS/SSL בהגדרה של
- אם השירות לקצה העורפי דורש תקשורת SSL דו-כיוונית, אז:
- מאפייני
SSLInfo
עם הדגליםClientAuthEnabled
,Keystore
,KeyAlias
ו-Truststore
צריכים להיות מוגדרים כראוי, כפי שמתואר בהמשך:<TargetServer name="mocktarget"> <IsEnabled>true</IsEnabled> <Host>www.example.com</Host> <Port>443</Port> <SSLInfo> <Ciphers/> <ClientAuthEnabled>true</ClientAuthEnabled> <Enabled>true</Enabled> <IgnoreValidationErrors>false</IgnoreValidationErrors> <KeyAlias>keystore-alias</KeyAlias> <KeyStore>keystore-name</KeyStore> <Protocols/> <TrustStore>truststore-name</TrustStore> </SSLInfo> </TargetServer >
- מאפייני
קובצי עזר
איזון עומסים בין שרתים עורפיים
הסיבה: EOFחריגה משרת הקצה העורפי
שרת הקצה העורפי עשוי לשלוח EOF (סוף הקובץ) פתאום.
אבחון
- משתמשים בAPI Monitoring, בכלי המעקב או ביומני הגישה של NGINX כדי לאתר את מזהה ההודעה, קוד השגיאה ומקור התקלה של השגיאה
502
. - כדאי לבדוק ביומנים של מעבד המידע (
/opt/apigee/var/log/edge-message-processor/logs/system.log
) ולחפש אם ישeof unexpected
עבור ה-API הספציפי, או אם יש לך אתmessageid
הייחודית לבקשת ה-API , אפשר לחפש אותה.דוגמה לדוח קריסות חריג מיומן ההודעות של מעבד ההודעות
"message": "org:myorg env:test api:api-v1 rev:10 messageid:rrt-1-14707-63403485-19 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : SSLClientChannel[C:193.35.250.192:8443 Remote host:0.0.0.0:50100]@459069 useCount=6 bytesRead=0 bytesWritten=755 age=40107ms lastIO=12832ms .onExceptionRead exception: {} java.io.EOFException: eof unexpected at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) ~[nio-1.0.0.jar:na] at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) ~[nio-1.0.0.jar:na] at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:79) ~[http-1.0.0.jar:na] at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) [nio-1.0.0.jar:na] at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:123) [nio-1.0.0.jar:na]"
בדוגמה שלמעלה, אפשר לראות שהשגיאה
java.io.EOFException: eof unexpected
אירעה כשמעבד ההודעות מנסה לקרוא תשובה מהשרת העורפי. החריגה הזו מציינת את סוף הקובץ (EOF) או את סיום השידור באופן בלתי צפוי.כלומר, מעבד ההודעות שלח את בקשת ה-API לשרת הקצה העורפי, והמתין או קרא את התגובה. עם זאת, השרת העורפי סיים את החיבור בפתאומיות לפני שמעבד ההודעות קיבל את התגובה או הצליח לקרוא את התגובה המלאה.
- צריך לבדוק את היומנים של השרת העורפי ולבדוק אם יש שגיאות או מידע שעלולים לגרום לשרת הקצה העורפי לסיים את החיבור בפתאומיות. אם יש שגיאות או מידע, עוברים אל פתרון ומתקנים את הבעיה בשרת הקצה העורפי.
- אם לא מוצאים שגיאות או מידע בשרת הקצה העורפי, אוספים את הפלט
tcpdump
במעבדי ההודעות:- אם למארח של שרת הקצה העורפי יש כתובת IP אחת, משתמשים בפקודה הבאה:
tcpdump -i any -s 0 host IP_ADDRESS -w FILE_NAME
- אם למארח של שרת הקצה העורפי יש כמה כתובות IP, צריך להשתמש בפקודה הבאה:
tcpdump -i any -s 0 host HOSTNAME -w FILE_NAME
בדרך כלל, השגיאה הזו נגרמת כי שרת הקצה העורפי מגיב עם
[FIN,ACK]
, ברגע שמעבד ההודעות שולח את הבקשה לשרת הקצה העורפי.
- אם למארח של שרת הקצה העורפי יש כתובת IP אחת, משתמשים בפקודה הבאה:
-
כדאי לעיין בדוגמה הבאה (
tcpdump
).tcpdump
לדוגמה שנלקחה כאשר התרחש502 Bad Gateway Error
(UnexpectedEOFAtTarget
) - בפלט של TCPDump, ניתן לראות את רצף האירועים הבא:
- בחבילה
985
, מעבד ההודעות שולח את בקשת ה-API לשרת הקצה העורפי. - בחבילה
986
, שרת הקצה העורפי מגיב באופן מיידי עם[FIN,ACK]
. - בחבילה
987
, מעבד ההודעות מגיב באמצעות[FIN,ACK]
לשרת הקצה העורפי. - בסופו של דבר, החיבורים ייסגרו עם
[ACK]
ועם[RST]
משני הצדדים. - מכיוון שהשרת העורפי שולח
[FIN,ACK]
, תקבלו את החריגה החריגהjava.io.EOFException: eof unexpected
למעבד ההודעות.
- בחבילה
- מצב זה עשוי להתרחש אם יש בעיה ברשת בשרת הקצה העורפי. כדאי להיעזר בצוות תפעול הרשת כדי לחקור את הבעיה לעומק.
רזולוציה
יש לתקן את הבעיה בשרת הקצה העורפי כראוי.
אם הבעיה נמשכת ואתם זקוקים לעזרה בפתרון בעיות, 502 Bad Gateway Error
או אם אתם חושדים שמקור הבעיה ב-Edge, תוכלו לפנות לתמיכה של Apigee Edge.
הסיבה: זמן קצוב לתפוגה של שמירת פעיל שהוגדר באופן שגוי
לפני שמנסים לאבחן אם זו הסיבה לשגיאות 502
, כדאי לקרוא את
המושגים הבאים.
חיבורים קבועים ב-Apigee
Apigee כברירת מחדל (ובהמשך בתקן HTTP/1.1) משתמש בחיבורים קבועים במהלך תקשורת עם שרת הקצה העורפי של היעד. חיבורים קבועים יכולים לשפר את הביצועים, כי הם מאפשרים שימוש חוזר בחיבור TCP שכבר קיים ובחיבור TLS (אבטחת שכבת התעבורה) ו-SSL (אם רלוונטי). כך תפחיתו את התקורות של זמן האחזור. משך הזמן שבו יש לשמור על החיבור נשלט באמצעות מאפיין משך הזמן הקצוב לתפוגה (keepalive.timeout.millis
).
הן השרת העורפי והן מעבד ההודעות של Apigee משתמשים בהפסקה של זמן קצוב לתפוגה כדי לשמור על החיבורים פתוחים זה עם זה. אם לא מתקבלים נתונים במשך הזמן הקצוב לתפוגה, שרת הקצה העורפי או מעבד ההודעות יכולים לסגור את החיבור עם הצד השני.
כברירת מחדל, בשרתי proxy של API שנפרסו מעבד הודעות ב-Apigee, הזמן הקצוב לתפוגה של שמירה פעילה מוגדר
כ-60s
, אלא אם בוטל. אם לא יתקבלו נתונים לגבי 60s
, Apigee תסגור את החיבור עם שרת הקצה העורפי. בנוסף, השרת לקצה העורפי ישמור על פרק זמן קצוב לתפוגה,
וברגע שיפוג התוקף של פרק הזמן הזה, החיבור של השרת העורפי יסגור את החיבור למעבד ההודעות.
ההשלכות של הגדרה שגויה של פרק הזמן הקצוב לתפוגה שמוגדר להשאיר פעיל
אם ב-Apigee או בשרת העורפי מוגדרים עם פרקי זמן שגויים של keep-alive, נוצר תנאי ריצה שגורם לשרת הקצה העורפי לשלוח End Of File
(FIN)
לא צפוי בתגובה לבקשת משאב.
לדוגמה, אם הזמן הקצוב לתפוגה של שמירה על פעילות תקינה מוגדר ב-API של שרת ה-proxy או במעבד
ההודעות, עם ערך גדול יותר או שווה לזמן הקצוב לתפוגה של שרת הקצה העורפי ב-upstream, יכול להיות שיתרחש תנאי המרוץ הבא. כלומר, אם מעבד ההודעות לא מקבל נתונים כלשהם עד שהזמן הקצוב לתפוגה של שרת הקצה העורפי יהיה קרוב מאוד לסף, הבקשה נשלחת לשרת הקצה העורפי באמצעות החיבור הקיים. המצב הזה עלול להוביל
ל-502 Bad Gateway
עקב שגיאת EOF לא צפויה, כפי שמוסבר בהמשך:
- נניח שהזמן הקצוב לתפוגה שמוגדר למעבד ההודעות ולשרת הקצה העורפי הוא 60 שניות, ולא התקבלה בקשה חדשה עד 59 שניות אחרי שהבקשה הקודמת נשלחה על ידי מעבד ההודעות הספציפי.
- מעבד ההודעות ממשיך לעבד את הבקשה שהגיעה בשנייה ה-59 באמצעות החיבור הקיים (מכיוון שהזמן הקצוב לתפוגה עדיין לא חלף), ושולח את הבקשה לשרת הקצה העורפי.
- עם זאת, לפני שהבקשה מגיעה לשרת הקצה העורפי, הייתה חריגה מסף הזמן הקצוב לתפוגה בשרת הקצה העורפי.
- הבקשה של מעבד ההודעות לקבלת משאב נמצאת בביצוע, אבל השרת העורפי מנסה לסגור את החיבור על ידי שליחת חבילת
FIN
למעבד ההודעות. - בזמן שמעבד ההודעות ממתין לקבלת הנתונים, הוא מקבל את הערך
FIN
הלא צפוי, והחיבור מתנתק. - התוצאה היא
Unexpected EOF
, ולאחר מכן502
מוחזר ללקוח על ידי מעבד ההודעות.
במקרה הזה, שמנו לב לשגיאה 502
שאירעה כי אותו ערך של זמן קצוב לתפוגה של 60 שניות
של שמירה על פעילות, הוגדר גם במעבד ההודעות וגם בשרת הקצה העורפי. באופן דומה, הבעיה הזו יכולה להתרחש גם אם הוגדר ערך גבוה יותר להפסקה של 'לא פעיל' במעבד ההודעות מאשר בשרת הקצה העורפי.
אבחון
- אם אתם משתמשים ב-Public Cloud:
- להשתמש בכלי API Monitoring או Trace (כפי שמוסבר
בשלבי האבחון הנפוצים) ומוודאים ששתי ההגדרות
הבאות הן:
- קוד תקלה:
messaging.adaptors.http.flow.UnexpectedEOFAtTarget
- מקור התקלה:
target
- קוד תקלה:
- למידע נוסף, יש לעבור אל שימוש ב-tcpdump.
- להשתמש בכלי API Monitoring או Trace (כפי שמוסבר
בשלבי האבחון הנפוצים) ומוודאים ששתי ההגדרות
הבאות הן:
- אם אתם משתמשים בענן פרטי:
- משתמשים בכלי המעקב או ביומני הגישה של NGINX כדי לזהות את מזהה ההודעה, את קוד השגיאה ואת מקור התקלה של השגיאה
502
. - עליך לחפש את מזהה ההודעה ביומן של מעבד ההודעות
(/opt/apigee/var/log/edge-message-processor/logs/system.log
). - יוצג הערך
java.io.EOFEXception: eof unexpected
כמו שמוצג למטה:2020-11-22 14:42:39,917 org:myorg env:prod api:myproxy rev:1 messageid:myorg-opdk-dc1-node2-17812-56001-1 NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : ClientChannel[Connected: Remote:51.254.225.9:80 Local:10.154.0.61:35326]@12972 useCount=7 bytesRead=0 bytesWritten=159 age=7872ms lastIO=479ms isOpen=true.onExceptionRead exception: {} java.io.EOFException: eof unexpected at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:80) at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:220)
- השגיאה
java.io.EOFException: eof unexpected
מציינת שמעבד ההודעות קיבלEOF
בזמן שהמתין לקריאת תשובה מהשרת העורפי. - המאפיין
useCount=7
בהודעת השגיאה שלמעלה מציין שמעבד ההודעות השתמש שוב בחיבור הזה כשבע פעמים, והמאפייןbytesWritten=159
מציין שמעבד ההודעות שלח את המטען הייעודי (payload) של הבקשה בסך159
בייט לשרת הקצה העורפי. עם זאת, הוא קיבל אפס בייט כשאירעה השגיאהEOF
באופן בלתי צפוי. -
זה מראה שמעבד ההודעות השתמש שוב באותו החיבור כמה פעמים, ובמקרה הזה הוא שלח נתונים אבל זמן קצר לאחר מכן הוא קיבל
EOF
לפני שהנתונים התקבלו. פירוש הדבר הוא שקיימת סבירות גבוהה שמשך הזמן הקצוב לתפוגה של שרת הקצה העורפי יהיה קצר יותר או שווה לערך שהוגדר בשרת ה-proxy של ה-API.אפשר להמשיך לחקור בעזרת
tcpdump
כפי שמוסבר בהמשך.
- משתמשים בכלי המעקב או ביומני הגישה של NGINX כדי לזהות את מזהה ההודעה, את קוד השגיאה ואת מקור התקלה של השגיאה
שימוש ב-tcpdump
- לוכדים
tcpdump
בשרת הקצה העורפי באמצעות הפקודה הבאה:tcpdump -i any -s 0 host MP_IP_Address -w File_Name
- ניתוח
tcpdump
שתועד:הנה פלט tcpdump לדוגמה:
בדוגמה
tcpdump
שלמעלה, תוכלו לראות את הפרטים הבאים:- בחבילה
5992,
, שרת הקצה העורפי קיבל בקשה שלGET
. - בחבילה
6064
הוא מגיב באמצעות200 OK.
- בחבילה
6084
, שרת הקצה העורפי קיבל בקשה נוספת שלGET
. - בחבילה
6154
הוא מגיב באמצעות200 OK
. - בחבילה
6228
, שרת הקצה העורפי קיבל בקשתGET
שלישית. - הפעם, שרת הקצה העורפי מחזיר
FIN, ACK
למעבד ההודעות (חבילה6285
) שמתחיל את סגירת החיבור.
בדוגמה הזו נעשה שימוש חוזר באותו חיבור פעמיים, אבל בבקשה השלישית, שרת הקצה העורפי סוגר את החיבור בזמן שמעבד ההודעות ממתין לנתונים משרת הקצה העורפי. משמעות הדבר היא שככל הנראה, הזמן הקצוב לתפוגה של שרת הקצה העורפי הוא קצר יותר או שווה לערך שהוגדר בשרת ה-proxy של ה-API. כדי לוודא זאת, קראו את המאמר השוואה בין פרק הזמן הקצוב לתפוגה של שימוש ב-Apigee ובשרת הקצה העורפי.
- בחבילה
השוואה של הזמן הקצוב לתפוגה של הישארות במצב פעיל ב-Apigee ובשרת קצה עורפי
- כברירת מחדל, Apigee משתמשת בערך של 60 שניות במאפיין הזמן הקצוב לתפוגה של שמירת פעילות.
-
עם זאת, ייתכן ששינית את ערך ברירת המחדל בשרת ה-API של ה-API. כדי לבדוק זאת, יש לבדוק את ההגדרה הספציפית של
TargetEndpoint
בשרת ה-Proxy הנכשל של ה-API, שיוצר שגיאות מסוג502
.הגדרה לדוגמה של TargetEndpoint:
<TargetEndpoint name="default"> <HTTPTargetConnection> <URL>https://mocktarget.apigee.net/json</URL> <Properties> <Property name="keepalive.timeout.millis">30000</Property> </Properties> </HTTPTargetConnection> </TargetEndpoint>
בדוגמה שלמעלה, המאפיין 'זמן קצוב לתפוגה של שמירה במצב פעיל' מבוטל עם ערך של 30 שניות (
30000
אלפיות השנייה). - לאחר מכן, בודקים את מאפיין הזמן הקצוב לתפוגה שמוגדר בשרת הקצה העורפי. נניח
ששרת הקצה העורפי שלכם מוגדר עם הערך
25 seconds
. - אם קבעת שהערך של מאפיין הזמן הקצוב לתפוגה של Keep alive ב-Apigee גבוה יותר מהערך של מאפיין הזמן הקצוב לתפוגה של האירוע keep-alive בשרת הקצה העורפי, כמו בדוגמה שלמעלה, זו הסיבה לשגיאות
502
.
רזולוציה
יש לוודא שמאפיין הזמן הקצוב לתפוגה של תהליך שמירה פעיל תמיד נמוך יותר ב-Apigee (ברכיב ה-API Proxy וברכיב מעבד המידע) בהשוואה לזה שבשרת הקצה העורפי.
- קביעת הערך שהוגדר לזמן הקצוב לתפוגה של 'שמור במצב פעיל' בשרת הקצה העורפי.
- מגדירים ערך מתאים למאפיין של הזמן הקצוב לתפוגה של זמן קצוב לתפוגה ב-API של ה-API או במעבד של ההודעות, כך שמאפיין הזמן הקצוב לתפוגה של אירוע יישאר פעיל יהיה נמוך מהערך שהוגדר בשרת הקצה העורפי. כך עושים את זה: הגדרת הזמן הקצוב לתפוגה של זמן קצוב לתפוגה במעבדי הודעות.
אם הבעיה נמשכת, כדאי לעיין במאמר נדרש איסוף של פרטי אבחון.
שיטה מומלצת
כדי למנוע מצבים כאלה של תנאי מרוץ ושגיאות 502
, מומלץ בחום שהסף של הזמן הקצוב לתפוגה
יהיה נמוך יותר מזה שהוגדר בשרתים של upstream. כל צעד ב-downstream צריך להיות נמוך מכל צעד במעלה הזרם. ב-Apigee Edge מומלץ להשתמש בהנחיות הבאות:
- הזמן הקצוב לתפוגה של לקוח להשאיר פעיל צריך להיות קטן מהזמן הקצוב לתפוגה של נתב Edge.
- הזמן הקצוב לתפוגה של נתב Edge לשמירה על מצב פעיל צריך להיות קטן יותר מהזמן הקצוב לתפוגה של מעבד ההודעות.
- הזמן הקצוב לתפוגה של מעבד ההודעות צריך להיות קטן מהזמן הקצוב לתפוגה של שרת היעד.
- אם יש לך צעדים אחרים לפני או אחרי Apigee, יש להחיל את אותו הכלל. תמיד צריך להשאיר את האחריות של הלקוח ב-downstream לסגור את החיבור עם ה-upstream.
צריך לאסוף פרטי אבחון
אם הבעיה נמשכת גם אחרי שביצעתם את ההוראות שלמעלה, עליכם לאסוף את פרטי האבחון הבאים, ולאחר מכן לפנות לתמיכה של Apigee Edge.
אם אתם משתמשים ב-Public Cloud, עליכם לספק את הפרטים הבאים:
- שם הארגון
- שם הסביבה
- שם שרת proxy ל-API
- צריך להשלים את הפקודה
curl
כדי לשחזר את השגיאה502
- קובץ מעקב שמכיל את הבקשות עם השגיאה
502 Bad Gateway - Unexpected EOF
- אם השגיאות
502
לא מתרחשות כרגע, יש לציין את תקופת הזמן עם פרטי אזור הזמן שבהם התרחשו שגיאות מסוג502
בעבר.
אם אתם משתמשים בענן פרטי, עליכם לספק את הפרטים הבאים:
- זוהתה הודעת שגיאה מלאה בבקשות שנכשלו
- הארגון, שם הסביבה ושם ה-Proxy של ה-API שלגביהם מופיעות
שגיאות מסוג
502
- חבילת שרת proxy ל-API
- קובץ מעקב שמכיל את הבקשות עם השגיאה
502 Bad Gateway - Unexpected EOF
- יומני הגישה של NGINX
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
- יומנים של מעבד ההודעות
/opt/apigee/var/log/edge-message-processor/logs/system.log
- תקופת הזמן עם פרטי אזור הזמן שבה אירעו השגיאות מסוג
502
Tcpdumps
נאסף במעבדי ההודעות או בשרת הקצה העורפי, או בשניהם כשאירעה השגיאה