‫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. סשן ניפוי באגים עם הבעיה.