דף זה תורגם על ידי Cloud Translation API.

504 זמן קצוב לתפוגה של Gateway - תם הזמן הקצוב לתפוגה של הנתב

מוצג המסמך של Apigee Edge.
עוברים אל מסמכי תיעוד של Apigee X. מידע

תיאור הבעיה

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

תגובת השגיאה הזו מציינת שהלקוח לא קיבל תגובה בזמן מ-Apigee Edge או שרת העורפי במהלך ביצוע קריאה ל-API.

הודעת שגיאה

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

HTTP/1.1 504 Gateway Time-out

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

<!DOCTYPE html>
<html>
<head>
<title>Error</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>An error occurred.</h1>
<p>Sorry, the page you are looking for is currently unavailable.<br/>
Please try again later.</p>
</body>
</html>

מה גורם לחסימות זמניות?

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

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

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

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

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

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

ב-Edge, הסיבות הטיפוסיות לשגיאה 504 Gateway Timeout שנגרמו בגלל הזמן הקצוב לתפוגה של הנתב:

סיבה	תיאור	הוראות לפתרון בעיות עבור
הגדרה שגויה של הזמן הקצוב לתפוגה בנתב	זה קורה אם הנתב מוגדר עם זמן שגוי של קלט/פלט (I/O).	משתמשי Edge בענן הציבורי והפרטי

שלבי אבחון נפוצים

יש להשתמש באחד מהכלים או השיטות הבאים כדי לאבחן את השגיאה:

מעקב אחרי API
יומני גישה ל-NGINX

מעקב אחרי API

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

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

דוגמה להצגת שגיאות 504
בחלונית שמשמאל, לוחצים על View Logs.

בחלון יומני תנועה, שימו לב לפרטים הבאים לגבי חלק משגיאות 504:
- בקשה: הפעולה הזו מספקת את שיטת הבקשה וה-URI שמשמשים לביצוע הקריאות.
- זמן תגובה: משך הזמן הכולל שחלף לבקשה.
בדוגמה שלמעלה,
- הבקשה מפנה אל GET /test-timeout.
- זמן התגובה הוא 57.001 שניות. זה מציין שהנתב הזמן הקצוב הסתיים לפני שמעבד ההודעות הצליח להגיב כי הערך קרוב מאוד לברירת המחדל של הזמן הקצוב לתפוגה של קלט/פלט (I/O) שהוגדר בנתב, שהוא 57 שניות.
אפשר גם לקבל את כל היומנים באמצעות API Monitoring API של GET Logs. לדוגמה, באמצעות שליחת שאילתה על היומנים של org, env, timeRange, וגם status, תוכלו להוריד את כל היומנים של עסקאות שבהן פג הזמן הקצוב של הלקוח.

מכיוון ש-API Monitoring מגדיר את שרת ה-proxy ל-- (לא מוגדר) עבור 504 הערכים האלה שגיאות, אפשר להשתמש ב-API (יומנים API) כדי לקבל את שרת ה-proxy המשויך למארח ולנתיב הווירטואלי.

לדוגמה :
```
curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https
```
הערה: השדות הבאים יציגו את הערך עבור שגיאת 504 הזו:
- מקור התקלה
- קוד שגיאה
- כשל
- מדיניות תקלות
- שרת proxy לבעיה
השדות האלה מאוכלסים על ידי מעבד ההודעות ומוגדרים עם הערכים המתאימים רק אם הנתב מקבל תגובה ממעבד ההודעות. במקרה הזה, הנתב הסתיים הזמן הקצוב לתפוגה לפני מעבד ההודעות כי הוא לא הגיב בחזרה בזמן. הפעולה הזו מאלצת את הנתב להגדיר את קוד הסטטוס ל-504, וכתוצאה מכך כל השדות שצוינו למעלה מוצגים כ--.
צריך לבדוק בזמן התגובה אם יש 504 שגיאות נוספות ולבדוק כדי לבדוק אם זמן התגובה עקבי (ערך הזמן הקצוב לתפוגת קלט/פלט מוגדר בנתב שהוא 57 שניות) בכל השגיאות של 504.

יומני גישה ל-NGINX

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

בודקים את יומני הגישה ל-NGINX:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
אפשר לבצע חיפוש כדי לראות אם יש שגיאות 504 במהלך פרק זמן ספציפי (אם הבעיה אירעה בעבר) או אם יש בקשות שעדיין לא נענו 504
שימו לב לפרטים הבאים לגבי חלק מהשגיאות ב-504:
- בתוך כמה זמן תקבלו תשובה
- כתובת אתר מבוקשת
בדוגמה הזאת אנחנו רואים את הפרטים הבאים:
- זמן הבקשה: 57.001 שניות. המשמעות היא הזמן הקצוב של הנתב פג אחרי 57.001 שניות.
  
  הערה: השדה הזה מייצג את השדה request_time ביומני NGINX. כלומר, זמן העיבוד של הבקשה בשניות; הזמן שעבר בין בייטים נקראו מהלקוח ומהכתיבה ביומן אחרי שהבייטים האחרונים נשלחו ללקוח.
- בקשה: GET /test-timeout
- כתובת האימייל החלופית של המארח: myorg-test.apigee.net
הערה: בשדות הבאים יוצג הערך - של 504 זה שגיאה:
- מקור התקלה
- קוד שגיאה
- כשל
- מדיניות תקלות
- שרת proxy לבעיה
השדות האלה מאוכלסים על ידי מעבד ההודעות והם יוגדרו עם הערכים המתאימים בלבד אם הנתב מקבל תגובה ממעבד ההודעות. במקרה הזה, הנתב קבע זמן לפני מעבד ההודעות כי הוא לא הגיב בחזרה בזמן. זה מאלץ על הנתב להגדיר את קוד הסטטוס ל-504. כתוצאה מכך, כל האפשרויות שצוינו למעלה השדות מוצגים בתור -.
צריך לבדוק אם זמן הבקשה זהה לזמן הקצוב לתפוגה של קלט/פלט שהוגדר בנתב/במארח הווירטואלי. אם כן, סימן שתם הזמן הקצוב של הנתב לפני מעבד ההודעות לא הגיב בפרק הזמן הזה.

ברשומה לדוגמה של יומן הגישה ל-NGINX שמוצגת למעלה, מזינים את הבקשה הזמן של 57.001 שניות קרוב מאוד לזמן הקצוב לתפוגה של קלט/פלט (I/O) שהוגדר כברירת מחדל בנתב. זה מציין בבירור שתם הזמן הקצוב של הנתב לפני ההודעה מעבד המידע יכול להגיב.
מאתרים את ה-Proxy ל-API שעבורו הבקשה נשלחה באמצעות הנתיב הבסיסי בקובץ ה- בקשה .

הסיבה: הגדרה שגויה של הזמן הקצוב לתפוגה בנתב

אבחון

יש לקבוע אם השגיאות מסוג 504 נגרמות כי פג הזמן הקצוב של הנתב מעבד ההודעות יוכל להגיב. אפשר לעשות זאת על ידי בדיקה אם Response Time ב-API Monitoring/Request Time בנתב (שני השדות) שמייצגות את אותו מידע,אבל נקראות בשמות שונים) זהה הזמן הקצוב לתפוגה של קלט/פלט (I/O) שהוגדר בנתב/במארח וירטואלי ובשדות מקור התקלה, תקלה שרתי ה-proxy ו-Fault Code מוגדרים ל-- באמצעות API Monitoring או NGINX Access יומנים, כמו שמוסבר ב שלבי האבחון הנפוצים.
צריך לבדוק אם ערך הזמן הקצוב לתפוגה של קלט/פלט (I/O) שהוגדר בנתב או במארח וירטואלי ספציפי הוא נמוך יותר בהשוואה לערך שהוגדר במעבד ההודעות או בשרת ה-proxy הספציפי ל-API.

כדי לעשות זאת, צריך לפעול לפי השלבים בקטע הזה.

אימות הזמן הקצוב לתפוגה של קלט/פלט במארחים וירטואליים

ממשק המשתמש של Edge

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

מתחברים לממשק המשתמש של Edge.
עוברים לקטע ניהול > מארחים וירטואליים.
בוחרים סביבה ספציפית שבה נתקלתם בבעיה עם הזמן הקצוב לתפוגה.
בוחרים את המארח הווירטואלי הספציפי שעבורו רוצים לאמת את ערך הזמן הקצוב לתפוגה של קלט/פלט.
בקטע מאפיינים, מציגים את הערך הזמן הקצוב לתפוגה של קריאה לשרת proxy בשניות.

בדוגמה שלמעלה, הזמן הקצוב לתפוגה של קריאה לשרת proxy מוגדר עם ערך של 120. המשמעות היא שהזמן הקצוב לתפוגה של קלט/פלט (I/O) שהוגדר במארח הווירטואלי הזה הוא 120 שניות.

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

ממשקי API לניהול

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

להפעיל את אחזור API של מארח וירטואלי כדי לקבל את ההגדרה של virtualhost כמו בדוגמה הבאה:

משתמש ב-Public Cloud
```
curl -v -X GET https://api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/virtualhosts/VIRTUALHOST_NAME -u USERNAME
```
משתמש בענן פרטי
```
curl -v -X GET http://MANAGEMENT_SERVER_HOST:PORT#/v1/organizations/ORGANIZATION_NAME/environments/v/virtualhosts/VIRTUALHOST_NAME -u USERNAME
```
כאשר:

ORGANIZATION_NAME הוא שם הארגון

ENVIRONMENT_NAME הוא שם הסביבה

VIRTUALHOST_NAME הוא השם של המארח הווירטואלי

בדיקת הערך שהוגדר לנכס proxy_read_timeout

הגדרה של מארח וירטואלי לדוגמה

{
  "hostAliases": [
    "api.myCompany,com",
  ],
  "interfaces": [],
  "listenOptions": [],
  "name": "secure",
  "port": "443",
  "retryOptions": [],
  "properties": {
    "property": [
      {
        "name": "proxy_read_timeout",
        "value": "120"
      }
    ]
  },
  "sSLInfo": {
    "ciphers": [],
    "clientAuthEnabled": "false",
    "enabled": "true",
    "ignoreValidationErrors": false,
    "keyAlias": "myCompanyKeyAlias",
    "keyStore": "ref://myCompanyKeystoreref",
    "protocols": []
  },
  "useBuiltInFreeTrialCert": false
}

בדוגמה שלמעלה, proxy_read_timeout מוגדר עם ערך של 120. המשמעות היא שהזמן הקצוב לתפוגה של קלט/פלט (I/O) שהוגדר במארח הווירטואלי הזה הוא 120 שניות.

הערה: אם הנכס proxy_read_timeout לא קיים בפלט של הניהול כלומר הוא יקבל את ברירת המחדל של 57 שניות (אלא אם הזמן הקצוב לתפוגה של קלט/פלט מתבטל במכונות של הנתב).

מאמת את הזמן הקצוב לתפוגה של קלט/פלט בקובץ console.properties

מתחברים למכשיר נתב.
חיפוש הנכס proxy_read_timeout ב /opt/nginx/conf.d ולבדוק אם היא הוגדרה עם הערך החדש ככה:
```
grep -ri "proxy_read_timeout" /opt/nginx/conf.d
```
בדיקת הערך שהוגדר לנכס proxy_read_timeout בתצוגה הווירטואלית הספציפית קובץ תצורה של המארח.

תוצאה לדוגמה מפקודת gRep
```
/opt/nginx/conf.d/0-default.conf:proxy_read_timeout 57;
/opt/nginx/conf.d/0-edge-health.conf:proxy_read_timeout 1s;
```
בפלט לדוגמה שלמעלה, שימו לב שהנכס proxy_read_timeout כולל הוגדר עם הערך החדש 57 ב-0-default.conf, שהוא קובץ תצורה עבור המארח הווירטואלי המוגדר כברירת מחדל. הדבר מציין שהזמן הקצוב לתפוגה של קלט/פלט הוגדרה ל-57 שניות בנתב למארח הווירטואלי ברירת המחדל. אם יש לכם מספר מארחים וירטואליים, המידע הזה יוצג לגבי כל אחד מהם. קבלת הערך של proxy_read_timeout למארח הווירטואלי הספציפי שבו השתמשתם ליצירת ה-API קריאות שנכשלו עם 504 שגיאות.

מאמת את הזמן הקצוב לתפוגה של קלט/פלט בשרת proxy ל-API

אפשר להציג את הזמן הקצוב לתפוגה של קלט/פלט בדברים הבאים:

נקודת קצה (endpoint) של יעד של שרת proxy ל-API
מדיניות ServiceCallout על שרת proxy ל-API

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

בממשק המשתמש של Edge, בוחרים את שרת ה-proxy הספציפי ל-API שבו רוצים להציג את הקלט/פלט (I/O) ערך הזמן הקצוב לתפוגה.
בוחרים את נקודת הקצה הספציפית שרוצים לבדוק.
צריך לראות את המאפיין io.timeout.millis עם ערך מתאים מתחת רכיב <HTTPTargetConnection> בTargetEndpoint הגדרה אישית.
לדוגמה, הזמן הקצוב לתפוגה של קלט/פלט בקוד הבא מוגדר ל-120 שניות:
```
<Properties>
  <Property name="io.timeout.millis">120000</Property>
</Properties>
```

הצגת הזמן הקצוב לתפוגה של קלט/פלט במדיניות ServiceCallout של שרת ה-proxy ל-API

בממשק המשתמש של Edge, בוחרים את שרת ה-proxy הספציפי ל-API שבו רוצים להציג את הקלט/פלט החדש הזמן הקצוב לתפוגה של מדיניות ServiceCallout.
בוחרים את המדיניות הספציפית של ServiceCallout שרוצים לבדוק.
אפשר לראות את הרכיב <Timeout> עם ערך מתאים מתחת הגדרה של <ServiceCallout>.

לדוגמה, הזמן הקצוב לתפוגה של קלט/פלט בקוד הבא יהיה 120 שניות:
```
<Timeout>120000</Timeout>
```

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

מתחברים למעבד ההודעות.

חיפוש הנכס HTTPTransport.io.timeout.millis ב הספרייה /opt/apigee/edge-message-processor/conf באמצעות הפקודה הבאה:

grep -ri "HTTPTransport.io.timeout.millis" /opt/apigee/edge-message-processor/conf

פלט לדוגמה

/opt/apigee/edge-message-processor/conf/http.properties:HTTPTransport.io.timeout.millis=55000

בפלט לדוגמה שלמעלה, שימו לב שהמאפיין HTTPTransport.io.timeout.millis הוגדר עם הערך 55000 ב- http.properties. הדבר מציין שהזמן הקצוב לתפוגה של קלט/פלט הוגדר בהצלחה 55 שניות במעבד ההודעות.

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

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

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

במשפט הזה,

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

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

רזולוציה

מבצעים את השלבים הבאים כדי להגדיר את הזמן הקצוב לתפוגה של קלט/פלט (I/O) בנתב ובהודעה מעבד המידע כדי לפתור את הבעיה.

פרטים נוספים שיטות מומלצות להגדרת זמן קצוב לתפוגה של קלט/פלט כדי להבין אילו ערכי זמן קצוב לתפוגה צריכה להיות מוגדרת ברכיבים שונים שמעורבים בתהליך בקשת ה-API דרך Apigee Edge.
בדוגמה שלמעלה, אם וידאתם שצריך להגדיר ערך גבוה יותר של זמן קצוב לתפוגה כי שרת הקצה העורפי דורש זמן רב יותר והגדלתם את הזמן הקצוב לתפוגה שבמעבד ההודעות ל-120 שניות, ולאחר מכן הגדרת ערך גבוה יותר של זמן קצוב לתפוגה לדוגמה: 123 seconds בנתב. כדי למנוע השפעה על כל שרתי ה-proxy ל-API בגלל הערך החדש של הזמן הקצוב לתפוגה, הגדירו את הערך 123 seconds רק בשעה מארח וירטואלי ספציפי שבו נעשה שימוש בשרת ה-Proxy הספציפי ל-API.
פועלים לפי ההוראות ב הגדרת זמן קצוב לתפוגה של קלט/פלט בנתבים כדי לקבוע את הזמן הקצוב לתפוגה במארח הווירטואלי.