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

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

באמצעות API Monitoring אפשר לבדוק את השגיאות של 502 על ידי ביצוע השלבים שמתוארים במאמר בדיקת בעיות. כלומר:

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

    • מקור התקלה הוא target
    • קוד התקלה הוא messaging.adaptors.http.UnexpectedEOFAtTarget

ערך זה מציין שהשגיאה 502 נגרמה על ידי היעד עקב EOF לא צפוי.

בנוסף, כדאי לרשום את Request Message ID של השגיאה 502 כדי להמשיך את הבדיקה.

כלי המעקב

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

  1. מפעילים את סשן המעקב ומבצעים את הקריאה ל-API כדי לשחזר את הבעיה 502 Bad Gateway.
  2. בוחרים אחת מהבקשות שנכשלו ובודקים את המעקב.
  3. אפשר לנווט בשלבים השונים של המעקב ולאתר את המיקום שבו אירעה הכשל.
  4. הכשל אמור להופיע לאחר שליחת הבקשה לשרת היעד באופן הבא:

    alt_text

    alt_text

  5. קובעים את הערך של 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, צריך לפעול לפי השלבים הבאים:

  1. כדאי לבדוק את יומני הגישה של NGINX.
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  2. חיפוש שגיאות 502 לשרת ה-API הספציפי במהלך פרק זמן ספציפי (אם הבעיה אירעה בעבר) או לבקשות שעדיין נכשלות עם 502.
  3. אם יש שגיאות מסוג 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.

אבחון

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

      סביר להניח שהבעיה הזו נגרמת על ידי הגדרה שגויה של שרת יעד.

  4. מקבלים את ההגדרה של שרת היעד באמצעות קריאה ל-Edge Management API:
    1. אם אתם משתמשים ב-Public Cloud, השתמשו ב-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, צריך גם לכלול את ה-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>
      
  2. אם השירות לקצה העורפי דורש תקשורת 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 >
      

קובצי עזר

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

הסיבה: EOFחריגה משרת הקצה העורפי

שרת הקצה העורפי עשוי לשלוח EOF (סוף הקובץ) פתאום.

אבחון

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

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 לא צפויה, כפי שמוסבר בהמשך:

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

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

אבחון

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

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

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

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

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

רזולוציה

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

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

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

שיטה מומלצת

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

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