מוצג המסמך של Apigee Edge.
עוברים אל
מסמכי תיעוד של Apigee X. מידע
סרטונים
צפו בסרטון הבא כדי לקבל מידע נוסף על פתרון שגיאות מסוג 503 שגיאות שירות לא זמין.
וידאו | תיאור |
---|---|
503 שגיאה של שירות לא זמין משרת העורפי | למידע על הנושאים הבאים:
|
תיאור הבעיה
אפליקציית הלקוח מקבלת סטטוס של תגובת HTTP 503 עם ההודעה Service Unavailable בהמשך קריאה לשרת proxy ל-API.
הודעות שגיאה
אחת מהודעות השגיאה הבאות תופיע:
HTTP/1.1 503 Service Unavailable
HTTP/1.1 503 Service Unavailable: Back-end server is at capacity
ייתכן גם שתופיע הודעת שגיאה כמו הבאה בתגובת ה-HTTP:
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
הערה: קוד התגובה והודעת השגיאה שצוינו למעלה הם רק דוגמאות. במקרים מסוימים, יכול להיות שתקבלו רק את קוד התגובה לשגיאה ללא הודעת שגיאה. הפורמט והתוכן של קוד תגובת השגיאה והודעת השגיאה עשויים להשתנות בהתאם ל בהטמעת השרת העורפי.
גורמים
המשמעות של קוד מצב HTTP 503 היא שהשרת לא יכול כרגע לטפל בקשות. בדרך כלל שגיאה זו מתרחשת מכיוון שהשרת עסוק מדי או מושבתת זמנית לצורך תחזוקה.
סיבות אפשריות לתגובה 503 Service Unavailable הן:
הסיבה | תיאור | מי יכול לבצע את השלבים לפתרון בעיות |
---|---|---|
שרת בעומס יתר | שרת הקצה העורפי עמוס מדי או חורג מהקיבולת שלו ולא יכול לטפל בבעיות חדשות בקשות נכנסות של לקוחות. | משתמשי Edge בענן הציבורי והפרטי |
השרת בתחזוקה | יכול להיות שמתבצעת תחזוקה זמנית בשרת העורפי. | משתמשי Edge בענן הציבורי והפרטי |
הסיבה: עומס יתר בשרת/שרת בתחזוקה
ב-Apigee Edge, אפשר להחזיר את שגיאת 503 Service Unavailable משרת קצה עורפי באחת מהנסיבות הבאות:
- שרת עורפי עמוס/עסוק ולא יכול לטפל בבקשות חדשות.
- השרת העורפי מושבת למשך תקופה זמנית עקב תחזוקה.
אבחון
כדי לאבחן את השגיאה, אפשר להשתמש בכל אחת משלוש השיטות הבאות:
- כלי המעקב
- יומני גישה ל-NGINX
- שיחה ישירה לשרת בקצה העורפי
אפשר ללחוץ על הכרטיסיות הבאות כדי לקבל מידע על כל שיטה.
כלי המעקב
- מפעילים את סשן המעקב, ולבצע את הקריאה ל-API כדי לשחזר את הבעיה – שירות 503 לא זמין.
- בוחרים אחת מהבקשות שנכשלו ובודקים את המעקב.
- אפשר לעבור בין השלבים השונים במעקב ולאתר את מקום הכשל.
- אם מגלים ששגיאה 503 מוחזרת כתגובה משרת היעד,
הסיבה לשגיאה 503 היא שרת היעד.
הנה צילום מסך לדוגמה של המעקב, שבו מוצגת תגובה מסוג 503 Service לא זמין משרת היעד:
- לוחצים על השלב התגובה התקבלה משרת יעד ומבצעים את
הקטעים 'כותרות תגובה' ו'תוכן תשובות' כדי לראות אם יש בהם מידע שימושי:
- כותרות התגובה עשויות להכיל את כותרת השרת, שמציינת שממנו נשלחה תגובת השגיאה.
- יכול להיות שתוכן התשובה מכיל מידע נוסף על הסיבה שרת היעד שלח את קוד התגובה 503.
- מוודאים שהשגיאה 503 מגיעה משרת היעד
הערכים של X-Apigee-fault-source ו-X-Apigee-fault-code ב-AX
(תיעוד הנתונים מ-Analytics) השלב במעקב לפי השלבים הבאים:
- לוחצים על שלב ה-AX (הקלטת נתונים ב-Analytics) כמו שמוצג בצילום המסך למטה:
- גוללים למטה לקטע 'פרטי השלב' אל הקטע 'כותרות תגובה' וקובעים את הערכים של X-Apigee-fault-code ו-X-Apigee-fault-source כפי שמוצג בהמשך:
- אם הערכים של X-Apigee-fault-source ו-X-Apigee-fault-code תואמים לערכים
שמוצג בטבלה הבאה, אפשר לאשר ששגיאה 503 מגיעה
שרת יעד:
כותרות של תגובות ערך X-Apigee-fault-source יעד X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
- צריך לבדוק אם משתמשים בשרשור של שרת proxy. כלומר אם נקודת הקצה של שרת היעד/היעד היא
להפעיל שרת proxy אחר ב-Apigee. כדי לקבוע את זה:
- חוזרים לשלב הבקשה נשלחה לשרת היעד ואז לוחצים על הלחצן Show Curl (הצגת Curl) ומגדירים את הדומיין החלופי של שרת היעד.
- אם הכינוי של המארח של שרת היעד מפנה לכתובת אימייל חלופית של מארח, אז היא שרשור של שרת proxy. במקרה הזה, צריך לחזור על כל השלבים שלמעלה עבור הרשת שרת proxy עד שקובעים מה גורם בפועל לשגיאה 503 Service Unavailable. במקרים כאלה, השגיאה 503 Service Unavailable עשויה להתרחש בשרתי proxy אחרים בשרשרת של שלבים שונים, ואפשר לאבחן אותם באמצעות את המדריך הזה.
- אם הכינוי של מארח שרת היעד מפנה לשרת הקצה העורפי שלכם, עוברים אל רזולוציה.
יומני גישה ל-NGINX
אפשר גם לעיין ביומני lcced של NGINX כדי לקבוע אם קוד הסטטוס 503 נשלח על ידי שרת הקצה העורפי. האפשרות הזו שימושית במיוחד אם הבעיה התרחשה בעבר או אם הבעיה מתרחשת לסירוגין ולא ניתן לתעד את המעקב בממשק המשתמש. כדי לראות את המידע הזה ביומני הגישה של NGINX, צריך לפעול לפי השלבים הבאים:
- בודקים את יומני הגישה ל-NGINX.
/opt/apigee/var/log/edge-router/nginx/<org>~<env>.<port#>_access_log
- חיפוש שגיאות 503 עבור שרת ה-proxy הספציפי ל-API במהלך פרק זמן ספציפי (אם הבעיה התרחשה בעבר) או לבקשות שנכשלות עם קוד 503.
- אם יש שגיאות 503, צריך לבדוק אם השגיאה מגיעה משרת הקצה העורפי.
אם הערכים של X-Apigee-fault-source ו-X-Apigee-fault-code תואמים
ערכים מוצגים
בטבלה הבאה, שגיאה 503 מגיעה מהשרת בקצה העורפי:
כותרות של תגובות ערך X-Apigee-fault-source יעד X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode זוהי רשומה לדוגמה שמציגה את השגיאה 503 שנגרמה על ידי שרת היעד:
- בודקים את שרת ה-proxy ל-API ומוודאים שמשתמשים בו יצירת שרשורים באמצעות שרת proxy, כלומר אם שרת היעד/נקודת הקצה (endpoint) של היעד לא מפעילים שרת proxy אחר ב-Apigee. אם משתמשים צריך לחזור על כל השלבים שלמעלה לשרת ה-Proxy המשורשר עד להבין מה גורם בפועל לשגיאה 503 Service Unavailable. במקרים כאלה, 503 Service Unavailable עשוי להתרחש גם בשרתי proxy אחרים בשרשרת בשלבים אחרים, שאפשר לאבחן בעזרת המדריך הזה.
- אם אישרתם שלא השתמשתם בשרשור של שרת proxy והשגיאה 503 מגיעה שרת בקצה העורפי, ואז עוברים אל Resolution (רזולוציה).
קריאה לשרת בקצה העורפי
אפשר לבצע שיחה ישירה לשרת הקצה העורפי ולוודא שמקבלים את אותו הדבר 503 תגובה מסוג Service Unavailable התקבלה כשהבקשה נשלחה דרך Apigee Edge.
- חשוב לוודא שיש לכם את כל הכותרות הנדרשות, הפרמטרים של השאילתות ופרטי הכניסה שאתם צריכים צריך לעבור לשרת העורפי כחלק מהבקשה.
- אם השירות לקצה העורפי נגיש לציבור, אפשר להשתמש בפקודת curl, Postman או כל לקוח REST אחר, והפעלה ישירה של ה-API של השרת העורפי.
- אם שרת הקצה העורפי נגיש רק ממעבדי ההודעות, אפשר להשתמש פקודת curl, Postman או כל לקוח REST אחר, והפעלה ישירה של ה-API של שרת הקצה העורפי ממעבד ההודעות.
- מוודאים ששירות הקצה העורפי אכן מחזיר שגיאה 503 Service Unavailable.
רזולוציה
אם תוודאו שהשגיאה 503 מגיעה משרת הקצה העורפי, תוכלו לבצע את הפעולות הבאות: כדי לפתור את הבעיה:
- אם הבעיה מתרחשת כי השרת העורפי מושבת לצורך תחזוקה, אפשר להעביר את שרת הקצה העורפי למצב אונליין בסיום תקופת התחזוקה.
- אם הבעיה מתרחשת עקב עומס יתר בשרת הקצה העורפי, יש לפתור את הבעיה אם יש לכם גישה לשרת הקצה העורפי. אחרת ייתכן שתצטרכו לעבוד עם צוות השרת העורפי כדי לפתור את הבעיה.
אבחון בעיות באמצעות API Monitoring
API Monitoring מאפשר לבודד תחומי בעיות במהירות כדי לאבחן שגיאה, ביצועים, בעיות בזמן אחזור והמקור שלהן, למשל אפליקציות למפתחים, שרתי proxy ל-API, יעדים לקצה העורפי, או פלטפורמת ה-API.
ביצוע דוגמה תרחיש שמדגים איך לפתור בעיות מסוג 5xx עם ממשקי ה-API באמצעות API Monitoring. לדוגמה, ייתכן שתרצו להגדיר התראה שתופיע כשמספר המשתמשים מהתקלות messages.adaptors.http.flow.ErrorResponseCode חורגת מסף מסוים.
חובה לאסוף פרטי אבחון
אם הבעיה נמשכת גם לאחר ביצוע ההוראות שלמעלה, יש לאסוף את בפרטי האבחון הבאים, ואז ליצור קשר תמיכה ב-Apigee.
אם אתם משתמשים בענן ציבורי, עליכם לספק את הפרטים הבאים:
- שם הארגון
- שם הסביבה
- שם ה-API של ה-Proxy
- צריך להשלים את פקודת ה-curl כדי לשחזר את השגיאה 503
- קובץ מעקב שמכיל את הבקשות עם שגיאת 503 Service Unavailable
- אם שגיאות 503 לא מתרחשות כרגע, יש לציין את תקופת הזמן עם אזור הזמן. מידע כשאירעו שגיאות 503 בעבר.
אם אתם משתמשים בענן פרטי, עליכם לספק את הפרטים הבאים:
- הודעת שגיאה מלאה שנצפתה בבקשות שנכשלו.
- הארגון, שם הסביבה ושם ה-Proxy ל-API שלגביהם הבחנת בשגיאות 503.
- חבילת ה-proxy ל-API.
- קובץ מעקב שמכיל את הבקשות עם שגיאת 503 Service Unavailable.
- יומני גישה ל-NGINX.
/opt/apigee/var/log/edge-router/nginx/<org>~<env>.<port#>_access_log
- יומני מעבד ההודעות.
/opt/apigee/var/log/edge-message-processor/logs/system.log
- התקופה עם פרטי אזור הזמן שבה התרחשו שגיאות 503.