אתם צופים במסמכי התיעוד של 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 ויעדים שהייתה בהם תנועה בשעה האחרונה:
- כדי לגשת ללוח הבקרה Recent, בוחרים באפשרות Analyze > API Monitoring > Recent בממשק המשתמש של Edge.
שימו לב לשרתי ה-proxy של ה-API ולמטרות שהיה להם שיעור שגיאות גבוה בשעה האחרונה.
לוחצים על ה-API proxy או על היעד עם אחוז שגיאות גבוה כדי להציג את הפרטים בחלונית הימנית. שימו לב לאחוז הגבוה של שגיאות 5xx בדוגמה הזו.
מידע נוסף על השלב הזה זמין במאמר מעקב אחר תעבורת API עדכנית.
שלב 2: זיהוי מגמות בנתוני המעקב של ה-API
כדי לגשת לתצוגה היסטורית של נתוני מעקב של API עבור שרתי proxy של API ויעדים שהייתה בהם תנועה עד שלושת החודשים האחרונים:
- בחלונית הימנית של לוח הבקרה 'מהזמן האחרון', בוחרים באפשרות
> הצגה בציר הזמן כדי לגשת ללוח הבקרה 'ציר הזמן'.
אפשר גם ללחוץ על Analyze > API Monitoring > Timeline (ניתוח > מעקב אחרי API > ציר זמן) בממשק המשתמש של Edge.
- צפייה במגמה של ה-API proxy או של היעד לאורך זמן. שימו לב שהמגמה הייתה עקבית ב-7 הימים האחרונים.
מידע נוסף על השלב הזה זמין במאמר זיהוי מגמות בנתוני המעקב של ה-API.
שלב 3: בדיקת בעיות מסוג 5xx
Apigee מספקת קבוצה של קודי תקלות שעוזרים לאבחן בעיות. בדרך כלל, אפשר לסווג קודי סטטוס 5xx באמצעות קוד תקלה אחד או יותר.
כדי לחקור בעיות מסוג 5xx:
- בחלונית הימנית של מרכז הבקרה של ציר הזמן, בוחרים באפשרות > הצגה בכלי החקירה כדי לגשת למרכז הבקרה של כלי החקירה.
לחלופין, אפשר ללחוץ על Analyze > API Monitoring > Investigate בממשק המשתמש של Edge.
לוח הבקרה 'חקירה' מאפשר להשוות בין פעילות יחסית של מדדים, כמו קוד שגיאה לעומת זמן. כדי לראות את הפעילות של קוד השגיאה בשעה האחרונה, מעיינים במטריצה של קוד השגיאה לעומת זמן. שימו לב לקודי התקלה שבהם נפחי החיפוש היחסיים הכי גבוהים, על סמך הצללת הצבע של הבלוק. ככל שהבלוק כהה יותר, כך נפח החיפוש היחסי גבוה יותר.
לדוגמה, קודי התקלה
policies.ratelimit.SpikeArrestViolationו-policies.ratelimit.QuotaViolationמציגים נפח יחסי גבוה יותר במטריצה הבאה:
לוחצים על הבלוק הכהה ביותר (הבלוק הראשון) בשורה
policies.ratelimit.SpikeArrestViolationכדי לראות פרטים נוספים בחלונית השמאלית.
שימו לב שמקור התקלה הוא proxy ל-API perfBenchmark_invalid_v1 וקוד הסטטוס של HTTP הוא 500. קוד סטטוס 500 הוא קוד שגיאה נפוץ בזמן ריצה להפרות של מדיניות Spike Arrest.
כדי לזהות את אפליקציות המפתחים עם שיעורי השגיאות הכי גבוהים, מעיינים בנתוני ההפצה לפי אפליקציית מפתח, שנמצאים ממש מתחת לחלונית 'הסיבה המשוערת'.
מידע נוסף על השלב הזה זמין במאמר זיהוי בעיות.
שלב 4: הגדרת התראה על שגיאות 5xx
מגדירים התראה על סמך ההקשר שנבחר בחלונית 'פרטים' של הכלי 'חקירה', כדי לקבל הודעה כשמספר קודי הסטטוס 5xx חורג מסף מסוים.
בחלונית הימנית של לוח הבקרה 'חקירה', בוחרים באפשרות
> יצירת התראה.
ממלאים את השדות בתיבת הדו-שיח של ההתראה. שדות התנאים מאוכלסים מראש בנתונים מההקשר הנוכחי. לדוגמה:
לוחצים על שמירה.
בעתיד, אם שיעור השגיאות מסוג 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 > Collections בממשק המשתמש של Edge כדי להציג את לוח הבקרה של Collections.
- לוחצים על + אוסף.
- לוחצים על שרת proxy.
- בתפריט הנפתח של הסביבה, בוחרים באפשרות prod.
- לוחצים על הבא.
- ממלאים את השדות בתיבת הדו-שיח של האוסף.
- לוחצים על שמירה.
בשלב הבא, אפשר להגדיר התראה, בדומה לשלב 4, ולהגדיר את המאפיין לאוסף שהגדרתם למעלה.
מידע נוסף על השלב הזה זמין במאמר בנושא ניהול אוספים.
שלב 7: פותרים את הבעיות שקשורות לקודי השגיאה 5xx
צריך לבצע את הפעולות המתאימות כדי לפתור את הבעיות שקשורות לקודי השגיאה 5xx. לדוגמה, בהתאם לאבחון, יכול להיות שתבצעו אחת מהמשימות הבאות:
- משתמשים ב-Apigee Sense כדי לקבוע אם העלייה הפתאומית במספר הבקשות מעוררת חשד, ומחליטים לחסום את כתובת ה-IP של הלקוח שזוהתה בדוח המותאם אישית.
- מוסיפים מדיניות מכסות כדי להגביל את מספר החיבורים שאפליקציות למפתחים יכולות ליצור עם proxy ל-API במהלך תקופה מסוימת.
- הפעלת מונטיזציה של ה-API כדי לחייב מפתחים על שימוש מעל מספר מסוים של קריאות.