התייחסות למדדים, מאפיינים ומסננים ב-Analytics

המספר הממוצע של עסקאות, כלומר בקשות לשרת proxy ל-API, לשנייה. לתשומת ליבכם, אם שיעור השימוש את מספר העסקאות במהלך תקופת הזמן, המספר הממוצע של עסקאות השני יכול להיראות כאפס בדוחות מותאמים אישית של ממשק המשתמש אם המספר קטן משני של ספרות אחרי הנקודה העשרונית.

תחביר של API: tps

מספר בקשות ה-API שבוצעו בהצלחה שמשתמשות במטמון התגובה במקום תגובה משירות היעד.

תחביר של API: sum(cache_hit)

פונקציה זו מחזירה את מספר הרכיבים במטמון L1 (בזיכרון) לכל עסקה מעל נתון פרק זמן מסוים. לדוגמה, אם בוחרים את max לתקופה של יום, ו- באותו יום, מספר הרכיבים הגבוה ביותר במטמון הוא 12 לעסקה ספציפית, הספירה תהיה 12. לגבי avg, אם יש שלוש עסקאות במהלך השאילתה, ומספרי המטמון שלהם הם 5, 6 ו-7, הממוצע הוא 6. L1 מטמון הוא מטמון בזיכרון, בניגוד למטמון של מסד נתונים L2, כפי שמתואר במאמר רכיבים פנימיים של מטמון.

תחביר של API: avg(ax_cache_l1_count)

המספר הכולל של שגיאות מדיניות בתקופת הזמן שצוינה.

בדרך כלל קורות שגיאות שקשורות למדיניות. לדוגמה, המדיניות 'אימות מפתח API' מקפיצה שגיאה כשמועבר מפתח API לא תקין בבקשה, ומדיניות עצירת ביניים מקפיצה הודעת שגיאה אם מספר הקריאות ל-API חורג מהמגבלה שהוגדרה במדיניות. ככה. המדד הזה שימושי לאיתור נקודות בעיות פוטנציאליות בממשקי ה-API. לדוגמה, מדדי policy_error, שמקובצים לפי המאפיין Developer_app, עשויים לעזור לך לגלות שמפתח API או אסימון OAuth של אפליקציה מסוימת פג. או שאולי תראו שרת proxy ספציפי ל-API משאיר הרבה שגיאות 'מעצר ספייק', ומוביל אותך לגלות מגבלת המעצרים של שרת ה-proxy לא מביאה בחשבון עלייה בנפח התנועה בחגים.

שגיאה שקשורה למדיניות מתועדת בניתוח נתונים רק אם השגיאה הובילה לכשל ב-proxy ל-API. לדוגמה, אם המאפיין continueOnError של המדיניות מוגדר כך: true, שרת ה-proxy ל-API ממשיך לעבד בקשה גם אם המדיניות נכשלה. במקרה כזה, שגיאה שקשורה למדיניות לא תתועד ב-Analytics.

המאפיין 'שם המדיניות בנושא שגיאה' (ax_execution_fault_policy_name) שימושי לצורך קיבוץ שגיאות מדיניות לפי שם המדיניות.

כשל ביעד (כגון 404 או 503) לא נחשב ככשל במדיניות. האלה נספרות ככשלים בשרת ה-proxy ל-API (is_error).

תחביר של API: sum(policy_error)

מספר הפעמים הכולל ששרתי proxy ל-API נכשלו בתקופה שצוינה. שרת proxy יכול לקרות כשמדיניות נכשלת או כשיש כשל בסביבת זמן ריצה, כמו שגיאה מסוג 404. 503 משירות היעד.

המאפיין 'שרת proxy (apiproxy)' שימושי לקיבוץ כשלים בשרתי proxy של API לפי שרת proxy.

תחביר של API: sum(is_error)

משך הזמן (ממוצע, מינימלי או מקסימלי), באלפיות שנייה, שנדרשת ל-Edge כדי לעבד בקשות נכנסות. הזמן מתחיל כשהבקשה מגיעה Edge ומסתיים כש-Edge מעביר את הבקשה לשירות היעד.

באמצעות מאפיינים שונים תוכלו לבדוק את זמני האחזור של עיבוד בקשות לפי שרת proxy ל-API, אפליקציה למפתחים, אזור וכן הלאה.

תחביר של API: max(request_processing_latency)

גודל המטען הייעודי (payload) של הבקשה שהתקבל על ידי Edge, בבייטים.

תחביר של API: avg(request_size)

מספר הפעמים הכולל שמדיניות מטמון התגובה בוצעה במשך הזמן הנתון של התקופה.

המדיניות 'מטמון תגובה' מצורפת בשני מקומות בשרת proxy ל-API (פעם אחת ב ופעם אחת בתגובה), הוא בדרך כלל מופעל פעמיים בקריאה ל-API. מטמון 'get' וקובץ 'put' של מטמון כל הפעלה נחשבת כהפעלה אחת.

עם זאת, הביצוע של מטמון התגובות הוא 0 אם <SkipCacheLookup> הפרמטר במדיניות מקבל את הערך True (בבקשה), ו-0 אם <SkipCachePopulation> הפרמטר במדיניות מקבל את הערך True (בתשובה).

בכלי המעקב, תוכלו ללחוץ על הסמל של מטמון התגובה בקריאה ל-API שהתרחשה ולראות משתנה הזרימה של responsecache.executed אל לבדוק אם בוצעה הפעלה של מטמון (ערך של 1).

תחביר של API: sum(ax_cache_executed)

משך הזמן (ממוצע, מינימלי או מקסימלי), באלפיות שנייה, שנדרשת ל-Edge כדי לעבד תשובות מה-API. הזמן מתחיל כששרת ה-Proxy ל-API מקבל התגובה של שירות היעד, והיא מסתיימת כש-Apigee מעבירה את התגובה למקור של הקריאה החוזרת.

בעזרת מאפיינים שונים אפשר לבדוק את זמן האחזור של עיבוד התגובות באמצעות API שרת proxy, אזור וכו'.

תחביר של API: min(response_processing_latency)

גודל המטען הייעודי (payload) של התגובה שמוחזר ללקוח, בייטים.

תחביר של API: max(response_size)

המספר הכולל של 5xx תגובות משירות היעד. אלה הם שירות יעד שלא נגרמו על ידי Apigee.

תחביר של API: sum(target_error)

כמות הזמן (סיכום, ממוצע, מינימום או מקסימום), ב- אלפיות שנייה, כדי ששרת היעד יגיב לקריאה. המדד הזה מציין את הביצועים של שרתי היעד. השעה מתחילה כש-Edge מעביר בקשה לשירות היעד, והיא תסתיים כש-Edge מקבל את התגובה.

שימו לב שאם קריאה ל-API מחזירה תגובה מהמטמון (באמצעות מטמון התגובה) המדיניות הזו, למשל), הקריאה אף פעם לא תגיע לשירות היעד המדדים של זמן התגובה נרשמים ביומן.

תחביר של API: avg(target_response_time)

כמות הזמן (סיכום, ממוצע, מינימום או מקסימום), ב- אלפיות שנייה, מרגע קבלת הבקשה ב-Edge מלקוח ועד Edge שולח את התשובה בחזרה ללקוח. הזמן כולל את תקורת הרשת (כמו משך הזמן שלוקח מאזני עומסים ונתבים לבצע את פעולתם), עיבוד בקשות זמן אחזור, זמן אחזור לעיבוד תגובה וזמן יעד לתגובה (אם מוצגת תגובה) משירות היעד במקום מהמטמון).

באמצעות מאפיינים שונים תוכלו לבדוק את זמני האחזור של העיבוד באמצעות שרת proxy ל-API, אפליקציה למפתחים, אזור וכן הלאה.

תחביר של API: avg(total_response_time)

המספר הכולל של קריאות ל-API שעובדו על ידי Edge בתקופה שצוינה.

כדאי להשתמש במאפיינים כדי לקבץ את ספירות התנועה לפי הדרכים החשובות ביותר מבחינתכם.

תחביר של API: sum(message_count)

השם של מוצר ה-API שמכיל את שרתי ה-proxy ל-API. כדי לקבל המאפיין הזה, אפליקציות של מפתחים שמבצעים את הקריאות צריכות להיות משויכות לממשק API אחד או יותר מוצרים שמכילים את שרתי ה-proxy ל-API, ושרתי ה-proxy שמופעלים בהם חייבים לחפש API מפתח או אסימון OAuth שנשלחו יחד עם הקריאה ל-API. המפתח או האסימון משויכים ל-API המוצר. מידע נוסף זמין במאמר הבא: קודם כל: איך יוצרים ניתוח נתונים מלא.

אם הקריטריונים שצוינו למעלה לא מתקיימים, יופיע הערך '(not set)'. ראו גם מה הערך של ישות ניתוח נתונים '(לא מוגדר)' ממוצע?.

המפתח שמכיל את הערך של מטמון התגובה שאליו בוצעה גישה. מידע נוסף על באופן שבו המפתח בנוי למטמון תגובות, ראו מדיניות לגבי מטמון התגובות.

בכלי המעקב, כאשר בוחרים מדיניות 'מטמון תגובה' שקוראת מהמטמון או כתובה במטמון, יכולים לראות את הערך הזה במשתנה הזרימה responsecache.cachekey.

שם המטמון שמכיל את המפתחות/הערכים שנעשה בהם שימוש במדיניות 'מטמון התגובה', עם התחילית orgName__envName__. לדוגמה, אם הארגון הוא "foo," ה היא 'test', ושם המטמון הוא myCache, ה-ax_cache_name הוא foo__test__myCache.

בכלי המעקב, כשבוחרים מדיניות של מטמון תגובה, אפשר לראות את הערך הזה responsecache.cachename משתנה זרימה.

רמת המטמון ('L1' בזיכרון או 'L2') שממנה מטמון התגובה היה אחזור. מאפיין זה מציג גם את "CACHE_MISS" כשהתגובה נשלחה היעד במקום המטמון (ומטמון התגובה עבר רענון עם תגובת היעד). או כשמפתח מטמון בבקשה לא תקין. מקשי המטמון מוגבלים ל- בגודל 2KB.

בכלי המעקב, כשבוחרים את המדיניות 'מטמון תגובה', אפשר לראות את הערך הזה responsecache.cachesource משתנה זרימה.

אפשר למצוא מידע נוסף על רמות המטמון במאמר מטמון פנימי.

מפתח הצרכן (מפתח API) של אפליקציית המפתח שמבצע את הקריאות ל-API, אם עבר בבקשה כמפתחות API או נכללת באסימוני OAuth.

כדי לקבל את המאפיין הזה, יש להגדיר את שרתי ה-proxy המקבלים שיחות לבדיקה מפתח API או אסימון OAuth חוקיים. אפליקציות למפתחים מקבלות מפתחות API, שבהם אפשר להשתמש כדי ליצור אסימוני OAuth כשהאפליקציות רשומות ב-Edge. מידע נוסף זמין במאמר הבא: קודם כל: איך יוצרים ניתוח נתונים מלא.

אם הקריטריונים שצוינו למעלה לא מתקיימים, יופיע הערך '(not set)'. מידע נוסף זמין בקטע מה הערך של '(not set)' בישות של ניתוח נתונים ממוצע?.

אפליקציית המפתחים הרשומה ל-Edge מבצעת קריאות ל-API.

כדי לקבל את המאפיין הזה, אפליקציות צריכות להיות משויכות למוצר אחד או יותר של API שמכילים את שרתי ה-proxy ל-API שאליהם מתבצעת קריאה, ושרתי ה-proxy חייבים לחפש מפתח API או אסימון OAuth נשלח עם הקריאה ל-API. המפתח או האסימון מזהים את האפליקציה למפתחים. עבור מידע נוסף זמין במאמר קודם כל: איך יוצרים ניתוח נתונים מלא.

אם הקריטריונים שצוינו למעלה לא מתקיימים, יופיע הערך '(not set)'. מידע נוסף זמין בקטע מה הערך של '(not set)' בישות של ניתוח נתונים ממוצע?.

כתובת האימייל של המפתחים שנרשמו ל-Edge שהאפליקציה שלהם ביצעה את הקריאות ל-API.

כדי לקבל את המאפיין הזה, למפתחים צריכים להיות אפליקציות שמשויכות לאחד או יותר מוצרי API שמכילים את שרתי proxy ל-API, ושרתי ה-proxy חייבים לבדוק אם יש מפתח API או אסימון OAuth נשלחו עם הקריאה ל-API. המפתח או האסימון מזהים את המפתח אפליקציה. מידע נוסף זמין במאמר קודם כל: איך יוצרים נתוני ניתוח מלאים.

אם הקריטריונים שצוינו למעלה לא מתקיימים, יופיע הערך '(not set)'. מידע נוסף זמין בקטע מה הערך של '(not set)' בישות של ניתוח נתונים ממוצע?.

מזהה המפתח הייחודי שנוצר על ידי Edge בצורת org_name@@@org_name.

כדי לקבל את המאפיין הזה, למפתחים צריכים להיות אפליקציות שמשויכות לאחד או יותר מוצרי API שמכילים את שרתי ה-proxy ל-API, ושרתי ה-proxy חייבים לבדוק אם יש מפתח API או אסימון OAuth נשלחו עם הקריאות ל-API. המפתח או האסימון מזהים את למפתחים. מידע נוסף זמין במאמר קודם כל: איך יוצרים נתוני ניתוח מלאים.

אם הקריטריונים שצוינו למעלה לא מתקיימים, יופיע הערך '(not set)'. מידע נוסף זמין בקטע מה הערך של '(not set)' בישות של ניתוח נתונים ממוצע?.

קוד השגיאה. מוצרים לדוגמה: messaging.adaptors.http.flow.GatewayTimeout

הערך flow שנקרא בשרת proxy ל-API שגרם לשגיאה. לדוגמה, "PreFlow", "PostFlow," או השם של התהליך המותנה שיצרתם.

שים לב שהשם המלא שבו צריך להשתמש ב-Management API הוא ax_execution_fault_flow_name, בלי מעבר שורה.

אם לא אירעו שגיאות, יופיע הערך '(not set)'.

השם של תהליך ה-Proxy ל-API שהפעיל שגיאות, כגון "PROXY_REQ_FLOW" או 'TARGET_RESP_FLOW'.

שים לב שהשם המלא שבו צריך להשתמש ב-Management API הוא ax_execution_fault_flow_state, בלי מעבר שורה.

שם המדיניות שגרמה לשגיאה וגרמה להיכשל של הקריאה ל-API.

לתשומת ליבכם: השם המלא שבו צריך להשתמש ב-Management API הוא ax_execution_fault_policy_name, בלי מעבר שורה.

אם מדיניות מסוימת מקפיצה הודעת שגיאה אבל מאפיין הבסיס של המדיניות continueOnError מוגדרת לערך true, זרימת ה-Proxy ל-API נמשכת ללא כשל והמדיניות לא נספר במאפיין הזה.

BasePath שהוגדר ב-ProxyEndpoint של שרת ה-API ל-API. הנתיב הבסיסי לא כולל את הדומיין והיציאה של כתובת ה-URL של שרת ה-proxy ל-API. לדוגמה, אם כתובת ה-URL הבסיסית של שרת proxy ל-API היא https://apigeedocs-test.apigee.net/releasenotes/, הנתיב הבסיסי הוא /Releasenotes.

הערך מאוחסן גם במשתנה הזרימה proxy.basepath.

נתיב המשאב התווסף לנתיב הבסיס של שרת ה-proxy ל-API. לדוגמה, אם כתובת ה-proxy של ה-API כתובת ה-URL הבסיסית היא https://apigeedocs-test.apigee.net/hello/, ומתבצעת קריאה אל https://apigeedocs-test.apigee.net/hello/json, הנתיבים הם /json.

אם לא משתמשים בנתיבים, הערך יהיה ריק.

הערך מאוחסן גם במשתנה הזרימה proxy.pathsuffix.

מכיל את כתובת ה-IP של הלקוח המקורי. הערך של ax_resolved_client_ip מחושב על סמך הערכים במאפיין ax_true_client_ip x_forwarded_for_ip מאפיינים.

שימו לב שבשימוש במוצרי ניתוב כמו Akamai כדי לתעד את כתובות ה-IP האמיתיות של לקוחות, כתובת ה-IP של הלקוח מועברת ל-Edge בכותרת ה-HTTP True-Client-IP, משמש להגדרת המאפיין ax_true_client_ip.

הערך של המאפיין ax_resolved_client_ip מחושב באופן הבא:

1. אם הערך ax_true_client_ip הוא לא null ולא מכיל כתובת IP מקומית, לאחר מכן מגדירים את ax_resolved_client_ip להיות ax_true_client_ip.
2. אחרת, צריך להגדיר את ax_resolved_client_ip לכתובת ה-IP הראשונה שאינה מקומית ב- x_forwarded_for_ip.
3. אם גם ax_true_client_ip וגם x_forwarded_for_ip מכילים כתובות IP מקומיות בלבד, ואז מגדירים את ax_resolved_client_ip לערך כתובת ה-IP המקומית הראשונה ב-x_forwarded_for_ip.
4. אם גם ax_true_client_ip וגם x_forwarded_for_ip הם אפס, מגדירים את ax_resolved_client_ip להיות (not set).
5. אם ax_true_client_ip היא כתובת IP מקומית ו-x_forwarded_for_ip הערך null הוגדר בשדה ax_resolved_client_ip כ-(not set).

גרסת מערכת ההפעלה של המכשיר שביצע את השיחה.

כדאי להשתמש באפשרות הזו בתור פירוט נוסף המאפיין 'מערכת הפעלה' משפחתית (ax_ua_os_family) כדי לראות את הגרסאות של מערכות ההפעלה.

כתובת ה-IP של הלקוח שמתקשר, מאוחסנת ב-proxy.client.ip משתנה זרימה. לרוב זו כתובת ה-X-Forwarded-For של השיחה הנכנסת, זוהי כתובת ה-IP ש-Edge התקבל מלחיצת היד החיצונית האחרונה של TCP. הפעולה הזו יכולה להיות הלקוח ששולח את הקריאה או מאזן עומסים. כשיש כמה כתובות IP X-Forwarded-For. זו כתובת ה-IP האחרונה ברשימה.

כשמשתמשים במוצרי ניתוב כמו Akamai כדי לתעד את כתובות ה-IP האמיתיות של לקוחות, כתובות ה-IP של הלקוח מועברות ל-Edge בכותרת ה-HTTP True-Client-IP. הזה מתעד את כתובות ה-IP האמיתיות של הלקוח מהכותרת הזו.

כדי לקבוע את כתובת ה-IP המקורית של הלקוח, ניגשה אליה דרך ax_resolved_client_ip המאפיין, Edge משתמש במאפייני ax_true_client_ip x_forwarded_for_ip מאפיינים.

נתיב המשאב (לא כולל הדומיין) לשירות היעד, לא כולל השאילתה .

לדוגמה, היעד לדוגמה של Apigee http://mocktarget.apigee.net כוללת כמה משאבים, כולל /user, שמחזיר הודעת פתיחה. ללא קשר לאופן שבו שרת ה-proxy של ה-API קורא ל-http://mocktarget.apigee.net/user, הפרמטר request_path הוא /user.

נתיב המשאב (לא כולל הדומיין) לשירות היעד, כולל השאילתה .

לדוגמה, היעד לדוגמה של Apigee http://mocktarget.apigee.net הדוח כולל מספר משאבים, כולל משאב אחד (/user?user={name}) ושאילתה כדי להחזיר הודעת פתיחה בהתאמה אישית לשם שצוין. ללא קשר לאופן שבו אתה משתמש ב-API קריאות proxy http://mocktarget.apigee.net/user?user=Dude, ה-request_uri היא /user?user=Dude.

השם של סוכן המשתמש או סוכן התוכנה ששימשו לביצוע הקריאה ל-API. דוגמאות:

• מכשיר Pixel XL מבצע שיחה באמצעות Chrome: Mozilla/5.0 (Linux; Android 7.1.2; Pixel XL Build/NHG47N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.92 Mobile Safari/537.36
• מכשיר iPad שמבצע שיחה באמצעות Chrome: Mozilla/5.0 (iPad; CPU OS 10_2 like Mac OS X) AppleWebKit/602.1.50 (KHTML, like Gecko) CriOS/54.0.2840.91 Mobile/14C92 Safari/602.1
• cURL מטרמינל: curl/7.51.0

גרסת סוכן המשתמש.

כדאי להשתמש באפשרות הזו בתור פירוט נוסף מאפיין עם הקבוצה המשפחתית של סוכן המשתמש (ax_ua_agent_family) כדי לקבל את הגרסה של משפחת הסוכנים.

נתיב המשאב (לא כולל הדומיין) לשירות היעד, לא כולל השאילתה שמוגדרים ב-<TargetEndpoint> של שרת ה-proxy.

לדוגמה, נניח ששרת proxy ל-API קורא ליעד הבא:

<TargetEndpoint name="default">
...
<HTTPTargetConnection>
  <URL>http://mocktarget.apigee.net/user?user=Dude</URL>
</HTTPTargetConnection>

בדוגמה הזו, הפרמטר target_basepath הוא /user.

אם היעד היה:

<TargetEndpoint name="default">
...
<HTTPTargetConnection>
  <URL>http://mocktarget.apigee.net</URL>
</HTTPTargetConnection>

הפרמטר target_basepath יהיה null.

בכלי המעקב, את סמל ה-AX בסוף תרשים הזרימה, target.basepath משתנה הזרימה ממופה אל target_basepath.

קוד הסטטוס של תגובת ה-HTTP משירות היעד ל-proxy של ה-API, למשל 200, 404, 503 וכן הלאה.

הערך null פירושו שהבקשה לא הגיעה לשירות היעד. מצב זה מתרחש כאשר התגובה מוצגת על ידי המדיניות 'מטמון התגובה' או כאשר הבקשה נכשלה בעיבוד.

הוא שונה מקוד סטטוס התגובה המאפיין (response_status_code).

כתובת ה-URL המלאה של שירות היעד, שמוגדרת ב-TargetEndpoint של שרת proxy ל-API.

<TargetEndpoint name="default">
...
<HTTPTargetConnection>
  <URL>http://mocktarget.apigee.net/user?user=Dude</URL>
</HTTPTargetConnection>

בדוגמה הזו, הפרמטר target_url הוא http://mocktarget.apigee.net/user?user=Dude

לתשומת ליבכם: ניתן לשנות את כתובת ה-URL גם במהלך עיבוד ה-proxy של ה-API באמצעות target.url משתנה זרימה.

ב-proxy יצירת שרשורים ובעת שימוש בסקריפט יעדים (Node.js), כתובת ה-URL של היעד בשרת ה-proxy הקריאות היא null.

רשימת כתובות ה-IP בכותרת X-Forwarded-For.

כדי לקבוע את כתובת ה-IP המקורית של הלקוח, ניגשה אליה דרך ax_resolved_client_ip המאפיין, Edge משתמש במאפייני ax_true_client_ip x_forwarded_for_ip מאפיינים.

מבוסס על שעון של 24 שעות, השעה ב-2 ספרות שבה בוצעו קריאות ל-API. לדוגמה, קריאות ל-API שיבוצעו בשעה בין 22:00 ל-23:00, ax_hour_of_day יהיה 22.

ערך השעה הוא לפי שעון UTC.