כרגע מוצג התיעוד של Apigee Edge.
כניסה למסמכי התיעוד של
Apigee X. מידע
הנושא הזה הוא חומר עזר למדדים, מאפיינים ומסננים בניתוח נתונים. למידע נוסף על השימוש בתכונות האלה, אפשר לקרוא את הסקירה הכללית על API Analytics.
הנושא הזה מציג את שמות המדדים והמאפיינים כפי שהם מופיעים בממשק המשתמש, וכשצריך להשתמש בהם בקריאות ל-API.
- השמות של ממשק המשתמש יופיעו כשתיצרו דוחות בהתאמה אישית.
- כדאי להשתמש בשמות הספציפיים ל-API כשמקבלים מדדים, יוצרים דוח או מעדכנים הגדרה של דוח.
מדדים
בהמשך מפורטים מדדי ה-API שאפשר לאחזר בדוחות בהתאמה אישית ובקריאות ל-API לניהול.
שם הדוחות בהתאמה אישית | שם לשימוש בממשק ה-API לניהול | פונקציות | התיאור |
---|---|---|---|
ממוצע עסקאות לשנייה | tps | ללא |
מספר הטרנזקציות הממוצע לשנייה, כלומר בקשות לשרת proxy ל-API. חשוב לשים לב שאם יש לך מספר נמוך יחסית של עסקאות במהלך תקופת הזמן, מספר העסקאות הממוצע לשנייה עשוי להיראות כאפס בדוחות מותאמים אישית של ממשק המשתמש, אם המספר קטן משתי ספרות אחרי הנקודה העשרונית. תחביר API: |
היט מטמון | cache_hit | סכום |
מספר בקשות ה-API שבוצעו בהצלחה שבהן נעשה שימוש במטמון התגובות במקום בתגובה משירות היעד. תחביר API: |
מספר רכיבי המטמון של L1 | ax_cache_l1_count | ממוצע, מינימום, מקסימום |
הפונקציה מחזירה את מספר הרכיבים במטמון L1 (בזיכרון) לכל טרנזקציה במהלך תקופת זמן
נתונה. לדוגמה, אם בוחרים באפשרות תחביר API: |
שגיאות שקשורות למדיניות | policy_error | סכום |
המספר הכולל של שגיאות מדיניות במהלך התקופה שצוינה. שגיאות מדיניות מתרחשות בדרך כלל משלב התכנון. לדוגמה, לפי המדיניות 'אימות מפתח API' מופיעה הודעת שגיאה כשמועבר מפתח API לא תקין בבקשה, והמדיניות של Spike Arrest גורמת לשגיאה אם מספר הקריאות ל-API חורג מהמגבלה שמוגדרת במדיניות. לכן המדד הזה שימושי לזיהוי נקודות בעייתיות אפשריות בממשקי ה-API. לדוגמה, מדדי policy_error שמקובצים לפי המאפיין developer_app יכולים לעזור לך לגלות שפג התוקף של מפתח API או אסימון OAuth של אפליקציה מסוימת, או לגלות ששרת proxy ספציפי של API מקפיץ הרבה שגיאות Spike Arrest, וזה מאפשר לגלות שמגבלת המעצר החדה ביותר בשרת ה-proxy לא מחילה עלייה בנפח התנועה בתקופת החגים. שגיאת מדיניות מתועדת ב-Analytics רק אם השגיאה מובילה לכשל בשרת proxy ל-API.
לדוגמה, אם המאפיין המאפיין 'שם המדיניות בשגיאה' (ax_execution_fault_policy_name) שימושי לקיבוץ שגיאות מדיניות לפי שם המדיניות. כשל ביעד (כמו שגיאה 404 או 503) לא נחשב ככשל במדיניות. כשלונות אלה נספרים ככשלים בשרת proxy ל-API (is_error). תחביר API: |
שגיאות שרת proxy | is_error | סכום |
מספר הפעמים הכולל ששרתי proxy של API נכשלו במהלך תקופת הזמן שצוינה. כשל בשרת proxy יכול לקרות כשמדיניות נכשלת או כשיש כשל בזמן הריצה, למשל שגיאה 404 או 503 משירות היעד. המאפיין 'שרת proxy' (apiproxy) שימושי לקיבוץ כשלים בשרת proxy של API לפי שרת proxy. תחביר API: |
זמן אחזור של בקשת עיבוד | request_processing_latency | ממוצע, מינימום, מקסימום |
משך הזמן (ממוצע, מינימלי או מקסימלי) באלפיות השנייה, שנדרש ל-Edge בעיבוד בקשות נכנסות. השעה מתחילה כשהבקשה מגיעה ל-Edge ומסתיימת כש-Edge מעבירה את הבקשה לשירות היעד. בעזרת מאפיינים שונים אפשר לבדוק את זמן האחזור לעיבוד בקשות לפי שרת proxy של API, אפליקציית מפתח, אזור ועוד. תחביר API: |
גודל הבקשה | request_size | סכום, ממוצע, מינימום, מקס' |
גודל המטען הייעודי (payload) של הבקשה שהתקבל ב-Edge, בבייטים. תחביר API: |
מטמון תגובה הופעל | ax_cache_executed | סכום |
מספר הפעמים הכולל שמדיניות מטמון תגובה בוצעה במהלך תקופת הזמן הנתונה. מאחר שהמדיניות לגבי מטמון התגובה מצורפת בשני מקומות בשרת proxy ל-API (פעם אחת בבקשה ופעם אחת בתגובה), היא בדרך כלל מופעלת פעמיים בקריאה ל-API. פעולת 'get' ו-'put' במטמון נחשבת כל אחד כהפעלה אחת. עם זאת, הביצוע של המטמון של התגובה הוא 0 אם הרכיב
בכלי המעקב, תוכלו ללחוץ על הסמל של מטמון התגובה בקריאה ל-API שבוצעה ולהציג את
תחביר API: |
זמן אחזור לעיבוד תגובה | response_processing_latency | ממוצע, מינימום, מקסימום |
משך הזמן (ממוצע, מינימלי או מקסימלי) באלפיות השנייה, שנדרש ל-Edge לעיבוד תגובות של API. השעה מתחילה כששרת ה-proxy של ה-API מקבל את תגובת שירות היעד, ומסתיימת כש-Apigee מעבירה את התגובה למתקשר המקורי. בעזרת מאפיינים שונים אפשר לבחון את זמני האחזור לעיבוד תשובות לפי שרת proxy של API, אזור וכו'. תחביר API: |
גודל התגובה | response_size | סכום, ממוצע, מינימום, מקס' |
הגודל של המטען הייעודי (payload) של התגובה שהוחזרה ללקוח, ב-בייטים. תחביר API: |
שגיאות יעד | target_error | סכום |
המספר הכולל של 5xx תגובות משירות היעד. אלה שגיאות בשירות היעד שלא נגרמו על ידי Apigee. תחביר API: |
יעד זמן תגובה | target_response_time | סכום, ממוצע, מינימום, מקס' |
משך הזמן (סה"כ, ממוצע, מינימום או מקסימום) באלפיות השנייה, שבמהלכו שרת היעד צריך להגיב לשיחה. המדד הזה מראה את הביצועים של שרתי היעד. השעה מתחילה כש-Edge מעביר בקשה לשירות היעד ומסתיימת כש-Edge מקבל את התגובה. חשוב לשים לב שאם קריאה ל-API מחזירה תגובה מהמטמון (למשל, באמצעות המדיניות 'מטמון התגובה'), היא לעולם לא תגיע לשירות היעד ולא יתועדו מדדים של זמן יעד לתגובה. תחביר API: |
זמן תגובה כולל | total_response_time | סכום, ממוצע, מינימום, מקס' |
משך הזמן (סיכום, ממוצע, מינימום או מקסימום) באלפיות השנייה, מרגע ש-Edge מקבלת בקשה מהלקוח ועד ש-Edge שולחת את התשובה חזרה ללקוח. משך הזמן כולל את תקורת הרשת (למשל, הזמן שלוקח למאזני עומסים ולנתבים לבצע את העבודה שלהם), זמן האחזור של עיבוד בקשות, זמן האחזור של עיבוד התגובות ויעד זמן התגובה (אם התגובה מוצגת משירות היעד במקום מהמטמון). בעזרת מאפיינים שונים אפשר לבחון את זמני האחזור בעיבוד לפי שרת proxy של API, אפליקציית מפתח, אזור ועוד. תחביר API: |
תנועה | message_count | סכום |
המספר הכולל של קריאות ל-API שעובדו על ידי Edge בתקופה שצוינה. ניתן להשתמש במאפיינים כדי לקבץ ספירות של תנועת גולשים בדרכים בעלות משמעות עבורכם. תחביר API: |
מאפיינים
המאפיינים מאפשרים להציג מדדים בקבוצות בעלות משמעות. לדוגמה, הצגת הספירות הכוללות של תנועת הגולשים יכולה להיות משמעותית הרבה יותר כשמציגים אותן עבור כל אפליקציית מפתח או שרת proxy של API.
אלו המאפיינים ש-Apigee מספקת בהתאמה אישית. בנוסף, תוכלו ליצור מאפיינים משלכם, כפי שמתואר במאמר ניתוח תוכן של הודעות ב-API באמצעות ניתוח נתונים מותאם אישית.
שם הדוחות בהתאמה אישית | שם לשימוש בממשק ה-API לניהול | התיאור |
---|---|---|
ישויות ב-Apigee | ||
אסימון גישה | access_token | אסימון הגישה ל-OAuth של משתמש הקצה באפליקציה. |
מוצר API | api_product |
השם של מוצר ה-API שמכיל את שרתי ה-proxy של ה-API. כדי לקבל את המאפיין הזה, אפליקציות למפתחים שמבצעות את הקריאות צריכות להיות משויכות למוצר API אחד או יותר שמכיל שרתי proxy של ה-API, ושרתי ה-proxy שמופעלים חייבים לבדוק אם יש מפתח API או אסימון OAuth שנשלחים עם הקריאה ל-API. המפתח או האסימון משויכים למוצר API. מידע נוסף זמין במאמר הראשונה: איך ליצור נתונים מלאים של ניתוח נתונים. אם הקריטריונים שצוינו לא יתקיימו, יופיע הערך '(not set)'. ראו גם מה המשמעות של ערך '(לא מוגדר)' של ישות ניתוח נתונים? |
מפתח מטמון | ax_cache_key |
המפתח שמכיל את הערך של מטמון התגובה שאליו בוצעה גישה. מידע נוסף על אופן ההגדרה של המפתח למטמון תגובות זמין במדיניות בנושא מטמון תגובות. בכלי המעקב, כשבוחרים מדיניות של מטמון תגובה לקריאה או לכתיבה מהמטמון, אפשר לראות את הערך הזה במשתנה הזרימה |
שם המטמון | ax_cache_name |
שם המטמון שמכיל את המפתחות/הערכים שבהם נעשה שימוש במדיניות בנושא מטמון התגובה, לפניו בקידומת orgName__envName__. לדוגמה, אם הארגון הוא "foo", הסביבה היא "test" ושם המטמון הוא "myCache", הערך ax_cache_name הוא foo__test__myCache. בכלי המעקב, כשבוחרים מדיניות של מטמון תגובה, אפשר לראות את הערך הזה במשתנה הזרימה |
מקור המטמון | ax_cache_source |
רמת המטמון (מסד הנתונים "L1" בזיכרון או "L2") שממנה אוחזר מטמון התגובה. במאפיין הזה מוצג גם 'CACHE_MISS' כשהתגובה נמסרה מהיעד במקום מהמטמון (והמטמון של התגובה עבר רענון עם תגובת היעד), או כשמפתח מטמון בבקשה לא חוקי. מפתחות מטמון מוגבלים לגודל של 2KB. בכלי המעקב, כשבוחרים במדיניות 'מטמון התגובה', אפשר לראות את הערך הזה במשתנה הזרימה מידע נוסף על רמות המטמון זמין במאמר נתונים פנימיים של מטמון. |
Client ID | client_id |
מפתח הצרכן (מפתח ה-API) של האפליקציה למפתחים שמבצעת את הקריאות ל-API, בין אם הוא מועבר בבקשה כמפתחות API או נכלל באסימוני OAuth. כדי לקבל את המאפיין הזה, צריך להגדיר שרתי proxy שמקבלים קריאות לבדוק אם יש מפתח API או אסימון OAuth חוקיים. אפליקציות למפתחים מקבלות מפתחות API, שניתן להשתמש בהם ליצירת אסימוני OAuth, כשהאפליקציות נרשמות ב-Edge. מידע נוסף זמין במאמר הראשונה: איך ליצור נתונים מלאים של ניתוח נתונים. אם הקריטריונים שצוינו לא יתקיימו, יופיע הערך '(not set)'. כדאי גם לקרוא את המאמר מה המשמעות של '(לא מוגדר)' הערך של ישות ניתוח נתונים? |
אפליקציה למפתחים | developer_app |
אפליקציית הפיתוח הרשומה ב-Edge מבצעת קריאות ל-API. כדי לקבל את המאפיין הזה, צריך לשייך אפליקציות למוצר API אחד או יותר שמכילים את שרתי ה-proxy של ה-API. שרתי ה-proxy צריכים לבדוק אם יש מפתח API או אסימון OAuth שנשלחים עם הקריאה ל-API. המפתח או האסימון משמש לזיהוי האפליקציה למפתחים. למידע נוסף, אפשר לקרוא את המאמר הקטע הראשון: איך ליצור נתונים מלאים של ניתוח נתונים. אם הקריטריונים שצוינו לא יתקיימו, יופיע הערך '(not set)'. כדאי גם לקרוא את המאמר מה המשמעות של '(לא מוגדר)' הערך של ישות ניתוח נתונים? |
כתובת האימייל של המפתח | developer_email |
האימייל של המפתחים שרשומים ב-Edge, שהאפליקציה שלהם ביצעו את הקריאות ל-API. כדי לקבל את המאפיין הזה, למפתחים צריכות להיות אפליקציות שמשויכות למוצר API אחד או יותר שמכילים את שרתי ה-proxy של ה-API. שרתי ה-proxy צריכים לבדוק מפתח API או אסימון OAuth שנשלחים עם הקריאה ל-API. המפתח או האסימון משמש לזיהוי האפליקציה של המפתח. למידע נוסף, כדאי לקרוא את המאמר הקטע הראשון: איך ליצור נתונים מלאים של ניתוח נתונים. אם הקריטריונים שצוינו לא יתקיימו, יופיע הערך '(not set)'. כדאי גם לקרוא את המאמר מה המשמעות של '(לא מוגדר)' הערך של ישות ניתוח נתונים? |
מזהה מפַתח | מפתח |
מזהה המפתח הייחודי שנוצר על ידי Edge בפורמט org_name@@@unique_id. כדי לקבל את המאפיין הזה, למפתחים צריכות להיות אפליקציות שמשויכות למוצר API אחד או יותר שמכילים שרתי proxy של API, ושרתי ה-proxy צריכים לבדוק אם מפתח API או אסימון OAuth נשלחים יחד עם הקריאות ל-API. המפתח או האסימון משמשים לזיהוי המפתח. מידע נוסף זמין במאמר הראשונה: איך ליצור נתונים מלאים של ניתוח נתונים. אם הקריטריונים שצוינו לא יתקיימו, יופיע הערך '(not set)'. כדאי גם לקרוא את המאמר מה המשמעות של '(לא מוגדר)' הערך של ישות ניתוח נתונים? |
סביבה | environment | סביבת Edge שבה פרוסים שרתי proxy של API. לדוגמה: "test" או "prod". |
קוד שגיאה בשגיאה | ax_edge_execution_fault_code |
קוד השגיאה של השגיאה. לדוגמה: |
שם הזרימה בשגיאה | ax_execution_fault _flow_name |
ה-flow שצוין בשרת proxy ל-API, שהניב שגיאה. לדוגמה, "PreFlow" , "PostFlow" או השם של תהליך מותנה שיצרת. הערה: השם המלא לשימוש בממשק ה-API לניהול הוא ax_execution_fault_flow_name, ללא מעבר שורה. כאשר לא אירעו שגיאות, יופיע הערך '(not set)'. |
משאב זרימה | flow_resource | לשימוש ב-Apigee בלבד. אם אתם סקרנים, תוכלו לעיין בפוסט הזה בקהילה. |
מצב זרימה עקב שגיאה | ax_execution_fault _flow_state |
השם של זרימת ה-API של שרת ה-API גורם לשגיאות, כמו "PROXY_REQ_FLOW" או "TARGET_RESP_FLOW". הערה: השם המלא לשימוש בממשק ה-API לניהול הוא ax_execution_fault_flow_state, ללא מעבר שורה. |
מזהה התהליך של השער | gateway_flow_id | כשקריאות ל-API עוברות דרך Edge, כל קריאה מקבלת מזהה תהליך משלה בשער. לדוגמה: rrt329ea-12575-114653952-1. מזהה התהליך של השער שימושי להבחנה בין מדדים במצבים עם TPS גבוה, שבהם מאפיינים אחרים, כמו ארגון, סביבה וחותמת הזמן זהים בכל הקריאות. |
ארגון | ארגון | הארגון ב-Edge שבו פרוסים שרתי proxy של API. |
שם מדיניות בעת שגיאה | ax_execution_fault _policy_name |
שם המדיניות שגרמה לשגיאה וגרמה לכישלון הקריאה ל-API. הערה: השם המלא שיש להשתמש בו בממשק ה-API לניהול הוא ax_execution_fault_policy_name, ללא מעבר שורה. אם מדיניות מקפיצה הודעת שגיאה אבל מאפיין הבסיס של המדיניות |
שרת Proxy | apiproxy | שם המכונה (לא שם התצוגה) של שרת proxy ל-API. |
נתיב בסיס של שרת Proxy | proxy_basepath |
ה-BasePath שהוגדר ב-ProxyEndpoint של שרת ה-API. נתיב הבסיס לא כולל את הדומיין ואת החלק של היציאה מכתובת ה-URL של שרת ה-API של שרת ה-API. לדוגמה, אם כתובת ה-URL הבסיסית של שרת proxy ל-API היא https://apigeedocs-test.apigee.net/releasenotes/, נתיב הבסיס הוא /releasenotes. הערך מאוחסן גם במשתנה הזרימה |
סיומת נתיב של שרת proxy | proxy_pathsuffix |
נתיב המשאב שנוסף לנתיב הבסיס של שרת ה-proxy של ה-API. לדוגמה, אם כתובת ה-URL הבסיסית של
שרת Proxy ל-API היא אם לא נעשה שימוש ב-Pathuffix, הערך יהיה ריק. הערך מאוחסן גם במשתנה הזרימה |
גרסה של שרת proxy | apiproxy_revision | מספר הגרסה של שרת ה-API שטיפל בקריאות ל-API. לא מדובר בהכרח בגרסה האחרונה של שרת proxy ל-API. אם לשרת proxy של API יש 10 גרסאות קודמות, ייתכן שנפרס את הגרסה השמינית. בנוסף, ל-API יכולות להיות כמה גרסאות לפריסה, כל עוד לגרסאות הגרסאות יש נתיבי בסיס שונים, כפי שמתואר במאמר פריסת שרתי proxy בממשק המשתמש. |
כתובת ה-IP של הלקוח שנפתרה | ax_resolved_client_ip |
מכילה את כתובת ה-IP של הלקוח המקורי. הערך של המאפיין חשוב לשים לב שכאשר משתמשים במוצרי ניתוב כמו Akamai כדי לתעד את כתובות ה-IP האמיתיות של הלקוחות, כתובת ה-IP של הלקוח מועברת אל Edge בכותרת ה-HTTP הערך של המאפיין
|
קוד סטטוס התגובה | response_status_code | קוד הסטטוס של תגובת ה-HTTP שהועבר מ-Apigee ללקוח, כמו 200, 404, 503 וכו'. ב-Edge, אפשר להחליף את קוד הסטטוס של התשובה מהיעד בכללי מדיניות כמו assign Message ו-Raise Fault, ולכן המאפיין הזה יכול להיות שונה מהמאפיין Target Response Code (target_response_code). |
מארח וירטואלי | virtual_host | השם של המארח הווירטואלי שאליו בוצעה הקריאה ל-API. לדוגמה, לארגונים יש שני מארחים וירטואליים כברירת מחדל: default (http) ו-secure (https). |
שיחה נכנסת/לקוח | ||
כתובת IP של לקוח | client_ip | כתובת ה-IP של המערכת שמגיעה לנתב, למשל הלקוח המקורי (proxy_client_ip) או מאזן עומסים. כשיש כמה כתובות IP בכותרת X-Forwarded-For , זו כתובת ה-IP האחרונה ברשימה. |
קטגוריית מכשיר | ax_ua_device_category | סוג המכשיר שממנו בוצעה הקריאה ל-API, למשל 'טאבלט' או 'סמארטפון'. |
משפחת מערכות הפעלה | 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 של הלקוחות מועברות אל Edge בכותרת ה-HTTP כדי לקבוע את כתובת ה-IP המקורית של הלקוח, שניגשים אליה דרך המאפיין |
נתיב בקשה | request_path |
נתיב המשאב (לא כולל הדומיין) לשירות היעד, לא כולל פרמטרים של שאילתה. לדוגמה, היעד לדוגמה של Apigee |
URI של בקשה | request_uri |
נתיב המשאב (לא כולל הדומיין) לשירות היעד, כולל פרמטרים של שאילתה. לדוגמה, היעד לדוגמה של Apigee |
בקשת פועל | request_verb | פועל בקשת ה-HTTP בבקשות ה-API, כגון GET, POST, PUT, DELETE. |
סוכן משתמש | סוכן משתמש |
השם של סוכן המשתמש או סוכן התוכנה שמשמש לביצוע הקריאה ל-API. דוגמאות:
|
משפחת סוכני המשתמש | ax_ua_agent_family | המשפחה של סוכן המשתמש, למשל "Chrome Mobile" או "cURL". |
סוג סוכן המשתמש | ax_ua_agent_type | סוג סוכן המשתמש, כגון "דפדפן", "דפדפן נייד", "ספרייה" וכו'. |
הגרסה של סוכן המשתמש | ax_ua_agent_version |
הגרסה של סוכן המשתמש. כדאי להשתמש במאפיין הזה כמאפיין פירוט שני של משפחת סוכני המשתמש (ax_ua_agent_family) כדי לקבל את הגרסה של משפחת הסוכנים. |
יוצאות/יעד | ||
נתיב בסיס היעד | 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 בסוף תרשים הזרימה, משתנה הזרימה |
מארח היעד | target_host | המארח של שירות היעד. לדוגמה, אם שרת Proxy ל-API קורא
ל-http://mocktarget.apigee.net/help , ה- target_host הוא
mocktarget.apigee.net . |
כתובת IP של היעד | target_ip | כתובת ה-IP של שירות היעד שמחזיר את התגובה לשרת ה-API. |
קוד תגובה ליעד | target_response_code |
קוד הסטטוס של תגובת ה-HTTP שהוחזר על ידי שירות היעד לשרת ה-API של ה-API, למשל 200, 404, 503 וכו'. הערך null פירושו שהבקשה מעולם לא הגיעה לשירות היעד. המצב הזה קורה כשהתגובה מוגשת על ידי המדיניות בנושא מטמון התגובה או כשיש כשל בעיבוד הבקשה. הוא שונה מהמאפיין קוד סטטוס תגובה (response_status_code). |
כתובת אתר של יעד | 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 וכשמשתמשים ביעדי סקריפטים (Node.js), הפרמטר target_url בשרת ה-proxy לקריאה הוא ריק. |
X הועבר אל | x_forwarded_for_ip | הרשימה של כתובות ה-IP בכותרת כדי לקבוע את כתובת ה-IP המקורית של הלקוח, שניגשים אליה דרך המאפיין |
זמן | ||
יום בשבוע | ax_day_of_week | היום בן שלוש האותיות בשבוע שבו בוצעו קריאות ל-API. לדוגמה, ראשון, שלישי, רביעי. |
חודש | ax_month_of_year | החודש המספרי שבו בוצעו הקריאות ל-API. לדוגמה, '03' עבור מרץ. |
שעה ביום | ax_hour_of_day |
בהתבסס על שעון של 24 שעות, השעה בת 2 הספרות שבה בוצעו קריאות ל-API. לדוגמה, קריאות ל-API שבוצעו בשעה 22:00 עד 23:00, הערך ax_ hour_of_day יהיה 22. ערך השעה הוא לפי שעון UTC. |
אזור זמן | ax_geo_timezone | השמות הנפוצים של אזורי הזמן שמהם בוצעו הקריאות ל-API, למשל America/New_York ואירופה/דבלין. |
השבוע בחודש | ax_week_of_month | השבוע המספרי של החודש. לדוגמה, עבור קריאות ל-API שבוצעו בשבוע השלישי של החודש, הערך של ax_week_of_month הוא 3. |
מיקום | ||
עיר | 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. |
מונטיזציה | ||
הודעת התעלמות מעסקה של עסקה | x_apigee_mint_tx_ignoreMessage | סימון שמציין אם להתעלם מהודעות הקשורות למונטיזציה. ההגדרה היא false לכל הארגונים לייצור הכנסות. |
סטטוס עסקה של מטבעה | x_apigee_mint_tx_status | הסטטוס של בקשת מונטיזציה, למשל: הצלחה, כישלון, לא חוקית או ללא. |
מסננים
בעזרת מסננים אפשר להגביל את התוצאות למדדים עם מאפיינים ספציפיים. בהמשך מפורטים כמה מסננים לדוגמה. בעת הגדרת מסננים, יש להשתמש בשמות בסגנון API של מדדים ומאפיינים.
הפונקציה מחזירה מדדים של שרתי proxy של API עם שמות הספרים או המוזיקה:
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)
בהמשך מפורטים אופרטורים שאפשר להשתמש בהם כדי ליצור מסנני דוחות.
מפעיל | התיאור |
---|---|
in |
הכללה ברשימה |
notin |
החרגה מהרשימה |
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 |
מאפשר להשתמש בלוגיקת 'וגם' כדי לכלול יותר מביטוי מסנן אחד. המסנן כולל נתונים שעומדים בכל התנאים. |
or |
מאפשר להשתמש בלוגיקת 'או' כדי להעריך ביטויי סינון אפשריים שונים. המסנן כולל נתונים שעומדים לפחות באחד מהתנאים. |