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