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