‫504 Gateway timeout - Target read timeout

הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.

לעיון במסמכי התיעוד של Apigee Edge

תיאור הבעיה

הבעיה הזו מופיעה כשגיאה Gateway Timeout עם סטטוס HTTP ‏504.

הודעת השגיאה

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

ערך ברירת המחדל של הזמן הקצוב לתפוגה של קריאת היעד (io.timeout.millis) הוא 55 שניות. כלומר, אם אחרי 55 שניות היעד לא מגיב, Apigee מחזיר את השגיאה הבאה:

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

סיבות אפשריות

מטרה	תיאור	הוראות לפתרון בעיות שרלוונטיות ל
יעד איטי	היעד לא מפיק תגובה בזמן.	‫Apigee X ו-Apigee Hybrid
בעיה בקישוריות של TargetServer	יש בעיה כללית בקישוריות ליעד כש-<LoadBalancer> מוגדר ב-TargetEndpoint.	‫Apigee X ו-Apigee Hybrid

הסיבה: יעד איטי

אבחון

אפשר לאבחן בעיה של יעד איטי באמצעות כלי הניפוי באגים של Apigee:

1. יוצרים סשן לניפוי באגים בשביל proxy ל-API.
2. בסשן ניפוי הבאגים, שולחים בקשה ובודקים את פלט ניפוי הבאגים.

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

רזולוציה

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

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

1. לוחצים על הכרטיסייה פיתוח בעורך ה-proxy.
2. בחלונית הניווט, בוחרים את נקודת הקצה של היעד הרלוונטי.
3. בכלי לעריכת XML, מחפשים את רכיב ה-XML‏ HTTPTargetConnection:
   
   

   

4. מוסיפים את הנכס io.timeout.millis מתחת לרכיב <HTTPTargetConnection> ומציינים את מגבלת הזמן החדשה באלפיות שנייה, לדוגמה:

   <HTTPTargetConnection>
     <URL>https://my-very-slow-target.example.com</URL>
     <Properties>
       <Property name="io.timeout.millis">120000</Property>
     </Properties>
   </HTTPTargetConnection>

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

5. שומרים את הגרסה החדשה ומפעילים את ה-proxy.

אם הבעיה נמשכת, אפשר לעבור אל מידע אבחוני שצריך לאסוף בהמשך.

הסיבה: בעיה בקישוריות של TargetServer

אבחון

‫Apigee לא חושף את הסיבה המדויקת לבעיית קישוריות כשמגדירים את המאפיין <LoadBalancer>endpoint. יכול להיות שתוכלו להסיק את הסיבה לבעיית הקישוריות, אבל רק מתוך הזמן שחלף מאז בקשת היעד. כשיטה לניפוי באגים, אפשר לנסות להסיר את הרכיב <LoadBalancer> לגמרי ולנסות להגיע ליעד ישירות בשרת ה-proxy.

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

1. יוצרים סשן לניפוי באגים בשביל proxy ל-API.
2. בסשן ניפוי הבאגים, שולחים בקשה ובודקים את פלט ניפוי הבאגים.

בדוגמה שלמעלה, חלפו תשע שניות עד שפג הזמן הקצוב לתפוגה. מכיוון שהזמן לא היה 55 שניות, הגורם לשגיאה הוא לא חריגה ממגבלת הזמן הקצוב לתפוגה בגלל יעד איטי. כברירת מחדל, Apigee מנסה ליצור חיבור פעמיים נוספות אם נעשה שימוש ברכיב <LoadBalancer> ב-TargetEndpoint. אתם יודעים שהיה ניסיון להתחבר שלוש פעמים בסך הכול, וזמן הקצוב לתפוגה שמוגדר כברירת מחדל לשגיאת חיבור הוא שלוש שניות (connect.timeout.millis), ולכן אפשר להניח שהבעיה היא בעיית קישוריות.

רזולוציה

אם הבעיה היא זמן קצוב לתפוגה של חיבור, אפשר לעיין במאמר שגיאת 503 Service Unavailable ב-VPC Peering עם TARGET_CONNECT_TIMEOUT.

במקרה של בעיות אחרות, מסירים את הרכיב <LoadBalancer> כדי לנפות באגים ולגלות את קוד השגיאה המדויק, ומחפשים את הקוד בקטלוג השגיאות.

איסוף פרטי אבחון

אם הבעיה נמשכת גם אחרי שמבצעים את ההוראות שלמעלה, צריך לאסוף את פרטי האבחון הבאים ואז לפנות לתמיכה של Google Cloud:

1. מזהה הפרויקט ושם הארגון ב-Apigee
2. שמות ה-proxy והסביבה.
3. מסגרת הזמן של הבעיה.
4. תדירות הבעיה
5. שם המארח של היעד.
6. סשן ניפוי באגים עם הבעיה.