הפניה למדדים, למאפיינים ולמסננים ב-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)

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

שגיאות שקשורות למדיניות מתרחשות בדרך כלל כחלק מהעיצוב. לדוגמה, מדיניות Verify API Key (אימות מפתח API) מחזירה שגיאה כשמפתח API לא תקין מועבר בבקשה, ומדיניות Spike Arrest (מניעת עומס פתאומי) מחזירה שגיאה אם מספר הקריאות ל-API חורג מהמגבלה שמוגדרת במדיניות. לכן, המדד הזה שימושי למציאת נקודות בעייתיות פוטנציאליות בממשקי ה-API. לדוגמה, מדדים של שגיאות שקשורות למדיניות, שמקובצים לפי המאפיין developer_app, יכולים לעזור לכם לגלות שתוקף של מפתח API או של טוקן OAuth פג עבור אפליקציה מסוימת. לחלופין, יכול להיות שתגלו ש-proxy ל-API ספציפי מחזיר הרבה שגיאות Spike Arrest, וכך תבינו שמגבלת Spike Arrest של ה-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)

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

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

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

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

תחביר API: sum(ax_cache_executed)

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

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

תחביר 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). אפשר לעיין גם במאמר מה המשמעות של ערך הישות (not set) ב-Analytics?

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

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

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

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

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

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

מידע נוסף על רמות מטמון זמין במאמר Cache internals.

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

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

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

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

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

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

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

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

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

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

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

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

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

התהליך שנקרא ב-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 של proxy ל-API. נתיב הבסיס לא כולל את החלק של הדומיין והיציאה בכתובת ה-URL של ה-proxy ל-API. לדוגמה, אם כתובת ה-URL הבסיסית של שרת proxy של API היא https://apigeedocs-test.apigee.net/releasenotes/, נתיב הבסיס הוא /releasenotes.

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

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

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

הערך מאוחסן גם ב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 הם null, הפונקציה 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, כתובת ה-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
• שיחה באייפד דרך 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

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

מומלץ להשתמש במאפיין הזה כממד שני של פירוט עם המאפיין User Agent Family (משפחת סוכני משתמשים) ‏(ax_ua_agent_family) כדי לקבל את הגרסה של משפחת הסוכנים.

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

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

<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 של התגובה שהוחזר משירות היעד ל-API Proxy, כמו 200,‏ 404,‏ 503 וכן הלאה.

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

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

כתובת ה-URL המלאה של שירות היעד שמוגדר ב-TargetEndpoint של פרוקסי 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 chaining ובשימוש ב-script targets (Node.js), הערך של target_url ב-proxy שקורא הוא null.

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

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

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

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