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 יהיה Client -> נתב -> מעבד הודעות -> שרת עורפי כפי שמוצג באיור הבא:

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

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

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

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

איטי שרת עורפי

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

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

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

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

אבחון

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

הליך מס' 1 באמצעות Trace

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

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

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

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

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

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

2. אם מופיעות שגיאות Gateway Timeout ו-onTimeoutRead בבקשה הספציפית לשרת ה-proxy של ה-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 שצוינו ב-Proxy ל-API. ערך הזמן הקצוב הזה חל על API ספציפי שרת proxy שבו מצוין המאפיין שצוין. לדוגמה, אם ב-API Proxy ל-io.timeout.millis מוגדר הערך 10 שניות, ואז ערך הזמן הקצוב לתפוגה של 10 שניות ישמש עבור שרת ה-proxy הספציפי הזה ל-API. אם שרת הקצה העורפי לא מגיב תוך 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 שניות

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

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

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

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

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

      רעיון: צריך להגדיר את ערך הזמן הקצוב לרכיבים השונים הזמנה: הזמן הקצוב לתפוגה של לקוח > הזמן הקצוב לתפוגה של הנתב > הזמן הקצוב לתפוגה של ההודעה מעבד > הזמן הקצוב לתפוגה בשרת ה-proxy ל-API

2. אם מדובר בקצה עורפי של NodeJS:
   1. עליכם לבדוק אם קוד NodeJS מבצע קריאות לשרתים עורפיים אחרים ואם זה לוקח הרבה זמן לחזור. לבדוק למה השימוש בשרתי הקצה העורפי האלה נמשך זמן רב יותר.
   2. בודקים אם מעבדי ההודעות סובלים משימוש גבוה במעבד (CPU) או בזיכרון:
      1. אם מעבד ההודעות חווה שימוש גבוה במעבד (CPU), יש ליצור שרשור קובצי dump כל 30 שניות באמצעות הפקודה הבאה:

         JAVA_HOME/bin/jstack -l PID > FILENAME

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

         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 ושולחים את קובצי cookie של שרשורים, תמונת מצב של הזיכרון ויומנים של מעבד הודעות (/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 איטי על ידי 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) בשרת ה-proxy ל-API לוקח הרבה זמן.
4. לאחר שאירעה השגיאה, בדקו את הבקשה הספציפית עם משך הזמן הארוך ביותר הזמן שחלף.
5. בדקו את הזמן שחלף בכל שלב ורשמו לעצמכם את השלב שבו זהו הזמן הרב ביותר הוצאה.
6. אם תראו את משך הזמן הארוך ביותר במדיניות אחרת מלבד 'השירות', מדיניות יתרונות מרכזיים, שמציינת כי לוקח ל-Edge זמן רב לעבד את בקשה.
7. הנה דוגמה למעקב אחר ממשק המשתמש, שמראה זמן רב מאוד שעובר במדיניות JavaScript:

   

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

רזולוציה

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

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

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

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