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