דף זה תורגם על ידי Cloud Translation API.

502 שער שגוי EOF לא צפוי

מוצג המסמך של 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
כלי המעקב
יומני גישה של NGINX

מעקב API

כדי לאבחן את השגיאה באמצעות API Monitoring:

באמצעות API Monitoring תוכלו לחקור את הבעיה. 502, על ידי ביצוע השלבים המתוארים ב איך בודקים את הסיבות לבעיות. כלומר:

עוברים אל מרכז הבקרה בדיקה.
בוחרים בקוד הסטטוס בתפריט הנפתח ומוודאים שהשעה הנכונה תקופה נבחרת כאשר התרחשו שגיאות מסוג 502.
אם רואים מספר גבוה של שגיאות 502, לוחצים על התיבה במטריצה.
בצד שמאל, לוחצים על View Logs (הצגת היומנים) עבור השגיאות של 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 שמגיע משרת היעד:

כותרות של תשובות	ערך
X-Apigee.fault-source	`target`
קוד X-Apigee.fault	`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 עבור שרת ה-proxy ל-API הספציפי במהלך משך זמן ספציפי (אם הבעיה התרחשה בעבר) או לבקשות שנכשלות עם 502.

אם יש שגיאות 502, צריך לבדוק אם השגיאה נגרמת על ידי היעד נשלח Unexpected EOF. אם הערכים של X-Apigee.fault-source ו-X- Apigee.fault-code תואמים לערכים שמוצגים בטבלה שלמטה, השגיאה 502 היא נגרמה על ידי היעד שסגר את החיבור באופן בלתי צפוי:

כותרות של תשובות	ערך
X-Apigee.fault-source	`target`
קוד X-Apigee.fault	`messaging.adaptors.http.flow.UnexpectedEOFAtTarget`

זוהי רשומה לדוגמה שמציגה את השגיאה 502 שנגרמה על ידי שרת היעד:

בנוסף, צריך לרשום את מזהי ההודעות של השגיאות 502 כדי שנוכל לבדוק את הנושא לעומק.

הסיבה: שרת יעד שהוגדר באופן שגוי

שרת היעד לא הוגדר כראוי לתמיכה בחיבורי TLS או SSL.

אבחון

להשתמש ב-API Monitoring, בכלי Trace, או יומני גישה ל-NGINX כדי לקבוע את מזהה ההודעה, קוד השגיאה ומקור השגיאה של השגיאה 502.
מפעילים את המעקב בממשק המשתמש של ה-API המושפע.
אם בדוח של בקשת ה-API שנכשלה מוצגים הפרטים הבאים:
1. השגיאה 502 Bad Gateway מופיעה ברגע שהבקשה של תהליך היעד מתחילה.
2. ב-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>

אם אתם משתמשים ב-Private Cloud, תוכלו להשתמש ב-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 >

ההגדרה של 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>

אם השירות לקצה העורפי מחייב תקשורת 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, בכלי Trace, או יומני גישה ל-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 במעבדי ההודעות:
1. אם למארח של שרת הקצה העורפי יש כתובת IP אחת, משתמשים בפקודה הבאה:
```
tcpdump -i any -s 0 host IP_ADDRESS -w FILE_NAME
```
2. אם למארח של שרת הקצה העורפי יש כמה כתובות IP, משתמשים בפקודה הבאה:
```
tcpdump -i any -s 0 host HOSTNAME -w FILE_NAME
```
  הערה: אם מריצים את הפקודה הזו על ההודעה מעבד מידע, שימוש בכתובת ה-IP/שם המארח של שרת הקצה העורפי. אפשר גם להשתמש tcpdump בשרת הקצה העורפי. אם אתם מריצים את הפקודה בשרת העורפי, צריך להשתמש ב- כתובת ה-IP של מעבד ההודעות בפקודה tcpdump שלמעלה.
  
  בדרך כלל, השגיאה הזו נגרמת כי שרת הקצה העורפי מגיב עם [FIN,ACK] ברגע שמעבד ההודעות שולח את הבקשה לשרת הקצה העורפי.
עיינו בדוגמה הבאה (tcpdump).

דוגמה של tcpdump בוצעה כאשר 502 Bad Gateway Error (UnexpectedEOFAtTarget) התרחש
בפלט TCPDump רואים את רצף האירועים הבא:
1. בחבילה 985, מעבד ההודעות שולח את בקשת ה-API לשרת הקצה העורפי.
2. בחבילה 986, שרת הקצה העורפי מגיב באופן מיידי עם [FIN,ACK].
3. בחבילה 987, מעבד ההודעות מגיב עם [FIN,ACK] לקצה העורפי השרת.
4. בסופו של דבר, החיבורים נסגרים עם [ACK] ועם [RST] משני הצדדים.
5. מכיוון שהשרת הקצה העורפי שולח [FIN,ACK], מקבלים חריגה חריג אחד (java.io.EOFException: eof unexpected) בהודעה מעבד.
מצב כזה יכול לקרות אם יש בעיית רשת בשרת הקצה העורפי. לעורר עניין בקרב הרשת של צוות התפעול כדי לחקור את הבעיה לעומק.

רזולוציה

צריך לתקן את הבעיה בשרת העורפי כראוי.

אם הבעיה נמשכת וברצונך לקבל עזרה בפתרון בעיות ב-502 Bad Gateway Error, חוששים שזו בעיה ב-Edge, פנו אל התמיכה של Apigee Edge.

הסיבה: הגדרה לא נכונה של משך הזמן הקצוב לתפוגה של שמירה במצב פעיל

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

חיבורים קבועים ב-Apigee

Apigee כברירת מחדל (ובהמשך עם תקן HTTP/1.1) משתמש בחיבורים קבועים במהלך תקשורת עם שרת היעד העורפי. חיבורים קבועים יכולים לשפר את הביצועים בכך שהיא מאפשרת שימוש חוזר בחיבור TCP ו-SSL (אם רלוונטי) שכבר קיים. מפחית את התקורה של זמן האחזור. צריך להגדיר את משך הזמן שבו החיבור צריך להימשך באמצעות נכס זמן קצוב לתפוגה של פעילות (keepalive.timeout.millis).

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

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

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

אם Apigee או שרת הקצה העורפי מוגדרים עם זמנים קצובים לתפוגה שגויים של שמירה במצב פעיל, התוצאה של מרוץ תהליכים שגורמת לשרת הקצה העורפי לשלוח End Of File (FIN) לא צפוי בתגובה לבקשה למשאב.

לדוגמה, אם הזמן הקצוב לתפוגה שמוגדר במצב פעיל מוגדר בשרת ה-API ל-API או בהודעה. מעבד עם ערך גדול יותר מהזמן הקצוב לתפוגה של שרת הקצה העורפי ב-upstream, או שווה לו, מרוץ התהליכים הבא יכול להתרחש. כלומר, אם מעבד ההודעות לא מקבל נתונים עד שקרוב מאוד לסף של שרת הקצה העורפי משאירים את הזמן הקצוב לתפוגה פעיל, ואז בקשה עובר ומועבר לשרת הקצה העורפי באמצעות החיבור הקיים. המצב הזה יכול לגרום 502 Bad Gateway עקב שגיאת EOF בלתי צפויה כפי שמוסבר בהמשך:

נניח שהזמן הקצוב לתפוגה שמוגדר לשהייה פעילה גם במעבד ההודעות וגם בשרת הקצה העורפי הוא 60 שניות, הגיעה עד 59 שניות אחרי שהגיש את הבקשה הקודמת מעבד הודעות.
מעבד ההודעות מתקדם ומעבד את הבקשה שנשלחה בשנייה ה-59 באמצעות החיבור הקיים (כי הזמן הקצוב לתפוגה של שמירה במצב פעיל טרם חלף) ושולח את בקשה לשרת העורפי.
עם זאת, לפני שהבקשה מגיעה לשרת הקצה העורפי, הזמן הקצוב לתפוגה של שמירה פעילה יש חריגה מאז בשרת הקצה העורפי.
הבקשה של מעבד ההודעות למשאב פעילה, אבל השרת העורפי מנסה לסגור את החיבור על ידי שליחת חבילת FIN להודעה מעבד.
בזמן שמעבד ההודעות ממתין לקבלת הנתונים, הוא מקבל במקום זאת FIN הבלתי צפוי, והחיבור מסתיים.
התוצאה היא Unexpected EOF ולאחר מכן 502 שהוחזר ללקוח על ידי מעבד ההודעות.

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

אבחון

אם אתם משתמשים ב-Public Cloud:
1. שימוש בכלי API Monitoring או בכלי Trace (כפי שמוסבר ב שלבי אבחון נפוצים) ומוודאים שאתם: ההגדרות:
  - קוד התקלה: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
  - מקור התקלה: target
2. למידע נוסף, אפשר לעבור אל שימוש ב-tcpdump.
אם אתם משתמשים ב-Private Cloud:
1. אפשר להשתמש בכלי המעקב או יומני גישה ל-NGINX כדי לקבוע את מזהה ההודעה, קוד השגיאה ומקור השגיאה של השגיאה 502.
2. חיפוש מזהה ההודעה ביומן מעבד ההודעות
  (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. השם של 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)
```
4. השגיאה java.io.EOFException: eof unexpected מציינת מעבד ההודעות קיבל EOF בזמן שהמתין לקריאת תגובה משרת הקצה העורפי.
5. המאפיין useCount=7 בהודעת השגיאה שלמעלה מציין מעבד ההודעות עשה שימוש חוזר בחיבור הזה שבע פעמים ובמאפיין bytesWritten=159 מציין שמעבד ההודעות שלח את הבקשה מטען ייעודי (payload) של 159 בייטים לשרת העורפי. עם זאת, היא קיבלה אפס בייטים בחזרה כאשר התרחש EOF בלתי צפוי.
6. זה מראה שמעבד ההודעות השתמש שוב באותו חיבור מספר פעמים, ולכן הוא שלח נתונים, אבל זמן קצר לאחר מכן קיבל EOF לפני שהתקבלו נתונים. כלומר יש סבירות גבוהה שהקצה העורפי הזמן הקצוב לתפוגה של שרת 'נשארים פעיל' קצר או שווה לזה שהוגדר בשרת ה-Proxy של ה-API.
  
  אפשר להמשיך לחקור בעזרת tcpdump, כמו שמוסבר בהמשך.

שימוש ב-tcpdump

מתעדים tcpdump בשרת הקצה העורפי באמצעות הפקודה הבאה:
```
tcpdump -i any -s 0 host MP_IP_Address -w File_Name
```
ניתוח הנתונים של tcpdump שתועדו:
דוגמה לפלט tcpdump:

בדוגמה שלמעלה tcpdump ניתן לראות את הפרטים הבאים:
1. בחבילה 5992,, שרת הקצה העורפי קיבל בקשת GET.
2. בחבילה 6064, היא מגיבה עם 200 OK.
3. בחבילה 6084, שרת הקצה העורפי קיבל בקשת GET נוספת.
4. בחבילה 6154 היא מגיבה עם 200 OK.
5. בחבילה 6228, שרת הקצה העורפי קיבל בקשת GET שלישית.
6. הפעם, שרת הקצה העורפי מחזיר FIN, ACK למעבד ההודעות (חבילה 6285) התחלת סגירת החיבור.
בדוגמה הזו נעשה שימוש חוזר באותו חיבור פעמיים, אבל בבקשה השלישית, שרת הקצה העורפי יוזם סגירה של החיבור, ואילו מעבד ההודעות בהמתנה לנתונים משרת הקצה העורפי. זה מרמז על כך ששרת הקצה העורפי סביר להניח שהזמן הקצוב לתפוגה שמוגדר בזמן אמת קצר יותר לערך שהוגדר בשרת ה-proxy של ה-API, או שווה לו. לאימות ראו השוואה של זמן קצוב לתפוגה בזמן אמת ב-Apigee ובשרת קצה עורפי.

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

כברירת מחדל, Apigee משתמשת בערך של 60 שניות במאפיין הזמן הקצוב לתפוגה שמוגדר כפעיל.
עם זאת, ייתכן ששיניתם את ערך ברירת המחדל ב-proxy ל-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.
אם קבעתם שהערך של מאפיין הזמן הקצוב לתפוגה שמוגדר ל'שמירה במצב פעיל' ב-Apigee גבוה יותר מהערך של מאפיין הזמן הקצוב לתפוגה שמוגדר במצב פעיל בשרת הקצה העורפי כמו שצוין למעלה לדוגמה, זו הסיבה לשגיאות 502.

רזולוציה

מוודאים שמאפיין הזמן הקצוב לתפוגה שמוגדר במצב פעיל תמיד נמוך יותר ב-Apigee (ב-proxy ל-API וגם רכיב מעבד הודעות) בהשוואה לזה שבשרת הקצה העורפי.

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

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

שיטה מומלצת

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

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

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

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

אם אתם משתמשים ב-Public Cloud, עליכם לספק את הפרטים הבאים:

שם הארגון
שם הסביבה
שם ה-API של ה-Proxy
צריך להשלים את הפקודה curl כדי לשחזר את השגיאה 502
קובץ המעקב שמכיל את הבקשות עם השגיאה 502 Bad Gateway - Unexpected EOF
אם השגיאות מסוג 502 לא מתרחשות כרגע, יש לציין את תקופת הזמן עם פרטי אזור הזמן כשאירעו 502 שגיאות בעבר.

אם אתם משתמשים בענן פרטי, עליכם לספק את הפרטים הבאים:

הודעת שגיאה מלאה שנצפתה בבקשות שנכשלו
הארגון, שם הסביבה ושם ה-Proxy של ה-API שעבורם מוצגים 502 שגיאות
חבילת API Proxy
קובץ המעקב שמכיל את הבקשות עם השגיאה 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 נאסף במעבדי ההודעות או בשרת הקצה העורפי, או בשניהם כשהשגיאה התרחש