אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע
בהמשך מפורטות שאלות נפוצות:
- יש לי הרבה שרתי proxy ל-API. מהן כמה גישות מומלצות להגדרת התראות לכל שרתי ה-proxy של ה-API שלי?
- אילו תפקידים יכולים לגשת ל-API Monitoring?
- למה לא מופיעים בדף 'אחרונים' כל שרתי ה-API הפרוקסי?
- למה אני לא רואה גרפים של זמן האחזור בציר הזמן?
- היומנים שימושיים לזיהוי קודי הסטטוס שגורמים לשגיאות, אבל איך אפשר לזהות את מזהי המפתחים שיוצרים את הקריאות?
- האם אפשר לעקוב אחרי שרשרת של שרתי proxy?
- למה מוצג הערך 'not set' בלוחות הבקרה?
- האם API Monitoring זמין בממשק המשתמש הקלאסי או ב-Edge for the Private Cloud?
- מה זה playbook?
- איך אפשר לטפל בקודי שגיאה מסוג HTTP 429?
יש לי הרבה שרתי proxy ל-API. מהן הגישות המומלצות להגדרת התראות לכל שרתי ה-proxy של ה-API שלי?
מומלץ להשתמש בגישות הבאות:
- כדי להתחיל, מגדירים התראות לכל proxy ל-API עם ערך סף ספציפי. לדוגמה, שיעור שגיאות 4xx של 10% למשך 5 דקות. כדי לעקוב אחרי ההתראות שמופעלות, אפשר להגדיר התראות ולעיין בהיסטוריית ההתראות. הגדרת התראות נוספות לגבי שירותים ספציפיים של יעד ושרתי proxy ספציפיים של API. ממשיכים לשפר את ההתראות על סמך התצפיות.
- כדאי לבקש מהצוותים שאחראים על פיתוח ממשקי ה-API להמליץ על סף לשגיאות ועל סף לזמן האחזור לצוות התפעול שאחראי על הגדרת ההתראות.
אילו תפקידים יכולים לגשת לניטור API?
מידע על תפקידים ב-API Monitoringלמה לא מופיעים בדף 'אחרונים' כל שרתי ה-API proxy?
בלוח הבקרה Recent מוצגים רק שרתי ה-API proxy שהייתה בהם תנועה בזמן האחרון. הוא לא מציג את כל שרתי ה-proxy של ה-API בארגון. במרכז הבקרה ציר הזמן אפשר לראות נתונים של כל ה-API Proxy.למה אני לא רואה גרפים של זמן האחזור בציר הזמן?
תרשימי זמן האחזור מוצגים בציר הזמן רק אם בוחרים אזור ו-proxy ל-API, וטווח הזמן שנבחר הוא עד 7 ימים.היומנים שימושיים לזיהוי קודי הסטטוס שגורמים לשגיאות, אבל איך אפשר לזהות את מזהי המפתחים שמייצרים את הקריאות?
מזהי מפתחים לא נכללים ביומני הניטור של ה-API. כדי לאחזר מזהי מפתחים, אפשר להריץ דוח בהתאמה אישית.האם אפשר לעקוב אחרי שרשרת של שרתי proxy?
אפשר להשתמש בשרת proxy אחד ל-API כנקודת היעד של שרת proxy אחר ל-API, וכך לחבר בין שני השרתים בשרשרת proxy. עם זאת, ב-API Monitoring מתבצע רישום ביומן רק של בקשות לשרת ה-proxy הראשון בשרשרת, ולא לשרת ה-proxy של ה-API שמשמש כיעד. מידע נוסף זמין במאמר בנושא שרשור של שרתי proxy של API.למה אני רואה את הערך 'לא הוגדר' בלוחות הבקרה?
אם אין ערך ל-proxy ל-API, למקור השגיאה, לקוד השגיאה או למדיניות השגיאה, או אם אי אפשר לקבוע את הערך, בלוח הבקרה יוצג not set כמקור. דוגמאות לתרחישים שבהם הערך יכול להיות 'לא מוגדר':
- שגיאות שקשורות ללקוח
- קודי שגיאה של HTTP שמוחלפת בהם תגובת הצלחה
- קודי סטטוס HTTP 2xx (כי הם בדרך כלל לא מובילים לקודי שגיאה)
מידע נוסף על הערך not set זמין במאמר מה המשמעות של הערך (not set) בישות Analytics?
האם API Monitoring זמין בממשק המשתמש הקלאסי או ב-Edge for the Private Cloud?
בשלב הזה, Apigee API Monitoring זמין רק ללקוחות Apigee Edge Cloud Enterprise שמשתמשים בממשק המשתמש החדש של Edge.
התכונה Apigee API Monitoring לא זמינה בממשק המשתמש הקלאסי של Edge או ב-Edge לענן פרטי.
מה זה playbook?
כשמגדירים התראה, בשדה Playbook מספקים תיאור קצר של פעולות מומלצות לפתרון ההתראות כשהן מופעלות. אפשר גם לציין קישור לוויקי הפנימי או לדף הקהילה שבו מפורטות שיטות מומלצות. המידע בשדה הזה ייכלל בהתראה.איך אפשר לטפל בקודי שגיאה מסוג HTTP 429?
מדיניות המכסה ומדיניות SpikeArrest של Edge מנפיקות קוד שגיאה HTTP 429 כשחורגים ממכסה (מדיניות המכסה) או כשחורגים ממגבלת הקצב (מדיניות SpikeArrest).עם זאת, במרכז הבקרה של ההתראות, אי אפשר להגדיר התראה לקוד שגיאה HTTP 429. במקום זאת, מגדירים תנאי להתראה Traffic Mgmt Policy > Quota > Quota Violation (מדיניות לניהול תנועה > מכסה > חריגה מהמכסה), כמו שמוצג בהמשך, או Traffic Mgmt Policy > Spike Arrest > SpikeArrest Violation (מדיניות לניהול תנועה > מניעת עליות פתאומיות > חריגה ממניעת עליות פתאומיות):
