504 Gateway Timeout

אתם צופים במסמכי העזרה של Apigee Edge.
כניסה למסמכי העזרה של Apigee X. info

תיאור הבעיה

אפליקציית הלקוח מקבלת את קוד הסטטוס 504 של HTTP עם ההודעה 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. פג תוקף הזמן של Message Processor לפני שתגובת שרת הקצה העורפי מתקבלת.
  2. חל הזמן הקצוב לתפוגה של הנתב לפני ששרת Message Processor או שרת הקצה העורפי משיב.
  3. חל הזמן הקצוב של אפליקציית הלקוח לפני שהנתב/מעבד ההודעות/שרת הקצה העורפי משיב.

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

תרחיש מס' 1: תפוגת הזמן של Message Processor לפני שהשרת העורפי מגיב

אבחון

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

שיטה 1: שימוש ב-Trace

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

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

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

בניתוח שלמעלה, חל זמן קצוב לתפוגה של Message Processor אחרי 55002 אלפיות השנייה כי שרת הקצה העורפי לא מגיב.

שיטה 2: שימוש ביומני מעבד הבקשות

  1. צריך לבדוק את היומן של מעבד ההודעות (/opt/apigee/var/log/edge-message-processor/logs/system.log)

  2. אם מוצאים שגיאות Gateway Timeout ו-onTimeoutRead בבקשה הספציפית לשרת ה-proxy של ה-API בזמן הזה, סימן שתם הזמן הקצוב לתפוגה של מעבד ההודעות.

    יומן לדוגמה של Message Processor שמוצגת בו שגיאה מסוג Gateway Timeout

    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

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

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

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

רזולוציה

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

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

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

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

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

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

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

אבחון

  1. בודקים את יומן הגישה של NGINX (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)

  2. אם חל הזמן הקצוב לתפוגה של הנתב לפני Message Processor, הסטטוס 504 יופיע ביומני הגישה של NGINX לבקשת ה-API הספציפית, והערך של message id מ-Message Processor יוגדר כ--. הסיבה לכך היא שהנתב לא קיבל תגובה ממעבד ההודעות במהלך פרק הזמן שהוגדרה לתפוגה בנתב.

    דוגמה של רשומה ביומן 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 Proxy
  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. מפעילים מחדש את Message Processor באמצעות הפקודה הבאה. הפעולה הזו אמורה להפחית את השימוש במעבד (CPU) ובזיכרון: 
        /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
      4. עוקבים אחרי הקריאות ל-API כדי לוודא שהבעיה עדיין קיימת.
      5. פונים לתמיכה של Apigee Edge ומציינים את קובצי ה-threads, את תמונת המצב של הזיכרון ואת היומנים של מעבד ההודעות (/opt/apigee/var/log/edge-message-processor/logs/system.log)כדי לבדוק מה הסיבה לשימוש הגבוה במעבד או בזיכרון.

כדאי לקרוא את המאמר: איך מנוהל הזמן הקצוב לתפוגה בשרתי הקצה של NodeJS ב-Message Processor

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

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

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

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

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

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

    במקרה כזה, הזמן הכולל לקבלת תשובה לבקשת API דרך Edge הוא פחות מ-50 שניות. המדד הזה כולל את הזמן שנדרש לשלוח בקשת API, את הזמן שבו הבקשה עוברת עיבוד ב-Edge (נתב, מעבד הודעות), את הזמן שבו הבקשה נשלחת לשרת הקצה העורפי (אם רלוונטי), את הזמן שבו הקצה העורפי מעבד את הבקשה ושולח את התגובה, את הזמן שבו המערכת של 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 Proxy
  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 של השרשור, את קובץ ה-dump של ה-heap ואת היומנים של Message Processor (/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. אם יש לכם יותר ממעבדי הודעות, צריך לחזור על השלבים שלמעלה בכל מעבדי ההודעות.

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

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

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

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

אבחון

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

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

רזולוציה

  1. בודקים אם המדיניות שלגביה חלף זמן רב עד לקבלת תשובה, ואם יש קוד מותאם אישית שיכול להידרשות לו זמן רב לעיבוד. אם יש קוד כזה, נסו לתקן או לבצע אופטימיזציה לקוד שזוהה.
  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. מפעילים מחדש את Message Processor באמצעות הפקודה הבאה. הפעולה הזו אמורה להפחית את השימוש ב-CPU ובזיכרון. 
      /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
    4. עוקבים אחרי הקריאות ל-API ומוודאים שהבעיה עדיין קיימת.
    5. פונים לתמיכה של Apigee Edge ומספקים את קובצי ה-dump של השרשור, את קובץ ה-dump של ה-heap ואת היומנים של Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)כדי לעזור להם לחקור את הסיבה לשימוש הגבוה ב-CPU או בזיכרון.

אבחון בעיות באמצעות מעקב אחר API

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

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