הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.
לעיון במסמכי התיעוד של
Apigee Edge
המאמר הזה הוא חומר עזר בנושא מדדים, מאפיינים ומסננים של Analytics. כדי לקבל מידע נוסף על השימוש בהם, אפשר לעיין במאמר סקירה כללית של API Analytics.
במאמר הזה מפורטים השמות של המדדים והמאפיינים כפי שהם מופיעים בממשק המשתמש וכפי שצריך להשתמש בהם בקריאות ל-API.
- השמות של ממשק המשתמש יוצגו לכם כשתיצרו ותנהלו דוחות בהתאמה אישית.
- כשמקבלים מדדים, יוצרים הגדרה של דוח או מעדכנים הגדרה של דוח, צריך להשתמש בשמות הספציפיים ל-API.
מדדים
בהמשך מפורטים מדדי ה-API שאפשר לאחזר בדוחות בהתאמה אישית ובקריאות ל-Apigee API.
| מדד | השם לשימוש ב-Apigee API | פונקציות | תיאור |
|---|---|---|---|
| ממוצע העסקאות לשנייה | tps |
ללא |
מספר העסקאות הממוצע, כלומר בקשות של שרתי proxy ל-API, בכל שנייה. שימו לב: אם יש לכם מספר נמוך יחסית של עסקאות במהלך תקופת הזמן, יכול להיות שהמספר הממוצע של עסקאות לשנייה יופיע כאפס בדוחות בהתאמה אישית בממשק המשתמש אם המספר קטן משני מקומות אחרי הנקודה העשרונית. תחביר API: |
| מציאה במטמון (cache hit) | cache_hit |
סכום |
מספר הבקשות המוצלחות ל-API שמשתמשות ב- תחביר API: |
| מספר הרכיבים במטמון L1 | ax_cache_l1_count |
ממוצע, מינימום, מקסימום |
מספר הרכיבים במטמון L1 (בזיכרון) לכל עסקה במהלך תקופת זמן נתונה. לדוגמה, אם בוחרים תחביר API: |
| שגיאות שקשורות למדיניות | policy_error |
סכום |
המספר הכולל של שגיאות שקשורות למדיניות בטווח הזמן שצוין. שגיאות שקשורות למדיניות מתרחשות בדרך כלל כחלק מהעיצוב. לדוגמה, מדיניות שגיאת מדיניות נרשמת ביומן של ניתוח הנתונים רק אם השגיאה גורמת לכשל ב-proxy ל-API.
לדוגמה, אם המאפיין המאפיין 'שם המדיניות בשגיאה' ( כשל ביעד (למשל תחביר API: |
| שגיאות בשרת ה-proxy | is_error |
סכום |
המספר הכולל של הפעמים שבהן שרתי proxy של API נכשלו בטווח הזמן שצוין. שגיאה בשרת proxy
יכולה להתרחש כשמדיניות נכשלת או כשמתרחשת שגיאת זמן ריצה, כמו המאפיין Proxy ( תחביר API: |
| זמן האחזור של עיבוד הבקשה | request_processing_latency |
ממוצע, מינימום, מקסימום |
משך הזמן (ממוצע, מינימלי או מקסימלי), באלפיות השנייה, שנדרש ל-Apigee לעיבוד בקשות נכנסות. הזמן מתחיל כשהבקשה מגיעה ל-Apigee ומסתיים כש-Apigee מעביר את הבקשה לשירות היעד. באמצעות מאפיינים שונים, אפשר לבדוק את זמן האחזור של עיבוד הבקשות לפי שרת proxy ל-API, לפי אפליקציה של מפתח, לפי אזור וכן הלאה. תחביר API: |
| גודל הבקשה | request_size |
סכום, ממוצע, מינימום, מקסימום |
גודל המטען הייעודי (payload) של הבקשה שהתקבל על ידי Apigee, בבייטים. תחביר API: |
| מטמון התשובות הופעל | ax_cache_executed |
סכום |
המספר הכולל של הפעמים שבהן בוצעה מדיניות מכיוון שמדיניות עם זאת, הביצוע של מטמון התגובות הוא 0 אם הערך של הרכיב בכלי לניפוי באגים, אפשר ללחוץ על הסמל תחביר API: |
| זמן האחזור של עיבוד התגובה | response_processing_latency |
ממוצע, מינימום, מקסימום |
משך הזמן (ממוצע, מינימלי או מקסימלי), במילישניות, שלוקח ל-Apigee לעבד תגובות של API. המדידה מתחילה כש-proxy ל-API מקבל את התגובה של שירות היעד ומסתיימת כש-Apigee מעביר את התגובה למתקשר המקורי. באמצעות מאפיינים שונים, אפשר לבחון את זמן האחזור של עיבוד התגובה לפי שרת proxy של API, אזור וכו'. תחביר API: |
| גודל התשובה | response_size |
סכום, ממוצע, מינימום, מקסימום |
גודל מטען הייעודי (payload) של התגובה שהוחזר ללקוח, בבייטים. תחביר API: |
| שגיאות שקשורות ליעד | target_error |
סכום |
המספר הכולל של תגובות שגיאה משירות היעד. אלה שגיאות בשירות היעד שלא נגרמו על ידי Apigee. תחביר API: |
| זמן תגובה רצוי | target_response_time |
סכום, ממוצע, מינימום, מקסימום |
משך הזמן (סכום, ממוצע, מינימום או מקסימום), באלפיות השנייה, שחלף עד שהשרת של היעד הגיב לקריאה. המדד הזה מראה את הביצועים של שרתי היעד. הזמן מתחיל כש-Apigee מעביר בקשה לשירות היעד ומסתיים כש-Apigee מקבל את התגובה. שימו לב שאם קריאה ל-API מחזירה תגובה מהמטמון (לדוגמה, באמצעות המדיניות תחביר API: |
| זמן התגובה הכולל | total_response_time |
סכום, ממוצע, מינימום, מקסימום |
משך הזמן (סכום, ממוצע, מינימום או מקסימום), במילישניות, מרגע ש-Apigee מקבל בקשה מלקוח ועד ש-Apigee שולח את התגובה בחזרה ללקוח. הזמן כולל תקורה של הרשת (כמו הזמן שלוקח למאזני עומסים ולנתבים לבצע את העבודה שלהם), חביון של עיבוד בקשות, חביון של עיבוד תגובות וזמן תגובה של היעד (אם התגובה מוגשת משירות היעד במקום מהמטמון). באמצעות מאפיינים שונים, אפשר לבחון את זמן האחזור של העיבוד לפי proxy ל-API, אפליקציה למפתחים, אזור וכו'. תחביר API: |
| תעבורת נתונים | message_count |
סכום |
המספר הכולל של קריאות ל-API שעובדו על ידי Apigee בתקופת הזמן שצוינה. אפשר להשתמש במאפיינים כדי לקבץ את נתוני התנועה באופן שהכי משמעותי לכם. תחביר API: |
| מונטיזציה | |||
| עמלות | fees |
סכום, ממוצע, מינימום, מקסימום |
סכום העמלה. תחביר API: |
| חלקם של המפתחים בהכנסות | x_apigee_mintng_dev_share |
סכום, ממוצע, מינימום, מקסימום |
החלק של מפתח האפליקציה או של קבוצת האפליקציות בהכנסות מעסקה. מערכת Apigee מחשבת את החלק היחסי רק אם הפעלתם את האפשרות לחלוקת הכנסות בתוכנית התמחור שלכם. הנתח מחושב לפי הנוסחה הבאה: x_apigee_mintng_dev_share = revShareGrossPrice * (share percentage)
הערך של אחוז השיתוף מאוחזר מתוכנית התמחור שלכם. תחביר API: |
| מחיר המונטיזציה | x_apigee_mintng_price |
סכום, ממוצע, מינימום, מקסימום |
ההכנסה הכוללת מעסקה.
ההכנסה מעסקה מוגדרת לערך של תחביר API: |
| מכפיל מחיר של API | x_apigee_mintng_price_multiplier |
סכום, ממוצע, מינימום, מקסימום |
הפקטור (המכפיל) שבו מכפילים את העלות לכל עסקה. העלות לכל עסקה מצוינת בתמחור של עמלות מבוססות-צריכה בתוכנית התמחור. תחביר API: |
| שיעורי מונטיזציה | x_apigee_mintng_rate |
סכום, ממוצע, מינימום, מקסימום |
התעריף שחויב על עסקה. התעריף שמוצג על עסקה מחושב לפי הנוסחה הבאה: x_apigee_mintng_rate = (consumption-based pricing rate) * perUnitPriceMultiplier value
הערך של שיעור התמחור לפי צריכה מאוחזר מתוכנית התמחור שלכם, והערך תחביר API: |
מידות
מאפיינים מאפשרים לראות את המדדים בקבוצות משמעותיות. לדוגמה, הרבה יותר שימושי לראות את ספירת התנועה הכוללת לפי כל אפליקציה של מפתח או לפי כל proxy ל-API.
בהמשך מפורטים המאפיינים ש-Apigee מספקת כברירת מחדל.
| מאפיין | השם לשימוש ב-Apigee API | תיאור |
|---|---|---|
| טוקן גישה | access_token |
אסימון גישה ל-OAuth של משתמש הקצה באפליקציה. |
| מוצר API | api_product |
|
| שם האפליקציה בקבוצת האפליקציות | app_group_app |
שם האפליקציה שמתקשרים אליה כשהיא חלק מ-AppGroup. מידע על AppGroup זמין במאמר שימוש ב-AppGroup לארגון הבעלות על אפליקציות. |
| שם קבוצת האפליקציות | app_group_name |
שם קבוצת האפליקציות שמכילה את האפליקציות שמתבצעת אליהן קריאה, אם רלוונטי. מידע על AppGroups זמין במאמר בנושא שימוש ב-AppGroups לארגון הבעלות על אפליקציות. |
| מפתח מטמון | ax_cache_key |
מפתח שמכיל את הערך בכלי לניפוי באגים, כשבוחרים מדיניות |
| שם המטמון | ax_cache_name |
שם המטמון שמכיל את המפתחות או הערכים שמשמשים את מדיניות בכלי לניפוי באגים, כשבוחרים מדיניות |
| מקור המטמון | ax_cache_source |
רמת המטמון (L1 בזיכרון או מסד נתונים L2) שממנה אוחזר בכלי לניפוי באגים, כשבוחרים במדיניות מידע נוסף על רמות מטמון זמין במאמר Cache internals. |
| מזהה לקוח | client_id |
טוקן צרכן (מפתח API) של אפליקציית המפתח שמבצעת את הקריאות ל-API, בין אם הוא מועבר בבקשה כמפתחות API או כלול באסימוני OAuth. כדי לקבל את המאפיין הזה, צריך להגדיר את השרתים הפרוקסי שמקבלים קריאות כך שיבדקו אם יש מפתח API או אסימון OAuth תקפים. אפליקציות למפתחים מקבלות מפתחות API, שאפשר להשתמש בהם כדי ליצור אסימוני OAuth, כשהאפליקציות רשומות ב-Apigee. מידע נוסף זמין במאמר בנושא יצירת נתוני ניתוח מלאים. אם הקריטריונים שלמעלה לא מתקיימים, יופיע הערך |
| אפליקציה למפתחים | developer_app |
אפליקציה למפתחים שרשומה ב-Apigee ושולחת קריאות ל-API. כדי לקבל את המאפיין הזה, צריך לשייך את האפליקציות למוצר API אחד או יותר שמכיל את שרתי ה-proxy של ה-API שאליהם מתבצעת הקריאה. בנוסף, שרתי ה-proxy צריכים לבדוק אם מפתח API או טוקן OAuth נשלחים עם הקריאה ל-API. המפתח או האסימון מזהים את אפליקציית המפתח. מידע נוסף זמין במאמר איך יוצרים נתוני ניתוח מלאים? אם הקריטריונים שלמעלה לא מתקיימים, יופיע הערך |
| כתובת האימייל של המפתח | developer_email |
|
| מזהה המפתח | developer |
מזהה מפתח ייחודי שנוצר על ידי Apigee בפורמט
כדי לקבל את המאפיין הזה, מפתחי אפליקציות וקבוצות אפליקציות צריכים לשייך אפליקציות למוצרי API אחד או יותר שמכילים את שרתי ה-proxy של ה-API שאליהם מתבצעות הקריאות. שרתי ה-proxy צריכים לבדוק אם נשלח מפתח API או אסימון OAuth עם הקריאות ל-API. המפתח או האסימון מזהים את מפתח האפליקציה או את קבוצת האפליקציות. מידע נוסף זמין במאמר איך יוצרים נתוני ניתוח מלאים? אם הקריטריונים שלמעלה לא מתקיימים, יופיע הערך |
| סביבה | environment |
סביבת Apigee שבה נפרסים שרתי ה-proxy של ה-API. לדוגמה, test או prod. |
| קוד תקלה בשגיאה | ax_edge_execution_fault_code |
קוד התקלה של השגיאה. לדוגמה:
|
| שם רצף הפעולות בשגיאה | ax_execution_fault |
תהליך בשם מסוים ב-proxy ל-API שגרם לשגיאה. לדוגמה, שימו לב: השם המלא שצריך להשתמש בו ב-Apigee API הוא אם לא היו שגיאות, יופיע הערך |
| Flow Resource | flow_resource |
לשימוש ב-Apigee בלבד. אם אתם רוצים לדעת איך משתמשים במאפיין 'זרימת משאבים' ב-Analytics, אתם יכולים לעיין במאמר איך משתמשים במאפיין 'זרימת משאבים' ב-Analytics. |
| מצב זרימה במקרה של שגיאה | ax_execution_fault |
שם מצבי הזרימה של proxy ל-API שגרמו לשגיאות, כמו שימו לב: השם המלא שצריך להשתמש בו ב-Apigee API הוא |
| מזהה תהליך של שער | gateway_flow_id |
כשקריאות ל-API עוברות דרך Apigee, כל קריאה מקבלת מזהה משלה של זרימת שער. דוגמה: rrt329ea-12575-114653952-1. מזהה זרימת השער שימושי להבחנה בין מדדים במצבים של TPS גבוה, שבהם מאפיינים אחרים כמו ארגון, סביבה וחותמת זמן זהים בכל השיחות. |
| ארגון | organization |
ארגון Apigee שבו נפרסו שרתי ה-proxy של ה-API. |
| שם המדיניות שגרמה לשגיאה | ax_execution_fault |
שם המדיניות שגרמה לשגיאה ולכישלון הקריאה ל-API. שימו לב: השם המלא שצריך להשתמש בו ב-Apigee API הוא אם מדיניות מסוימת מחזירה שגיאה, אבל מאפיין הבסיס של המדיניות |
| בשם אחרים | apiproxy |
שם המכונה (לא השם המוצג) של proxy ל-API. |
| נתיב בסיס של שרת proxy | proxy_basepath |
BasePath שהוגדר ב-ProxyEndpoint של ה-proxy ל-API. נתיב הבסיס לא כולל את החלק של הדומיין והיציאה בכתובת ה-URL של ה-proxy ל-API. לדוגמה, אם כתובת ה-URL הבסיסית של ה-proxy ל-API היא הערך מאוחסן גם ב |
| סוג פריסת שרת proxy | proxy_deployment_type |
סוג שרת ה-proxy ל-API עבור שרתי proxy שנפרסו. אם מציינים סוג של שרת proxy, התוצאות יוגבלו לסוג הזה של שרת proxy. הערכים האפשריים הם |
| סיומת נתיב שרת Proxy | proxy_pathsuffix |
נתיב המשאב נוסף לנתיב הבסיס של proxy ל-API. לדוגמה, אם כתובת ה-URL הבסיסית של שרת proxy של API היא אם לא משתמשים ב- הערך מאוחסן גם ב |
| גרסה של שרת proxy | apiproxy_revision |
מספר הגרסה של ה-proxy ל-API שטיפל בקריאות ל-API. לא בהכרח מדובר בגרסה האחרונה של ה-proxy ל-API. אם ל-proxy ל-API יש 10 גרסאות, יכול להיות שהגרסה השמינית פרוסה כרגע. בנוסף, יכול להיות של-API יש כמה גרסאות פרוסות, כל עוד לגרסאות יש נתיבי בסיס שונים, כפי שמתואר במאמר בנושא פריסת proxies. |
| כתובת IP של לקוח שנפתרה | ax_resolved_client_ip |
כתובת ה-IP של הלקוח שממנו נשלחה ההודעה. הערך הזה נגזר באמצעות ברירת המחדל של רזולוציית כתובת ה-IP של הלקוח (שמשתמשת רק בכותרת שימו לב: כשמשתמשים במוצרי ניתוב כמו Akamai כדי לתעד את כתובות ה-IP האמיתיות של לקוחות, כתובת ה-IP של הלקוח מועברת אל Apigee בכותרת ה-HTTP בהתנהגות ברירת המחדל, הערך של המאפיין
|
| קוד סטטוס התגובה | response_status_code |
קוד סטטוס של תגובת HTTP שמועבר מ-Apigee ללקוח, כמו 200, 404, 503 וכן הלאה. ב-Apigee, אפשר להחליף את קוד הסטטוס של התגובה מהיעד באמצעות כללי מדיניות כמו AssignMessage policy ו-RaiseFault policy. לכן, יכול להיות שהמאפיין הזה יהיה שונה מהמאפיין Target Response Code (target_response_code). |
| מארח וירטואלי | virtual_host |
השם של המארח הווירטואלי שאליו בוצעה קריאה ל-API. מידע נוסף זמין במאמר מידע על סביבות וקבוצות סביבות. |
| Inbound/Client | ||
| כתובת ה-IP של הלקוח | client_ip |
כתובת ה-IP של המערכת שפוגעת בנתב, כמו הלקוח המקורי (proxy_client_ip) או מאזן עומסים. אם יש כמה כתובות IP בכותרת X-Forwarded-For, זו כתובת ה-IP האחרונה שמופיעה. |
| קטגוריית מכשיר | ax_ua_device_category |
סוג המכשיר שממנו בוצעה הקריאה ל-API, למשל Tablet או Smartphone. |
| משפחת מערכות ההפעלה | ax_ua_os_family |
שם המשפחה של מערכת ההפעלה של המכשיר שמבצע את השיחה, כמו Android או iOS. |
| גרסת OS | ax_ua_os_version |
גרסת מערכת ההפעלה של המכשיר שממנו מתבצעת השיחה. מומלץ להשתמש במאפיין הזה כמאפיין שני לניתוח מעמיק עם המאפיין 'שם המשפחה של מערכת ההפעלה' (ax_ua_os_family) כדי לראות את הגרסאות של מערכות ההפעלה. |
| כתובת ה-IP של לקוח ה-Proxy | proxy_client_ip |
כתובת ה-IP של הלקוח שמתקשר, שמאוחסנת ב |
| כתובת ה-IP של הלקוח שהופנה | ax_true_client_ip |
כשמשתמשים במוצרי ניתוב כמו Akamai כדי לתעד את כתובות ה-IP האמיתיות של לקוחות, כתובות ה-IP של הלקוחות מועברות אל Apigee בכותרת ה-HTTP |
| נתיב הבקשה | request_path |
נתיב המשאב (לא כולל הדומיין) לשירות היעד, לא כולל פרמטרים של שאילתות. לדוגמה, יעד הדוגמה של Apigee |
| URI של בקשה | request_uri |
נתיב המשאב (לא כולל הדומיין) לשירות היעד, כולל פרמטרים של שאילתות. לדוגמה, יעד לדוגמה של Apigee |
| פועל הבקשה | request_verb |
פועל של בקשת HTTP בבקשות ה-API, כמו GET, POST, PUT, DELETE. |
| סוכן משתמש | useragent |
השם של סוכן המשתמש או סוכן התוכנה שדרכו מתבצעת הקריאה ל-API. דוגמאות:
|
| משפחה של סוכן משתמש | ax_ua_agent_family |
המשפחה של ה-useragent, כמו Chrome Mobile או curl. |
| סוג סוכן המשתמש | ax_ua_agent_type |
סוג סוכן המשתמש, כמו Browser, Mobile Browser, Library וכן הלאה. |
| גרסת סוכן המשתמש | ax_ua_agent_version |
גרסת הסוכן המשתמש. מומלץ להשתמש במאפיין הזה כמאפיין שני לניתוח מעמיק עם מאפיין משפחת סוכן המשתמש (ax_ua_agent_family) כדי לקבל את הגרסה של משפחת הסוכן. |
| יוצא/יעד | ||
| יעד | target |
נקודת הקצה (endpoint) שאליה מטרגטים את הבקשה. לדוגמה, default. |
| נתיב בסיס ליעד | target_basepath |
נתיב המשאב (לא כולל הדומיין) לשירות היעד, לא כולל פרמטרים של שאילתות, שמוגדר ב- לדוגמה, נניח ש-proxy ל-API קורא ליעד הבא: <TargetEndpoint name="default"> ... <HTTPTargetConnection> <URL>http://mocktarget.apigee.net/user?user=Dude</URL> </HTTPTargetConnection> בדוגמה הזו, target_basepath הוא אם היעד היה: <TargetEndpoint name="default"> ... <HTTPTargetConnection> <URL>http://mocktarget.apigee.net</URL> </HTTPTargetConnection> הערך של target_basepath יהיה null. בכלי לניפוי באגים, כשבוחרים בסמל AX בסוף תרשים הזרימה, |
| שם שירות gRPC | x_apigee_grpc_service_name |
המאפיין הזה רלוונטי רק אם שירות היעד הוא gRPC. שם שירות gRPC. למידע על שרתי proxy של gRPC API, אפשר לעיין במאמר בנושא יצירת שרתי proxy של gRPC API. |
| סטטוס gRPC | x_apigee_grpc_status |
המאפיין הזה רלוונטי רק אם שירות היעד הוא gRPC. סטטוס הבקשה ב-gRPC. מידע על שרתי proxy של gRPC זמין במאמר יצירת שרתי proxy של gRPC API. |
| מארח היעד | target_host |
המארח של שירות היעד. לדוגמה, אם proxy ל-API קורא ל-http://mocktarget.apigee.net/help, המארח היעד הוא mocktarget.apigee.net. |
| כתובת ה-IP של היעד | target_ip |
כתובת ה-IP של שירות היעד שמחזיר את התגובה ל-proxy ל-API. |
| קוד תגובה של היעד | target_response_code |
קוד סטטוס של תגובת HTTP שמוחזר משירות היעד ל-proxy ל-API, כמו
הערך המאפיין הזה שונה מהמאפיין קוד הסטטוס של התגובה (response_status_code). |
| שם ה-RPC של gRPC | x_apigee_grpc_rpc_name |
המאפיין הזה רלוונטי רק אם שירות היעד הוא gRPC. שם ה-RPC. למידע על שרתי proxy של gRPC, אפשר לעיין במאמר בנושא יצירת שרתי proxy של gRPC API. |
| כתובת URL של יעד | target_url |
כתובת ה-URL המלאה של שירות היעד שמוגדר ב-TargetEndpoint של פרוקסי API. <TargetEndpoint name="default"> ... <HTTPTargetConnection> <URL>http://mocktarget.apigee.net/user?user=Dude</URL> </HTTPTargetConnection> בדוגמה הזו, target_url הוא
שימו לב שאפשר גם לבטל את כתובת ה-URL במהלך העיבוד של ה-proxy ל-API באמצעות בשרשור של שרתי proxy, הערך של target_url ב-proxy ששולח את הקריאה הוא null. |
| כתובת ה-IP של X-Forwarded-For | x_forwarded_for_ip |
רשימת כתובות ה-IP בכותרת כדי לקבוע את כתובת ה-IP המקורית של הלקוח, שאליה ניגשים דרך המאפיין |
| X-Forwarded-For Proto | x_forwarded_proto |
הפרוטוקול שבו הלקוח השתמש כדי להתחבר לנתב. הערכים התקינים כוללים |
| שעה | ||
| יום בשבוע | ax_day_of_week |
קיצור של יום בשבוע בן שלוש אותיות שבו בוצעו הקריאות ל-API. לדוגמה, Mon, Tue, Wed. |
| חודש | ax_month_of_year |
החודש המספרי שבו בוצעו הקריאות ל-API. לדוגמה, 03 למרץ. |
| השעה ביום | ax_hour_of_day |
השעה שבה בוצעו קריאות ל-API, בפורמט של 2 ספרות, לפי שעון של 24 שעות. לדוגמה, אם בוצעו קריאות ל-API בשעה שבין 22:00 ל-23:00, הערך של ax_hour_of_day יהיה 22. ערך הזמן הוא לפי שעון UTC. |
| אזור זמן | ax_geo_timezone |
שמות נפוצים של אזורי הזמן שמהם בוצעו הקריאות ל-API, כמו
America/New_York ו-Europe/Dublin. |
| השבוע בחודש | ax_week_of_month |
מספר שבוע בחודש. לדוגמה, אם קריאות ה-API בוצעו בשבוע השלישי של החודש, הערך של ax_week_of_month הוא 3. |
| Location | ||
| עיר | ax_geo_city |
העיר שממנה בוצעו הקריאות ל-API. |
| יבשת | ax_geo_continent |
קוד בן שתי אותיות של היבשת שממנה בוצעו הקריאות ל-API. לדוגמה,
NA לאמריקה הצפונית. |
| מדינה | ax_geo_country |
קוד בן שתי אותיות של המדינה שממנה בוצעו הקריאות ל-API. לדוגמה, US
לציון ארצות הברית. |
| אזור גיאוגרפי | ax_geo_region |
קוד עם מקף לאזור הגיאוגרפי, כמו STATE-COUNTRY. לדוגמה,
WA-US לוושינגטון, ארצות הברית. |
| אזור | ax_dn_region |
השם של מרכז הנתונים של Apigee שבו נפרסים שרתי proxy ל-API, כמו us-east-1. |
| מונטיזציה | ||
| שם קבוצת האפליקציות | app_group_name |
שם קבוצת האפליקציות שאליה חלים העמלות, אם רלוונטי. למפתחי אפליקציות, השדה הזה ריק. בהקשר של מדד העמלות, זהו AppGroup שמתאים למוצר ה-API ולתוכנית התמחור שעליהם חלה העמלה. |
| סוג העמלה | fees_type |
סוג העמלה: עמלת הקמה, עמלה חוזרת, טעינה מראש או החזר כספי. הערך הזה מאוכלס רק אם בחרתם במדד Fees. |
| מועד יצירת העמלה | created |
חותמת זמן בפורמט Unix שבה נוסף לוח התעריפים למפתח האפליקציה ולמוצר ה-API.
הערך הזה מאוכלס רק אם בחרתם במדד |
| מטבע ההכנסות | x_apigee_mintng_currency |
המטבע של ההכנסה מהעסקה מוגדר לערך של משתנה המונטיזציה במסגרת מדד העמלות, זהו המטבע של העמלה. |
| מזהה תוכנית תמחור | x_apigee_mintng_rate_plan_id |
תוכנית שיעור המונטיזציה של מפַתח האפליקציות או של קבוצת האפליקציות. |
| העסקה בוצעה בהצלחה | x_apigee_mintng_tx_success |
סטטוס המונטיזציה של העסקה מוגדר לערך של משתנה המונטיזציה transactionSuccess שתועד במדיניות DataCapture. |
| תחילת התקופה | period_start |
תחילת התקופה שעליה נגבות עמלות חוזרות. לדוגמה, אם יש לכם תשלום חודשי, זה היום הראשון של החודש. הערך הזה מאוכלס רק אם בחרתם במדד |
| סוף התקופה | period_end |
סוף התקופה שעליה נגבות עמלות חוזרות. לדוגמה, אם מדובר בתשלום חודשי, זהו היום האחרון של החודש. הערך הזה מאוכלס רק אם בחרתם במדד |
מסננים
מסננים מאפשרים להגביל את התוצאות למדדים עם מאפיינים ספציפיים. בהמשך מופיעות כמה דוגמאות למסננים. כשמגדירים מסננים, צריך להשתמש בשמות בסגנון API של מדדים ומאפיינים.
מחזירה מדדים של שרתי proxy ל-API עם השם books או music:
filter=(apiproxy in 'books','music')
הפונקציה מחזירה מדדים לשרתי proxy ל-API עם שמות שמתחילים ב-m:
filter=(apiproxy like 'm%')
הפונקציה מחזירה מדדים לשרתי proxy ל-API עם שמות שלא מתחילים ב-m:
filter=(apiproxy not like 'm%')
הפונקציה מחזירה מדדים של קריאות ל-API עם קודי סטטוס של תגובה בין 400 ל-599:
filter=(response_status_code ge 400 and response_status_code le 599)
הפונקציה מחזירה מדדים של קריאות ל-API עם קוד סטטוס תגובה של 200 וקוד תגובה של יעד 404:
filter=(response_status_code eq 200 and target_response_code eq 404)
הפונקציה מחזירה מדדים של קריאות ל-API עם קוד סטטוס תגובה של 500:
filter=(response_status_code eq 500)
הפונקציה מחזירה מדדים של קריאות ל-API שלא גרמו לשגיאות:
filter=(is_error eq 0)
המדדים שמוחזרים הם של קריאות ל-API שלא הניבו תגובות מסוג null:
filter=(response_status_code isnot null)
אלה האופרטורים שאפשר להשתמש בהם כדי ליצור מסננים לדוחות.
| אופרטור | תיאור |
|---|---|
in |
הכללה ברשימה |
notin |
החרגה מהרשימה |
is |
משתמשים ב-response_status_code is null כדי לסנן תשובות שקוד הסטטוס שלהן הוא null. |
isnot |
משתמשים ב-response_status_code isnot null כדי לסנן תשובות שקוד הסטטוס שלהן לא null. |
eq |
שווה ל-== |
ne |
לא שווה לערך, != |
gt |
גדול מ-> |
lt |
פחות מ-< |
ge |
גדול מ->= או שווה לו |
le |
קטן מהערך <= או שווה לו |
like |
הפונקציה מחזירה את הערך True אם מחרוזת התבנית תואמת לתבנית שצוינה. |
not like |
הפונקציה מחזירה false אם דפוס המחרוזת תואם לדפוס שצוין. |
similar to |
הפונקציה מחזירה את הערך true או false בהתאם לכך שהתבנית שלה תואמת למחרוזת הנתונה. היא דומה ל-like, אבל היא מפרשת את התבנית באמצעות ההגדרה של ביטוי רגולרי בתקן SQL. |
not similar to |
הפונקציה מחזירה את הערך false או true בהתאם להתאמה של התבנית למחרוזת שצוינה. היא דומה ל-not like, אבל היא מפרשת את התבנית באמצעות ההגדרה של ביטוי רגולרי בתקן SQL. |
and |
מאפשר להשתמש בלוגיקת AND כדי לכלול יותר מביטוי סינון אחד. המסנן
כולל נתונים שעומדים בכל התנאים. |
or |
מאפשר להשתמש בלוגיקת OR כדי להעריך ביטויי סינון שונים. המסנן
כולל נתונים שעומדים לפחות באחד מהתנאים. |