504 Gateway Timeout

אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע

תיאור הבעיה

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

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

הודעות שגיאה

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

HTTP/1.1 504 Gateway Timeout

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

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

מה גורם לפסק זמן בשער?

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

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

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

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

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

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

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

שרת בק-אנד איטי

אם השרת העורפי איטי מאוד או שלוקח לו הרבה זמן לעבד את בקשת ה-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. אם השגיאה עם הזמן שחלף הכי ארוך מופיעה מיד אחרי אחד מהשלבים הבאים, זה מצביע על כך שהשרת העורפי איטי או שלוקח לו הרבה זמן לעבד את הבקשה:
    • הבקשה נשלחה לשרת היעד
    • ‫ServiceCallout policy

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

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

תהליך מספר 2: שימוש ביומני מעבד בקשות

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

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

    דוגמה ליומן של מעבד הודעות שמוצגת בו שגיאת 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

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

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

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

רזולוציה

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

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

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

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

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

    פסק זמן בנתב תם הזמן הקצוב לתפוגה של מעבד ההודעות זמן קצוב לתפוגה ב-API Proxy
    ‫57 שניות 55 שניות ‫120 שניות

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

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

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

    מכיוון שלנתב יש ערך זמן קצוב לתפוגה נמוך יותר (57 שניות) בהשוואה ל-120 שניות שהוגדרו ב-API Proxy, אם שרת הקצה העורפי לא יגיב אחרי 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, את מזהה ההודעה מ-Message Processor שהוא - ואת הזמן הכולל שחלף שהוא 57.001 שניות. הסיבה לכך היא שחלף הזמן הקצוב לתגובה בנתב אחרי 57.001 שניות, ולא קיבלנו תגובה ממעבד ההודעות.
  4. במקרה כזה, תראו חריגים Broken Pipe ביומנים של Message Processor (/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. אם אי אפשר לתקן או לבצע אופטימיזציה של שרת הקצה העורפי, או אם ידוע שלוקח לשרת הקצה העורפי הרבה זמן, צריך להגדיל את ערך הזמן הקצוב לתפוגה בנתב ובמעבד ההודעות.

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

      זמן קצוב לתפוגה בלקוח > זמן קצוב לתפוגה בנתב > זמן קצוב לתפוגה במעבד בקשות > זמן קצוב לתפוגה ב-proxy ל-API
  2. אם זה שרת קצה עורפי של NodeJS:
    1. בודקים אם קוד NodeJS מבצע קריאות לשרתי קצה עורפיים אחרים, ואם לוקח לו הרבה זמן להחזיר תגובה. בודקים למה לשרתי הקצה העורפי לוקח יותר זמן ומתקנים את הבעיה בהתאם.
    2. בודקים אם יש שימוש גבוה ב-CPU או בזיכרון במעבדי ההודעות:
      1. אם יש מעבד הודעות שמשתמש במעבד באופן מוגזם, צריך ליצור שלושה thread dumps כל 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 ומספקים את קובצי ה-thread dumps, תמונת מצב של הזיכרון והיומנים של מעבד בקשות (/opt/apigee/var/log/edge-message-processor/logs/system.log)כדי לעזור בחקירת הסיבה לשימוש הגבוה במעבד או בשימוש בזיכרון).

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

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

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

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

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

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

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

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

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

    כתוצאה מכך, NGINX יגדיר קוד סטטוס של 499 שמציין שהלקוח סגר את החיבור.

אבחון

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

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

  2. בדוגמה שלמעלה, שימו לב שהסטטוס של 499 ב-NGINX ומשך הזמן הכולל שחלף הוא 50.001 שניות. המשמעות היא שחלף הזמן הקצוב לתגובה של הלקוח אחרי 50.001 שניות.
  3. במקרה כזה, יופיעו Broken Pipe חריגים ביומנים של Message Processor (/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. אם אי אפשר לתקן או לבצע אופטימיזציה של שרת הקצה העורפי, או אם אתם יודעים שייקח הרבה זמן עד ששרת הקצה העורפי יפעל, צריך להגדיל את ערך הזמן הקצוב לתפוגה בנתב ובמעבד ההודעות.

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

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

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

צריך לבחור בקפידה את ערכי הזמן הקצוב לתפוגה שיוגדרו בנתב ובמעבד ההודעות, בהתאם לדרישות שלכם. אל תגדירו ערכי זמן קצובים גדולים באופן שרירותי. אם אתם צריכים עזרה, אתם יכולים לפנות אל התמיכה של 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. אם יש מעבד הודעות עם שימוש גבוה במעבד, צריך ליצור שלושה thread dumps כל 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 ומספקים את קובצי ה-thread dump, תמונת מצב של הזיכרון והיומנים של מעבד בקשות (/opt/apigee/var/log/edge-message-processor/logs/system.log)כדי לעזור להם לחקור את הסיבה לשימוש הגבוה במעבד או בשימוש בזיכרון.

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

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

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