אתם צופים במסמכי העזרה של Apigee Edge.
כניסה למסמכי העזרה של Apigee X. info
נסביר איך פותרים בעיות מסוג 5xx ב-API באמצעות תרחיש לדוגמה.
# | שלב | תיאור |
---|---|---|
1 | מעקב אחר תנועת ה-API מהזמן האחרון | הצגת נתוני המעקב האחרונים של ממשקי ה-API לכל שרת ה-proxy ולכל היעד של ממשק ה-API שזוהתה בהם תנועה בשעה האחרונה. להציג פירוט של שרתי proxy או יעדים של API עם שיעור שגיאות גבוה. |
2 | זיהוי מגמות בנתוני המעקב אחר ה-API | כדי לקבל תמונה רחבה יותר, תוכלו לגשת לתצוגה היסטורית של נתוני המעקב של ה-API עד 3 החודשים האחרונים. |
3 | חקירה של בעיות מסוג 5xx | כדי לבדוק לעומק את המקור לבעיות מסוג 5xx, אפשר לעיין בקודי השגיאה עם הנפחים היחסיים הגבוהים ביותר לאורך זמן. (בדרך כלל, אפשר לסווג קודי סטטוס 5xx באמצעות קוד תקלה אחד או יותר). |
4 | הגדרת התראה מסוג 5xx | אפשר להגדיר התראה כדי לקבל עדכון כשמספר קודי הסטטוס 5xx חורג מסף מסוים. |
5 | יצירת דוח בהתאמה אישית עם פרטי הלקוח (אופציונלי) | אפשר גם ליצור דוח בהתאמה אישית כדי לזהות פרטים על הלקוח שמפעיל את השגיאות מסוג 5xx. הערה: כדי ליצור דוח בהתאמה אישית, צריכה להיות לכם הרשאת אדמין ארגוני. |
6 | קיבוץ שרתי proxy ל-API באוסף | אפשר ליצור אוסף כדי לקבץ שרתים proxy של API ולהגדיר ערכי סף מתאימים להתראות לכל חברי הקבוצה, כדי לאבחן בעיות מהר יותר.
|
7 | פתרון הבעיות מסוג 5xx | על סמך החקירה והאבחון, מבצעים את הפעולות המתאימות כדי לפתור את הבעיות מסוג 5xx. |
שלב 1: מעקב אחר תנועת ה-API מהזמן האחרון
כדי להציג נתוני מעקב של ממשקי API לשרתים proxy וליעדים של ממשקי API שבהם הייתה תנועה במהלך השעה האחרונה:
- כדי לגשת למרכז הבקרה 'אירועים אחרונים', בוחרים באפשרות Analyze (ניתוח) > API Monitoring (מעקב אחר ממשקי API) > Recent (אחרונים) בממשק המשתמש של Edge.
שימו לב לשרתי ה-API וליעדים עם שיעור שגיאות גבוה בשעה האחרונה.
לוחצים על שרת ה-proxy או היעד של ה-API עם שיעור שגיאות גבוה כדי להציג פרטים בחלונית השמאלית. שימו לב לאחוז הגבוה של שגיאות 5xx בדוגמה הזו.
מידע נוסף על השלב הזה זמין במאמר מעקב אחר תעבורת ה-API מהזמן האחרון.
שלב 2: זיהוי מגמות בנתוני המעקב אחר ה-API
כדי לגשת לתצוגה היסטורית של נתוני מעקב ה-API לשרתים המתווך וליעדים של ממשקי ה-API שהיו להם תנועה ב-3 החודשים האחרונים:
- בחלונית השמאלית של מרכז הבקרה 'מהזמן האחרון', בוחרים באפשרות > הצגה בציר הזמן כדי לגשת למרכז הבקרה 'ציר הזמן'.
לחלופין, אפשר ללחוץ על Analyze (ניתוח) > API Monitoring (מעקב אחר ממשקי API) > Timeline (ציר זמן) בממשק המשתמש של Edge.
- הצגת המגמה של שרת ה-proxy או היעד של ה-API לאורך זמן. שימו לב שהמגמה הייתה עקבית ב-7 הימים האחרונים.
מידע נוסף על השלב הזה זמין במאמר זיהוי מגמות בנתוני המעקב של ממשק ה-API.
שלב 3: בודקים בעיות מסוג 5xx
ב-Apigee יש קבוצה של קודי שגיאה שיעזרו לכם לאבחן בעיות. בדרך כלל, אפשר לסווג קודי סטטוס 5xx באמצעות קוד תקלה אחד או יותר.
כדי לבדוק בעיות מסוג 5xx:
- בחלונית השמאלית של מרכז הבקרה של ציר הזמן, בוחרים באפשרות > הצגה ב-Investigate כדי לגשת למרכז הבקרה של Investigate.
לחלופין, אפשר ללחוץ על Analyze (ניתוח) > API Monitoring (מעקב אחר API) > Investigate (בדיקה) בממשק המשתמש של Edge.
בלוח הבקרה 'בדיקה' אפשר להשוות בין פעילות יחסית בין מדדים, כמו קוד שגיאה לעומת זמן. אפשר להציג את המטריצה של קוד השגיאה מול הזמן כדי לראות את הפעילות של קוד השגיאה בשעה האחרונה. שימו לב לקודי השגיאה עם נפח הנתונים היחסי הגבוה ביותר, על סמך הגוון של הבלוק. ככל שהבלוק כהה יותר, כך נפח הפעילות היחסי גבוה יותר.
לדוגמה, בקודים של השגיאות
policies.ratelimit.SpikeArrestViolation
ו-policies.ratelimit.QuotaViolation
מוצג נפח יחסי גבוה יותר במטריצה הבאה:לוחצים על הבלוק הכי כהה (הבלוק הראשון) בשורה
policies.ratelimit.SpikeArrestViolation
כדי להציג פרטים נוספים בחלונית השמאלית.
שימו לב שמקור השגיאה הוא שרת ה-API proxy perfBenchmark_invalid_v1 וקוד הסטטוס של ה-HTTP הוא 500. קוד סטטוס 500 הוא קוד שגיאה נפוץ בסביבת זמן ריצה במקרים של הפרות של מדיניות Spike Arrest.
כדי לזהות את אפליקציות המפתח עם שיעורי השגיאה הגבוהים ביותר, אפשר להציג את החלונית 'חלוקה לפי אפליקציית מפתח', שממוקמת מתחת לחלונית 'הסיבה האפשרית'.
מידע נוסף על השלב הזה זמין בקטע זיהוי בעיות.
שלב 4: מגדירים התראה מסוג 5xx
אפשר להגדיר התראה על סמך ההקשר שנבחר בחלונית 'בדיקת פרטים' כדי לקבל התראה כשמספר קודי הסטטוס 5xx חורג מסף ספציפי.
בחלונית השמאלית של לוח הבקרה של Investigate, בוחרים באפשרות > Create Alert.
ממלאים את השדות בתיבת הדו-שיח של ההתראה. שדות התנאי מאוכלסים מראש בנתונים מההקשר הנוכחי. לדוגמה:
לוחצים על שמירה.
בעתיד, אם שיעור השגיאות מסוג 5xx יחרוג מ-5% למשך 5 דקות בשרת ה-proxy של ה-API perfBenchmark_invalid_v1, תישלח התראה לכתובת האימייל שצוינה ותופיע התראה חזותית בממשק המשתמש. לדוגמה:
מידע נוסף על השלב הזה זמין במאמר הגדרת התראות.
שלב 5: יצירת דוח בהתאמה אישית עם פרטי הלקוח (אופציונלי)
אפשר גם ליצור דוח מותאם אישית כדי לזהות פרטים נוספים על הלקוח שמפעיל את השגיאות מסוג 5xx.
בדף הדוחות, דוחות בהתאמה אישית שנוצרים על סמך התראה נקראים לפי הפורמט הבא: API Monitoring Generated: alert-name
.
אפשר לגשת לדוח בהתאמה אישית שנוצר כשהגדרתם את ההתראה באחת מהדרכים הבאות:
כדי להציג את הדף 'דוחות', בוחרים באפשרות ניתוח > דוחות בהתאמה אישית > דוחות בסרגל הניווט הימני. לוחצים על שם הדוח ברשימה: API Monitoring Generated: 5xx Alert
לוחצים בתוך ההתראה שמוצגת כשהיא נוצרת. לדוגמה:
מוסיפים את המאפיינים הבאים:
- אפליקציה למפתחים
- Client-ID
- כתובת ה-IP של הלקוח
כדי להציג דוח שמבוסס על אפליקציית פיתוח ספציפית עם שיעור שגיאות גבוה, מוסיפים מסנן דומה למסנן הבא:
and (developer_app eq 'perfBenchmarkApp0')
הערה: במקרה כזה, צריך להסיר את 'אפליקציית המפתח' מרשימת המאפיינים.
לוחצים על שמירה.
מריצים את הדוח כדי להציג פרטים על אפליקציית הפיתוח ועל הלקוחות שמפעילים את קוד הסטטוס 5xx.
מידע נוסף על השלב הזה זמין במאמר יצירת דוחות בהתאמה אישית.
שלב 6: קיבוץ שרתים proxy של API לאוסף
אפשר ליצור אוסף כדי לקבץ שרתים proxy של API ולהגדיר ערכי סף מתאימים להתראות לכל חברי הקבוצה, כדי לאבחן בעיות מהר יותר.
- בוחרים באפשרות Analyze (ניתוח) > API Monitoring (מעקב אחר ממשקי API) > Collections (אוספים) בממשק המשתמש של Edge כדי להציג את מרכז הבקרה של האוספים.
- לוחצים על + אוסף.
- בוחרים באפשרות שרת proxy.
- בתפריט הנפתח של הסביבה, בוחרים באפשרות prod.
- לוחצים על הבא.
- ממלאים את השדות בתיבת הדו-שיח של האוסף.
- לוחצים על שמירה.
בשלב הבא אפשר להגדיר התראה, בדומה לשלב 4, ולהגדיר את המאפיין לאוסף שהגדרתם למעלה.
מידע נוסף על השלב הזה זמין במאמר ניהול אוספים.
שלב 7: פתרון הבעיות מסוג 5xx
מבצעים את הפעולות המתאימות כדי לפתור את הבעיות מסוג 5xx. לדוגמה, על סמך האבחון, תוכלו לבצע אחת מהמשימות הבאות:
- משתמשים ב-Apigee Sense כדי לקבוע אם העלייה החדה במספר הבקשות היא חשודה, ולהחליט אם לחסום את כתובת ה-IP של הלקוח שזוהתה בדוח המותאם אישית.
- מוסיפים מדיניות מכסות כדי להגביל את מספר החיבורים שאפליקציות הפיתוח יכולות ליצור לשרתי ה-API שלכם בפרק זמן מסוים.
- לייצר הכנסות מ-API כדי לחייב מפתחים על שימוש מעבר למספר מסוים של קריאות.