504 Gateway Timeout

כרגע מוצג התיעוד של Apigee Edge.
כניסה למסמכי התיעוד של Apigee X.
מידע

תיאור הבעיה

אפליקציית הלקוח מקבלת קוד סטטוס HTTP של 504 עם ההודעה Gateway Timeout כתגובה לקריאות ל-API.

קוד מצב HTTP - שגיאת 504 Gateway Timeout מציין שהלקוח לא קיבל תגובה בזמן מ-Edge Gateway או משרת הקצה העורפי במהלך ביצוע API

הודעות שגיאה

אפליקציית הלקוח מקבלת את קוד התגובה הבא:

HTTP/1.1 504 Gateway Timeout

במקרים מסוימים, ייתכן שהודעת השגיאה הבאה תוצג גם:

{
   "fault": {
      "faultstring": "Gateway Timeout",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.GatewayTimeout"
       }
    }
}

מה גורם להשבתה של השער?

הנתיב האופייני לבקשת API דרך פלטפורמת Edge יהיה לקוח -> נתב -> מעבד הודעות -> שרת עורפי, כפי שמוצג באיור הבא:

באפליקציית הלקוח, בנתבים ובמעבדי ההודעות בפלטפורמת Edge מוגדרים ערכים מתאימים של זמן קצוב לתפוגה. פלטפורמת Edge מצפה שתישלח תגובה תוך פרק זמן מסוים לכל בקשת API, לפי הערכים של הזמן הקצוב לתפוגה. אם לא תתקבל תגובה תוך פרק הזמן שצוין, המערכת מחזירה את הערך 504 Gateway Timeout Error.

הטבלה הבאה מספקת פרטים נוספים על המקרים שבהם הזמן הקצוב לתפוגה עשוי להתרחש ב-Edge:

אירוע זמן קצוב לתפוגה פרטים
פג הזמן הקצוב למעבד ההודעות
  • שרת הקצה העורפי לא מגיב למעבד ההודעות במשך פרק זמן קצוב לתפוגה במעבד ההודעות.
  • הזמן הקצוב לתפוגה של מעבד ההודעות נפסק ושולח את סטטוס התגובה כ-504 Gateway Timeout לנתב.
אירעה הפסקה זמנית בנתב
  • מעבד ההודעות לא מגיב לנתב בתוך פרק הזמן הקצוב לתפוגה שהוגדר בנתב.
  • הזמן הקצוב לתפוגה של הנתב פג ושולח לאפליקציית הלקוח את סטטוס התגובה בתור 504 Gateway Timeout.
פג הזמן הקצוב לאפליקציית הלקוח
  • הנתב לא מגיב לאפליקציית הלקוח במהלך פרק הזמן הקצוב שצוין בנתב.
  • פג הזמן הקצוב לתפוגה של אפליקציית הלקוח והיא מסיימת את סטטוס התגובה למשתמש הקצה בתור 504 Gateway Timeout.

גורמים אפשריים

ב-Edge, הסיבות הטיפוסיות לשגיאה 504 Gateway Timeout הן:

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

שרת לקצה העורפי איטי

אם שרת הקצה העורפי איטי מאוד או שנדרש לו זמן רב לעיבוד בקשת ה-API, תתקבל הודעת השגיאה 504 Gateway Timeout. כפי שמוסבר בקטע שלמעלה, הזמן הקצוב לתפוגה עשוי להתרחש באחד מהתרחישים הבאים:

  1. הזמן הקצוב למעבד ההודעות נפסק לפני ששרת הקצה העורפי מגיב.
  2. הזמן הקצוב לתפוגה של הנתב פג לפני שמעבד ההודעות או שרת הקצה העורפי מגיבים.
  3. הזמן הקצוב של אפליקציית הלקוח פג לפני התגובה של הנתב/מעבד ההודעות/שרת הקצה העורפי.

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

תרחיש מס' 1 הזמן הקצוב לתפוגה של מעבד ההודעות הסתיים לפני ששרת הקצה העורפי מגיב

אבחון

אפשר להשתמש בתהליכים הבאים כדי לבדוק אם השגיאה 504 Gateway Timeout אירעה בגלל שרת הקצה העורפי האיטי.

הליך מס' 1: שימוש במעקב

אם הבעיה עדיין פעילה (504 שגיאות עדיין מתרחשות), יש לבצע את השלבים הבאים:

  1. עוקבים אחרי ה-API המושפע בממשק המשתמש של Edge. צריך להמתין עד שהשגיאה תתרחש או אם מתקבלת הקריאה ל-API, לבצע כמה קריאות ל-API ולשחזר את השגיאה 504 Gateway Timeout.
  2. כשאירעה השגיאה, בודקים את הבקשה הספציפית שבה קוד התגובה מופיע כ-504.
  3. צריך לבדוק את הזמן שחלף בכל שלב ולרשום את השלב שבו ניצלת את רוב הזמן.
  4. אם מופיעה שגיאה עם הזמן הארוך ביותר שחלף מיד אחרי אחד מהשלבים הבאים, זה סימן לכך שהשרת העורפי איטי או שנדרש זמן רב לעיבוד הבקשה:
    • הבקשה נשלחה לשרת היעד
    • המדיניות בנושא יתרונות מרכזיים של שירות

למטה מופיעה דוגמה ל-Trace שלפיו שרת הקצה העורפי לא הגיב אפילו אחרי 55 שניות, וכתוצאה מכך התקבלה שגיאת 504 Gateway Timeout:

בנתוני המעקב שלמעלה, הזמן הקצוב לתפוגה של מעבד ההודעות הוא 55,002 אלפיות השנייה, כי שרת הקצה העורפי לא מגיב.

הליך מס' 2 שימוש ביומנים של מעבד ההודעות

  1. בדיקת היומן של מעבד ההודעות (/opt/apigee/var/log/edge-message-processor/logs/system.log)
  2. אם מוצאים את השגיאות Gateway Timeout ו-onTimeoutRead בבקשות הספציפיות של שרת ה-API בזמן הרלוונטי, סימן שפג הזמן הקצוב לתפוגה של מעבד ההודעות.

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

    2015-09-29 20:16:54,340 org:myorg env:staging api:profiles rev:13 NIOThread@1
    ERROR ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() :
    AbstractResponseListener.onError(HTTPResponse@4d898cf1, Gateway
    Timeout)
    2015-09-29 20:16:57,361 org:myorg env:staging api:profileNewsletters rev:8
    NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onTimeout() :
    SSLClientChannel[C:XX.XX.XX.XX:443 Remote
    host:192.168.38.54:38302]@120171 useCount=2 bytesRead=0
    bytesWritten=824 age=55458ms lastIO=55000ms .onTimeoutRead
    

    ביומן של מעבד ההודעות שלמעלה, שמתם לב שהשרת של הקצה העורפי הרשום בכתובת ה-IP XX.XX.XX.XX לא הגיב גם אחרי 55 שניות (lastIO=55000ms). כתוצאה מכך, תם הזמן הקצוב לתפוגה של מעבד ההודעות ונשלחה השגיאה 504 Gateway Timeout.

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

    • איך נקבע הזמן הקצוב לתפוגה של מעבד ההודעות. מעבדי הודעות בדרך כלל מוגדרים עם ערך ברירת המחדל של הזמן הקצוב לתפוגה של 55 שניות) דרך המאפיין HTTPTransport.io.timeout.millis. ערך הזמן הקצוב לתפוגה חל על כל שרתי ה-proxy של ה-API ששייכים לארגון שמופעל על ידי מעבד ההודעות הזה.
      • אם שרת הקצה העורפי לא מגיב תוך 55 שניות, הזמן הקצוב לתפוגה של מעבד ההודעות נפסק והודעת השגיאה 504 Gateway Timeout נשלחת ללקוח.
    • המאפיין io.timeout.millis שמצוין בשרת ה-API של ה-API יכול לשנות את ערך הזמן הקצוב לתפוגה שמצוין במעבד ההודעות. ערך הזמן הקצוב הזה חל על שרת proxy ספציפי של API שבו מצוין המאפיין שצוין למעלה. לדוגמה, אם io.timeout.millis מוגדר ל-10 שניות בתוך שרת ה-proxy של ה-API, ייעשה שימוש בערך הזמן הקצוב של 10 שניות עבור שרת ה-proxy הספציפי הזה.
      • אם שרת הקצה העורפי לא יגיב תוך 10 שניות לשרת ה-proxy הספציפי של ה-API, הזמן הקצוב לתפוגה של מעבד ההודעות יפוג והודעת השגיאה 504 Gateway Timeout תישלח ללקוח.

רזולוציה

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

תרחיש מס' 2 – תם הזמן הקצוב לתפוגה של הנתב לפני התגובה של מעבד ההודעות/השרת העורפי

יכול להיות שיופיעו שגיאות מסוג 504 Gateway Timeout אם הזמן הקצוב לתפוגה של הנתב פג לפני שמעבד ההודעות או שרת הקצה העורפי יגיבו. זה יכול לקרות במצבים הבאים:

  • ערך הזמן הקצוב לתפוגה שהוגדר בנתב קצר יותר מערך הזמן הקצוב לתפוגה שהוגדר במעבד ההודעות. לדוגמה, נניח שהזמן הקצוב לתפוגה של נתב הוא 50 שניות, ומעבד ההודעות הוא 55 שניות.
    הזמן הקצוב לתפוגה של הנתב זמן קצוב לתפוגה של מעבד ההודעות
    50 שניות 55 שניות
  • ערך הזמן הקצוב לתפוגה במעבד ההודעות משתנה עם ערך גבוה יותר של זמן קצוב לתפוגה באמצעות המאפיין io.timeout.millis שהוגדר בתצורת היעד של נקודת הקצה של ה-API Proxy:

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

    הזמן הקצוב לתפוגה של הנתב זמן קצוב לתפוגה של מעבד ההודעות זמן קצוב לתפוגה בתוך שרת proxy ל-API
    57 שניות 55 שניות 120 שניות

    לעומת זאת, השדה io.timeout.millis מוגדר ל-120 שניות בשרת ה-proxy של ה-API:

    <HTTPTargetConnection>
         <Properties>
              <Property name="io.timeout.millis">120000</Property>
          </Properties>
          <URL>http://www.apigee.com</URL>
    </HTTPTargetConnection>
    

    לאחר מכן, הזמן הקצוב לתפוגה של מעבד ההודעות לא יופסק אחרי 55 שניות, על אף שערך הזמן הקצוב לתפוגה (55 שניות) קטן מערך הזמן הקצוב לתפוגה בנתב (57 שניות). הסיבה לכך היא שהזמן הקצוב לתפוגה של 55 שניות במעבד ההודעות מתבטל בערך של 120 שניות שהוגדר בשרת ה-API של ה-API. לכן, ערך הזמן הקצוב לתפוגה של מעבד ההודעות עבור שרת ה-API הספציפי הזה יהיה 120 שניות.

    מאחר שלנתב יש ערך זמן קצוב לתפוגה נמוך יותר (57 שניות) בהשוואה ל-120 שניות שמוגדר בשרת ה-Proxy של ה-API, הזמן הקצוב לתפוגה של הנתב יופסק אם שרת הקצה העורפי לא יגיב לאחר 57 שניות.

אבחון

  1. בדיקת יומן הגישה של NGINX (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)
  2. אם הזמן הקצוב של הנתב פג לפני מעבד ההודעות, הסטטוס 504 יופיע ביומני הגישה של NGINX לבקשת ה-API הספציפית, וה-message id ממעבד ההודעות יוגדר בתור -. הסיבה לכך היא שהנתב לא קיבל תגובה ממעבד ההודעות במהלך פרק הזמן הקצוב לתפוגה שהוגדר בנתב.

    דוגמה של רשומת יומן NGINX שמציגה שגיאה 504 כי הזמן הקצוב לתפוגה של הנתב הסתיים

  3. בדוגמה שלמעלה, אפשר לשים לב לסטטוס 504 ב-NGINX, מזהה ההודעה ממעבד ההודעות הוא - והזמן הכולל שחלף הוא 57.001 שניות. הסיבה לכך היא שפג הזמן הקצוב של הנתב לאחר 57.001 שניות ולא קיבלנו תגובה ממעבד ההודעות.
  4. במקרה כזה, יהיו Broken Pipe חריגים ביומנים של מעבד ההודעות (/opt/apigee/var/log/edge-message-processor/logs/system.log).
    2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
    2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
    java.io.IOException: Broken pipe
            at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
            at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
            at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
             … <snipped>
    

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

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

רזולוציה

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

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

      זמן קצוב לתפוגה בלקוח > זמן קצוב לתפוגה בנתב > זמן קצוב לתפוגה במעבד ההודעות > פסק זמן בתוך שרת ה-API של ה-API

  2. אם מדובר בשרת לקצה העורפי של NodeJS:
    1. כדאי לבדוק אם הקוד של NodeJS מבצע קריאות לשרתים אחרים בקצה העורפי, ואם קבלת התגובה נמשכת זמן רב. צריך לבדוק למה נדרש זמן רב יותר לשרתי הקצה העורפי ולתקן את הבעיה לפי הצורך.
    2. בודקים אם יש שימוש מוגבר במעבד (CPU) או בזיכרון:
      1. אם יש שימוש גבוה במעבד של ההודעות במעבד (CPU), צריך ליצור שלושה נתוני Dump של שרשור בכל 30 שניות באמצעות הפקודה הבאה:
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. אם מעבד הודעות מסוים משתמש בנפח גדול של זיכרון, יוצרים קובץ Dump של ערימה באמצעות הפקודה הבאה:
        sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
      3. מפעילים מחדש את מעבד ההודעות באמצעות הפקודה הבאה. המעבד (CPU) והזיכרון אמורים להרוס:
        /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
      4. צריך לעקוב אחר הקריאות ל-API כדי לוודא שהבעיה עדיין קיימת.
      5. מומלץ לפנות לתמיכה של Apigee Edge ולמסור את קובצי ה-Dump של ה-thread, תמונת ה-heap dump והיומנים של מעבד ההודעות (/opt/apigee/var/log/edge-message-processor/logs/system.log)כדי לבדוק את הסיבה לשימוש המוגבר במעבד (CPU) או בזיכרון.

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

  • שרת הקצה העורפי של NodeJS פועל בתוך תהליך ה-JVM של מעבד ההודעות. ערך הזמן הקצוב לתפוגה של שרתי הקצה העורפי של NodeJS נשלט באמצעות המאפיין http.request.timeout.seconds בקובץ nodejs.properties. המאפיין הזה מוגדר ל-0 כברירת מחדל. כלומר, הזמן הקצוב לתפוגה מושבת כברירת מחדל לכל שרתי ה-proxy של ה-API ששייכים לארגון שמופעל על ידי מעבד ההודעות הזה. כך שגם אם שרת הקצה העורפי של NodeJS לוקח זמן רב, למעבד ההודעות אין זמן קצוב לתפוגה.
  • עם זאת, אם שרת הקצה העורפי של NodeJS נמשך זמן רב ואם הזמן הנדרש לבקשת ה-API הוא גדול מ-57 שניות, הנתב הזמן הקצוב לתפוגה יסתיים וישלח הודעת השגיאה 504 Gateway Timeout ללקוח.

תרחיש מס' 3 – הזמן הקצוב לתפוגה של אפליקציית הלקוח פג לפני התגובה של הנתב/מעבד ההודעות/שרת הקצה העורפי

אם תם הזמן הקצוב לתפוגה של אפליקציית הלקוח לפני ששרת הקצה העורפי מגיב, ייתכן שתקבלו 504 Gateway Timeout שגיאות. מצב כזה יכול להתרחש אם:

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

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

    זמן קצוב לתפוגה בלקוח הזמן הקצוב לתפוגה של הנתב זמן קצוב לתפוגה של מעבד ההודעות
    50 שניות 57 שניות 55 שניות

    במקרה הזה, הזמן הכולל שזמין לקבלת תשובה לבקשת API דרך Edge הוא <= 50 שניות. זה כולל את הזמן שנדרש לביצוע בקשת API, עיבוד הבקשה באמצעות Edge (נתב, מעבד הודעות), שליחת הבקשה לשרת הקצה העורפי (אם רלוונטי), עיבוד הבקשה ושליחת התגובה בקצה העורפי, עיבוד התגובה ושליחתה בחזרה ללקוח.

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

    הפעולה הזו תגרום ל-NGINX להגדיר קוד סטטוס של 499 שמציין שהלקוח סגר את החיבור.

אבחון

  1. אם תם הזמן הקצוב לתפוגה של אפליקציית הלקוח לפני שהיא מקבלת תגובה מהנתב, היא תסגור את החיבור עם הנתב. במצב כזה, יופיע קוד הסטטוס 499 ביומני הגישה של NGINX לבקשת ה-API הספציפית.

    דוגמה של רישום ביומן NGINX שמראה את קוד הסטטוס 499

  2. בדוגמה שלמעלה, שימו לב שהסטטוס של 499 ב-NGINX והזמן הכולל שחלף הוא 50.001 שניות. פירוש הדבר הוא שתם הזמן הקצוב לתפוגה של הלקוח אחרי 50.001 שניות.
  3. במקרה כזה, יופיעו Broken Pipe חריגים ביומנים של מעבד ההודעות (/opt/apigee/var/log/edge-message-processor/logs/system.log).
    2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
    2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
    java.io.IOException: Broken pipe
            at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
            at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
            at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
             … <snipped>
    
    
  4. לאחר הזמן הקצוב לתפוגה של הנתב, הוא סוגר את החיבור עם מעבד ההודעות. כשמעבד ההודעות משלים את העיבוד, הוא מנסה לכתוב את התשובה לנתב. מאחר שהחיבור לנתב כבר סגור, ה-Broken Pipe exception מותקן במעבד ההודעות.
  5. החריגה הזו צפויה להימצא בנסיבות שמפורטות למעלה. כך שהסיבה בפועל לשגיאה 504 Gateway Timeout היא שעדיין לוקח לשרת הקצה העורפי זמן רב להגיב, ועליכם לטפל בבעיה.

רזולוציה

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

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

      זמן קצוב לתפוגה בלקוח > זמן קצוב לתפוגה בנתב > זמן קצוב לתפוגה במעבד ההודעות > פסק זמן בתוך שרת ה-API של ה-API

  2. אם מדובר בקצה עורפי של NodeJS:
    1. כדאי לבדוק אם קוד NodeJS מבצע קריאות לשרתים אחרים לקצה העורפי, ואם זמן האחזור נמשך זמן רב. בדקו למה נדרש זמן רב יותר לשרתי הקצה העורפי האלה.
    2. בודקים אם מעבדי ההודעות משתמשים בנפח גדול של משאבי מעבד (CPU) או של הזיכרון:
      1. אם יש שימוש גבוה במעבד של ההודעות, צריך ליצור שלושה קובצי Dump של שרשורים בכל 30 שניות באמצעות הפקודה הבאה:
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. אם מעבד הודעות מסוים צורך בנפח גדול של זיכרון, יש ליצור קובץ Dump של ערימה באמצעות הפקודה הבאה:
        sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
      3. מפעילים מחדש את מעבד ההודעות באמצעות הפקודה הבאה. כתוצאה מכך, המעבד (CPU) והזיכרון יימחקו:
        /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
      4. צריך לעקוב אחר הקריאות ל-API כדי לוודא שהבעיה עדיין קיימת.
      5. צריך לפנות לתמיכה של Apigee Edge ולמסור את הנתונים של קובצי ה-Dump של השרשור, Dump של הערימה והיומנים של מעבד ההודעות (/opt/apigee/var/log/edge-message-processor/logs/system.log)כדי לעזור להם לבדוק את הסיבה לשימוש הגבוה במעבד (CPU) או בזיכרון.

הגדלת הזמן הקצוב לתפוגה בנתב ובמעבד ההודעות

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

נתב

chown apigee:apigee /opt/apigee/customer/application/router.properties
  1. יוצרים את הקובץ /opt/apigee/customer/application/router.properties במחשב הנתב, אם הוא עדיין לא קיים.
  2. מוסיפים את השורה הבאה לקובץ הזה:
    conf_load_balancing_load.balancing.driver.proxy.read.timeout=TIME_IN_SECONDS

    לדוגמה, אם רוצים להגדיר את הזמן הקצוב לתפוגה של 120 שניות, מגדירים אותו באופן הבא:

    conf_load_balancing_load.balancing.driver.proxy.read.timeout=120
  3. צריך לוודא שהקובץ הזה בבעלות apigee:
  4. מפעילים מחדש את הנתב:
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
    
  5. אם יש לך כמה נתבים, עליך לחזור על השלבים שלמעלה בכל הנתבים.

מעבד בקשות

  1. יוצרים קובץ /opt/apigee/customer/application/message-processor.properties במחשב של מעבד ההודעות, אם הוא עדיין לא קיים.
  2. מוסיפים את השורה הבאה לקובץ הזה:
    conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS

    לדוגמה, אם רוצים להגדיר את הזמן הקצוב לתפוגה של 120 שניות, מגדירים אותו באופן הבא:

    conf_http_HTTPTransport.io.timeout.millis=120000
  3. יש לוודא שהקובץ הזה הוא בבעלות apigee:
    chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
  4. מפעילים מחדש את מעבד ההודעות:
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  5. אם יש לכם יותר ממעבד הודעות אחד, צריך לחזור על השלבים שלמעלה בכל מעבדי ההודעות.

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

זמן קצוב לתפוגה בלקוח > זמן קצוב לתפוגה בנתב > זמן קצוב לתפוגה במעבד ההודעות > תם הזמן הקצוב לשרת ה-API של ה-API

עיבוד איטי של בקשות API על ידי Edge

אם שירות Edge איטי מאוד ו/או נמשך זמן רב לעיבוד בקשת ה-API, תופיע הודעת השגיאה 504 Gateway Timeout.

אבחון

  1. עוקבים אחרי ה-API המושפע בממשק המשתמש של Edge.
  2. צריך להמתין עד שהשגיאה תתרחש או אם מוצגת קריאה ל-API, ולאחר מכן לבצע כמה קריאות ל-API ולשחזר את השגיאה 504 Gateway Timeout.
  3. הערה: במקרה זה, ייתכן שתופיע תגובה מוצלחת ב'מעקב'.
    1. הזמן הקצוב לתפוגה של הנתב או הלקוח נפסק כי מעבד ההודעות לא מגיב תוך פרק הזמן הקצוב שצוין בנתב או בלקוח (שהזמן הקצוב שלהם הוא הנמוך ביותר). עם זאת, מעבד ההודעות ימשיך לעבד את הבקשה וייתכן שהטיפול בה יושלם בהצלחה.
    2. כמו כן, הערך HTTPTransport.io.timeout.millis שמוגדר במעבד ההודעות מופעל רק אם מעבד ההודעות מתקשר עם שרת קצה עורפי HTTP/HTTPS. במילים אחרות, הזמן הקצוב לתפוגה לא יופעל אם כל מדיניות (מלבד המדיניות של ServiceCallout) על שרת ה-proxy של ה-API נמשכת זמן רב.
  4. אחרי שאירעה השגיאה, בודקים את הבקשה הספציפית עם הזמן הארוך ביותר שחלף.
  5. יש לבדוק את הזמן שחלף בכל שלב ולרשום את השלב שבו הוקדש הכי הרבה זמן.
  6. אם רואים את הזמן הארוך ביותר שחלף בכל כללי המדיניות מלבד המדיניות בנושא יתרונות מרכזיים של שירות, המשמעות היא שעיבוד הבקשה ל-Edge נמשך זמן רב.
  7. הנה דוגמה למעקב בממשק המשתמש שמראה את הזמן שחלף זמן רב מאוד במדיניות JavaScript:

  8. בדוגמה שלמעלה, ניתן לראות שהמדיניות של JavaScript נמשכת זמן ארוך באופן חריג כ-245 שניות.

רזולוציה

  1. כדאי לבדוק אם הטיפול במדיניות נמשך זמן רב, ואם יש קוד בהתאמה אישית שהעיבוד שלו עשוי להימשך זמן רב. אם קיים קוד כזה, כדאי לבדוק אם אפשר לתקן או לבצע אופטימיזציה של הקוד שזוהה.
  2. אם אין קוד מותאם אישית שעשוי לגרום לזמן עיבוד ארוך, בדקו אם מעבדי ההודעות מנצלים שימוש רב במעבד או בזיכרון:
    1. אם יש שימוש גבוה במעבד של ההודעות במעבד (CPU), צריך ליצור שלושה נתוני Dump של שרשור בכל 30 שניות באמצעות הפקודה הבאה:
      JAVA_HOME/bin/jstack -l PID > FILENAME
    2. אם יש מעבד הודעות שנעשה בו שימוש גבוה בזיכרון, יוצרים heap dump באמצעות הפקודה הבאה:
      sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
    3. מפעילים מחדש את מעבד ההודעות באמצעות הפקודה הבאה. המעבד (CPU) והזיכרון יימחקו.
      /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
    4. צריך לעקוב אחר הקריאות ל-API ולוודא אם הבעיה עדיין קיימת.
    5. צריך לפנות לתמיכה של Apigee Edge ולמסור את הנתונים של קובצי ה-Dump של השרשור, Dump של הערימה והיומנים של מעבד ההודעות (/opt/apigee/var/log/edge-message-processor/logs/system.log)כדי לעזור להם לבדוק את הסיבה לשימוש הגבוה במעבד (CPU) או בזיכרון.

אבחון בעיות באמצעות API Monitoring

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

שלב תרחיש לדוגמה שמדגים איך לפתור בעיות מסוג 5xx בממשקי ה-API באמצעות API Monitoring. לדוגמה, ייתכן שתרצו להגדיר התראה כדי לקבל התראה כאשר מספר קודי הסטטוס 504 חורג מסף מסוים.