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, שיכולה להיגרם מהסיבות הבאות:

שלבים נפוצים לאבחון

כדי לאבחן את השגיאה, אפשר להשתמש באחת מהשיטות הבאות:

• API Monitoring
• כלי המעקב
• יומני גישה של NGINX

הסיבה: שרת היעד הוגדר בצורה שגויה

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

אבחון

1. כדי לקבוע את מזהה ההודעה, קוד השגיאה ומקור השגיאה של השגיאה 502, אפשר להשתמש במעקב אחר API, בכלי Trace או ביומני הגישה של NGINX.
2. מפעילים את המעקב בממשק המשתמש של ה-API המושפע.
3. אם הנתונים של בקשת ה-API שנכשלה מראים את הדברים הבאים:
   1. השגיאה 502 Bad Gateway מופיעה מיד אחרי שהבקשה לתהליך היעד מתחילה.
   2. בerror.class מוצגות messaging.adaptors.http.UnexpectedEOF.

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

4. אפשר לקבל את הגדרת שרת היעד באמצעות קריאה ל-Edge Management API:
   1. אם אתם משתמשי ענן ציבורי, אתם יכולים להשתמש ב-API הזה:

      curl -v https://api.enterprise.apigee.com/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>

   2. אם אתם משתמשים בענן פרטי, אתם צריכים להשתמש ב-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 >

5. ההגדרה 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 כחלק מההגדרה של שרת היעד כדי למנוע בלבול.

1. אם שירות לקצה העורפי דורש תקשורת SSL חד-כיוונית, אז:
   1. צריך להפעיל את 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>

   2. אם רוצים לאמת את האישור של שרת היעד ב-Edge, צריך גם לכלול את מאגר האישורים (שמכיל את האישור של שרת היעד) כמו בדוגמה הבאה:

      <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>

2. אם שירות ה-Backend דורש תקשורת SSL דו-כיוונית, אז:
   1. צריך להגדיר את הדגלים של מאפייני 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 >

קובצי עזר

איזון עומסים בין שרתי קצה עורפי

הסיבה: EOFException משרת הקצה העורפי

יכול להיות ששרת הבק-אנד ישלח EOF (סוף קובץ) באופן פתאומי.

אבחון

1. כדי לקבוע את מזהה ההודעה, קוד השגיאה ומקור השגיאה של השגיאה 502, אפשר להשתמש במעקב אחר API, בכלי Trace או ביומני הגישה של NGINX.
2. בודקים את היומנים של מעבד ההודעות (/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 לשרת הקצה העורפי והמתין או קרא את התגובה. עם זאת, שרת הקצה העורפי סיים את החיבור באופן פתאומי לפני שמעבד ההודעות קיבל את התגובה או יכול היה לקרוא את התגובה המלאה.

3. בודקים את יומני השרת של העורף כדי לראות אם יש שגיאות או מידע שיכלו לגרום לשרת העורף לסיים את החיבור באופן פתאומי. אם מופיעות שגיאות או פרטי מידע, עוברים אל פתרון הבעיה ומתקנים את הבעיה בשרת העורפי.
4. אם לא מצאתם שגיאות או מידע בשרת העורפי, אוספים את הפלט tcpdump במעבדי ההודעות:
   1. אם למארח של שרת ה-Backend יש כתובת IP אחת, משתמשים בפקודה הבאה:

      tcpdump -i any -s 0 host IP_ADDRESS -w FILE_NAME

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

      tcpdump -i any -s 0 host HOSTNAME -w FILE_NAME

      בדרך כלל, השגיאה הזו מתרחשת כי שרת הבק-אנד מגיב עם [FIN,ACK] ברגע שמעבד ההודעות שולח את הבקשה לשרת הבק-אנד.

5. הנה דוגמה לtcpdump:

   דוגמה tcpdump נלקחה כש502 Bad Gateway Error (UnexpectedEOFAtTarget) קרה

   

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

רזולוציה

מתקנים את הבעיה בשרת העורפי בהתאם.

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

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

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

חיבורים מתמשכים ב-Apigee

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

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

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

ההשלכות של הגדרת פסק זמן שגויה של שמירת החיבור

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

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

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

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

אבחון

1. אם אתם משתמשי ענן ציבורי:
   1. משתמשים בכלי API Monitoring או בכלי Trace (כפי שמוסבר בשלבים נפוצים לאבחון) ומוודאים ששתי ההגדרות הבאות מוגדרות:
      • קוד תקלה: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • מקור התקלה: target
   2. כדי לבצע בדיקה מעמיקה יותר, צריך לעבור אל שימוש ב-tcpdump.
2. אם אתם משתמשי Private Cloud:
   1. כדי לזהות את מזהה ההודעה, קוד השגיאה ומקור השגיאה של השגיאה 502, אפשר להשתמש בכלי Trace או בקבצים של יומני הגישה של NGINX.
   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 מציין שמעבד הבקשות שלח את מטען ייעודי בגודל 159 בייט לשרת בק-אנד. אבל הוא קיבל אפס בייטים בחזרה כשהתרחשה השגיאה הלא צפויה EOF.

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

      אפשר להשתמש ב-tcpdump כדי לבדוק את הבעיה לעומק, כמו שמוסבר בהמשך.

שימוש ב-tcpdump

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

   tcpdump -i any -s 0 host MP_IP_Address -w File_Name

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

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

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

2. עם זאת, יכול להיות ששיניתם את ערך ברירת המחדל ב-API Proxy. כדי לוודא זאת, אפשר לבדוק את ההגדרה הספציפית של TargetEndpoint בשרת ה-API Proxy שנכשל ונותן שגיאות 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 אלפיות השנייה).

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

רזולוציה

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

1. קובעים את הערך שהוגדר לזמן הקצוב לתפוגה של שמירת החיבור בשרת העורפי.
2. מגדירים ערך מתאים למאפיין הזמן הקצוב לתפוגה של keep-alive ב-API Proxy או ב-Message Processor, כך שערך המאפיין יהיה נמוך מהערך שהוגדר בשרת העורפי. לשם כך, פועלים לפי השלבים שמתוארים במאמר הגדרת הזמן הקצוב לתפוגה של keep-alive ב-Message Processors.

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

שיטה מומלצת

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

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

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

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

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

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

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

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