Analytics मेट्रिक, डाइमेंशन, और फ़िल्टर का रेफ़रंस

हर सेकंड में हुए ट्रांज़ैक्शन की औसत संख्या, मतलब एपीआई प्रॉक्सी अनुरोध. ध्यान दें कि अगर इस समयावधि में आपके ट्रांज़ैक्शन की संख्या काफ़ी कम है, तो यूज़र इंटरफ़ेस (यूआई) की कस्टम रिपोर्ट में हर सेकंड पर हुए ट्रांज़ैक्शन की औसत संख्या शून्य दिख सकती है. ऐसा तब होगा, जब इनकी संख्या दशमलव के बाद के दो से कम हो.

एपीआई सिंटैक्स: tps

ऐसे एपीआई अनुरोधों की संख्या जो टारगेट की गई सेवा से मिले रिस्पॉन्स के बजाय रिस्पॉन्स कैश का इस्तेमाल करते हैं.

एपीआई सिंटैक्स: sum(cache_hit)

किसी दी गई समयावधि में, हर लेन-देन के लिए L1 (इन-मेमोरी) कैश मेमोरी में मौजूद एलिमेंट की संख्या दिखाता है. उदाहरण के लिए, अगर किसी दिन की अवधि के लिए max चुना जाता है और उस दिन किसी लेन-देन के लिए, कैश मेमोरी में मौजूद एलिमेंट की ज़्यादा से ज़्यादा संख्या 12 होगी, तो उसकी गिनती 12 होगी. avg के लिए, अगर क्वेरी की गई समयावधि में तीन लेन-देन हुए हैं और उनकी कैश संख्या 5, 6, और 7 है, तो औसत रूप से 6 है. L1 कैश मेमोरी, L2 डेटाबेस कैश मेमोरी के बजाय इन-मेमोरी कैश मेमोरी में सेव होती है. इसकी जानकारी कैश इंटरनल कैश मेमोरी में दी गई है.

एपीआई सिंटैक्स: avg(ax_cache_l1_count)

किसी तय समयावधि के दौरान, नीति से जुड़ी गड़बड़ियों की कुल संख्या.

नीति से जुड़ी गड़बड़ियां आम तौर पर डिज़ाइन के हिसाब से होती हैं. उदाहरण के लिए, 'एपीआई पासकोड की पुष्टि करें' नीति, अनुरोध में अमान्य एपीआई पासकोड पास किए जाने पर गड़बड़ी दिखाती है. साथ ही, अगर एपीआई कॉल की संख्या नीति में दी गई सीमा से ज़्यादा हो जाती है, तो स्पाइक अरेस्ट नीति के तहत गड़बड़ी की जानकारी दी जाती है. इसलिए, यह मेट्रिक आपके एपीआई में समस्या वाले संभावित स्पॉट का पता लगाने में मदद करती है. उदाहरण के लिए, developer_app डाइमेंशन के हिसाब से ग्रुप की गई policy_error मेट्रिक, यह पता लगाने में आपकी मदद कर सकती हैं कि किसी ऐप्लिकेशन के लिए, एपीआई पासकोड या OAuth टोकन की समयसीमा खत्म हो गई है. इसके अलावा, आपको यह भी दिख सकता है कि कोई खास एपीआई प्रॉक्सी बहुत सारी स्पाइक अररेस्ट गड़बड़ी दिखा रहा है. इससे आपको यह पता चल सकता है कि प्रॉक्सी की तेज़ी से होने वाली गिरफ़्तारी की सीमा से छुट्टियों के ट्रैफ़िक में बढ़ोतरी नहीं होती है.

Analytics में नीति की गड़बड़ी सिर्फ़ तब लॉग इन की जाती है, जब गड़बड़ी की वजह से एपीआई प्रॉक्सी काम नहीं कर रहा हो. उदाहरण के लिए, अगर किसी नीति का continueOnError एट्रिब्यूट, true पर सेट किया जाता है, तो नीति के काम न करने पर भी एपीआई प्रॉक्सी, अनुरोध को प्रोसेस करना जारी रखता है. ऐसे में, Analytics में नीति की गड़बड़ी को लॉग नहीं किया जाता.

'गड़बड़ी पर नीति का नाम' (ax_execution_fault_policy_name) डाइमेंशन, नीति के नाम के हिसाब से नीति की गड़बड़ियों को ग्रुप करने के लिए काम आता है.

टारगेट पूरा न होने (जैसे कि 404 या 503) को नीति का उल्लंघन नहीं माना जाता. इन्हें एपीआई प्रॉक्सी की असफलताओं (is_error) के तौर पर गिना जाता है.

एपीआई सिंटैक्स: sum(policy_error)

किसी तय समयावधि में, एपीआई प्रॉक्सी के फ़ेल होने की कुल संख्या. प्रॉक्सी तब नहीं हो सकता, जब कोई नीति काम नहीं करती या रनटाइम के दौरान कोई गड़बड़ी होती है. उदाहरण के लिए, टारगेट सेवा का 404 या 503.

प्रॉक्सी (apiप्रॉक्सी) डाइमेंशन का इस्तेमाल, प्रॉक्सी सर्वर में एपीआई की असफलताओं को ग्रुप करने के लिए किया जा सकता है.

एपीआई सिंटैक्स: sum(is_error)

दिए गए अनुरोधों को प्रोसेस करने में, Edge को मिलीसेकंड में औसत, कम से कम या ज़्यादा से ज़्यादा समय (औसत, कम से कम या ज़्यादा से ज़्यादा) लग सकता है. यह समय तब शुरू होता है, जब अनुरोध Edge पर पहुंच जाता है और जब Edge, टारगेट सेवा को अनुरोध भेज देता है, खत्म हो जाता है.

अलग-अलग डाइमेंशन का इस्तेमाल करके, एपीआई प्रॉक्सी, डेवलपर ऐप्लिकेशन, इलाके वगैरह के हिसाब से, अनुरोध प्रोसेस होने में लगने वाले समय की जांच की जा सकती है.

एपीआई सिंटैक्स: max(request_processing_latency)

Edge को मिले अनुरोध वाले पेलोड का साइज़, बाइट में.

एपीआई सिंटैक्स: avg(request_size)

किसी खास समयावधि के दौरान, रिस्पॉन्स कैश मेमोरी की नीति को लागू किए जाने की कुल संख्या.

रिस्पॉन्स कैश मेमोरी की नीति को एपीआई प्रॉक्सी में दो जगहों पर (अनुरोध में एक बार और रिस्पॉन्स में एक बार) अटैच किया जाता है. इसलिए, आम तौर पर यह एपीआई कॉल में दो बार एक्ज़ीक्यूट होती है. कैश मेमोरी में सेव किए गए डेटा को 'get' कहते हैं और कैश मेमोरी में मौजूद हर एक कैश मेमोरी को एक ही प्रोसेस के तौर पर गिना जाता है.

हालांकि, अगर नीति में मौजूद <SkipCacheLookup> एलिमेंट का आकलन, अनुरोध में सही के तौर पर होता है, तो रिस्पॉन्स कैश मेमोरी का इस्तेमाल 0 दिखाया जाता है. वहीं, अगर नीति में <SkipCachePopulation> एलिमेंट का आकलन, रिस्पॉन्स के दौरान सही पर होता है, तो यह 0 होता है.

ट्रेस टूल में, चलाए गए एपीआई कॉल में रिस्पॉन्स कैश आइकॉन पर क्लिक किया जा सकता है. साथ ही, responsecache.executed फ़्लो वैरिएबल देखा जा सकता है, ताकि यह पता लगाया जा सके कि कैश एक्ज़ीक्यूट हुआ है या नहीं (वैल्यू 1).

एपीआई सिंटैक्स: sum(ax_cache_executed)

एपीआई से मिले रिस्पॉन्स को प्रोसेस करने में, Edge को लगने वाला मिलीसेकंड में, औसतन, कम से कम या ज़्यादा से ज़्यादा समय. यह समय तब शुरू होता है, जब एपीआई प्रॉक्सी को टारगेट सेवा से रिस्पॉन्स मिलता है. यह तब खत्म होता है, जब Apigee, मूल कॉलर को जवाब देता है.

अलग-अलग डाइमेंशन का इस्तेमाल करके, एपीआई प्रॉक्सी, इलाके वगैरह के हिसाब से रिस्पॉन्स प्रोसेस होने में लगने वाले समय की जांच की जा सकती है.

एपीआई सिंटैक्स: min(response_processing_latency)

क्लाइंट को वापस किए गए रिस्पॉन्स पेलोड का साइज़, बाइट में.

एपीआई सिंटैक्स: max(response_size)

टारगेट सेवा से मिले कुल 5xx रिस्पॉन्स. टारगेट सेवा से जुड़ी ये गड़बड़ियां हैं. ये Apigee की वजह से नहीं होती हैं.

एपीआई सिंटैक्स: sum(target_error)

टारगेट सर्वर को किसी कॉल का जवाब देने में लगने वाला समय (कुल, औसत, कम से कम या ज़्यादा से ज़्यादा) मिलीसेकंड में. इस मेट्रिक से आपको पता चलता है कि टारगेट सर्वर कैसा परफ़ॉर्म कर रहे हैं. यह समय तब शुरू होता है, जब Edge, टारगेट की गई सेवा को अनुरोध भेजता है और Edge को रिस्पॉन्स मिलने पर यह खत्म हो जाता है.

ध्यान दें कि अगर कोई एपीआई कॉल, कैश मेमोरी से रिस्पॉन्स देता है (उदाहरण के लिए, रिस्पॉन्स कैश की नीति का इस्तेमाल करके), तो कॉल कभी भी टारगेट सेवा तक नहीं पहुंचेगा. साथ ही, जवाब देने के टारगेट से जुड़ी कोई मेट्रिक लॉग नहीं की जाएगी.

एपीआई सिंटैक्स: avg(target_response_time)

Edge, क्लाइंट से अनुरोध मिलने से लेकर, जब Edge क्लाइंट को जवाब भेजता है, तब मिलीसेकंड में (योग, औसत, कम से कम या ज़्यादा से ज़्यादा) लगने वाला समय. इस समय में नेटवर्क की ओर से तय की गई ज़्यादा रकम (जैसे, लोड बैलेंसर और राऊटर को अपना काम करने में लगने वाला समय), अनुरोध प्रोसेस होने में लगने वाला समय, जवाब मिलने में लगने वाला समय, और जवाब देने में लगने वाला टारगेट समय (अगर रिस्पॉन्स कैश के बजाय टारगेट सेवा से दिखाया जाता है) शामिल होता है.

अलग-अलग डाइमेंशन का इस्तेमाल करके, एपीआई प्रॉक्सी, डेवलपर ऐप्लिकेशन, इलाके वगैरह के हिसाब से, प्रोसेसिंग के इंतज़ार में लगने वाले समय का पता लगाया जा सकता है.

एपीआई सिंटैक्स: avg(total_response_time)

किसी तय समयावधि में, Edge से प्रोसेस किए गए एपीआई कॉल की कुल संख्या.

डाइमेंशन का इस्तेमाल करके, ट्रैफ़िक की गिनती को ऐसे तरीके से ग्रुप करें जो आपके लिए सबसे ज़्यादा काम के हों.

एपीआई सिंटैक्स: sum(message_count)

उस एपीआई प्रॉडक्ट का नाम जिसमें एपीआई प्रॉक्सी मौजूद हैं. यह डाइमेंशन पाने के लिए, कॉल करने वाले डेवलपर ऐप्लिकेशन को, एपीआई प्रॉक्सी वाले एक या ज़्यादा एपीआई प्रॉडक्ट से जुड़े होने चाहिए. साथ ही, कॉल किए जा रहे प्रॉक्सी की जांच करनी होगी, ताकि एपीआई कॉल के साथ भेजे गए एपीआई पासकोड या OAuth टोकन की जांच की जा सके. कुंजी या टोकन, एपीआई प्रॉडक्ट से जुड़ा होता है. ज़्यादा जानकारी के लिए, सबसे पहले ये काम करना: आंकड़ों का पूरा डेटा कैसे जनरेट करें लेख पढ़ें.

अगर ऊपर दी गई शर्तें पूरी नहीं होती हैं, तो आपको "(not set)" वैल्यू दिखेगी. यह भी देखें Analytics इकाई की वैल्यू "(not set)" का क्या मतलब होता है?.

वह कुंजी जिसमें ऐक्सेस की गई रिस्पॉन्स कैश वैल्यू है. रिस्पॉन्स कैश के लिए कुंजी को बनाने के तरीके के बारे में ज़्यादा जानने के लिए, रिस्पॉन्स कैश से जुड़ी नीति देखें.

ट्रेस टूल में, जब रिस्पॉन्स कैश से जुड़ी कोई ऐसी नीति चुनी जाती है जिसे कैश मेमोरी से पढ़ा गया हो या उसमें लिखा गया हो, तो इस वैल्यू को responsecache.cachekey फ़्लो वैरिएबल में देखा जा सकता है.

कैश मेमोरी का नाम जिसमें रिस्पॉन्स कैश नीति में इस्तेमाल की गई कुंजियां/वैल्यू मौजूद हैं. इसकी शुरुआत में orgName__envName__ होता है. उदाहरण के लिए, अगर संगठन "foo" है, तो एनवायरमेंट "test" होगा और कैश मेमोरी का नाम "myकैश" है. ऐसे में, ax_cache_name foo__test__mycache है.

ट्रेस टूल में, रिस्पॉन्स कैश से जुड़ी कोई नीति चुनने पर, इस वैल्यू को responsecache.cachename फ़्लो वैरिएबल में देखा जा सकता है.

कैश मेमोरी का वह लेवल ("L1" इन-मेमोरी या "L2" डेटाबेस) जिससे रिस्पॉन्स कैश वापस पाया गया. इस डाइमेंशन में "CACHE_MISS" भी दिखता है. जब रिस्पॉन्स, कैश के बजाय टारगेट से डिलीवर किया गया था और रिस्पॉन्स कैश को टारगेट रिस्पॉन्स के साथ रीफ़्रेश किया गया था; या अनुरोध में दी गई कैश कुंजी अमान्य है. कैश कुंजी का साइज़ 2 केबी से ज़्यादा नहीं होना चाहिए.

ट्रेस टूल में, रिस्पॉन्स कैश से जुड़ी नीति चुनने पर, आपको यह वैल्यू responsecache.cachesource फ़्लो वैरिएबल में दिख सकती है.

कैश लेवल के बारे में ज़्यादा जानकारी के लिए, कैश मेमोरी देखें.

एपीआई कॉल करने वाले डेवलपर ऐप्लिकेशन की उपभोक्ता कुंजी (एपीआई पासकोड), चाहे वह अनुरोध को एपीआई पासकोड के तौर पर पास किया गया हो या OAuth टोकन में शामिल किया गया हो.

यह डाइमेंशन पाने के लिए, कॉल पाने वाले प्रॉक्सी को कॉन्फ़िगर करना ज़रूरी है, ताकि यह जांचा जा सके कि कोई मान्य एपीआई पासकोड या OAuth टोकन है या नहीं. जब ऐप्लिकेशन को Edge में रजिस्टर किया जाता है, तब डेवलपर ऐप्लिकेशन को एपीआई कुंजियां मिलती हैं. इनका इस्तेमाल करके, OAuth टोकन जनरेट किए जा सकते हैं. ज़्यादा जानकारी के लिए, सबसे पहले ये काम करना: आंकड़ों का पूरा डेटा कैसे जनरेट करें लेख पढ़ें.

अगर ऊपर दी गई शर्तें पूरी नहीं होती हैं, तो आपको "(not set)" वैल्यू दिखेगी. Analytics में मौजूद इकाई की वैल्यू "(not set)" का क्या मतलब होता है? भी देखें.

Edge रजिस्टर किया गया डेवलपर ऐप्लिकेशन है जो एपीआई कॉल कर रहा है.

यह डाइमेंशन पाने के लिए, ऐप्लिकेशन को एक या एक से ज़्यादा एपीआई प्रॉडक्ट से जोड़ना होगा. इनमें वे एपीआई प्रॉक्सी शामिल हैं जिन्हें कॉल किया जा रहा है. साथ ही, प्रॉक्सी को एपीआई कॉल के साथ भेजे गए एपीआई पासकोड या OAuth टोकन की जांच करनी होगी. कुंजी या टोकन, डेवलपर ऐप्लिकेशन की पहचान करता है. ज़्यादा जानकारी के लिए, सबसे पहले, बुनियादी बातें: आंकड़ों का पूरा डेटा कैसे जनरेट करें लेख देखें.

अगर ऊपर दी गई शर्तें पूरी नहीं होती हैं, तो आपको "(not set)" वैल्यू दिखेगी. Analytics में मौजूद इकाई की वैल्यू "(not set)" का क्या मतलब होता है? भी देखें.

EDGE में रजिस्टर उन डेवलपर का ईमेल पता जिनके ऐप्लिकेशन ने एपीआई कॉल किए थे.

यह डाइमेंशन पाने के लिए, डेवलपर के पास एक या एक से ज़्यादा एपीआई प्रॉडक्ट से जुड़े ऐप्लिकेशन होने चाहिए. इनमें, कॉल किए जा रहे एपीआई प्रॉक्सी शामिल होने चाहिए. साथ ही, प्रॉक्सी को एपीआई कॉल से भेजे गए एपीआई पासकोड या OAuth टोकन की जांच करनी होगी. कुंजी या टोकन से डेवलपर ऐप्लिकेशन की पहचान होती है. ज़्यादा जानकारी के लिए, सबसे ज़रूरी जानकारी: आंकड़ों का पूरा डेटा कैसे जनरेट करें लेख देखें.

अगर ऊपर दी गई शर्तें पूरी नहीं होती हैं, तो आपको "(not set)" वैल्यू दिखेगी. Analytics में मौजूद इकाई की वैल्यू "(not set)" का क्या मतलब होता है? भी देखें.

org_name@@@unique_id के फ़ॉर्मैट में, Edge से जनरेट किया गया यूनीक डेवलपर आईडी.

यह डाइमेंशन पाने के लिए, डेवलपर के पास एक या एक से ज़्यादा एपीआई प्रॉडक्ट से जुड़े ऐप्लिकेशन होने चाहिए. इनमें वे एपीआई प्रॉक्सी शामिल हैं जिन्हें कॉल किया जा रहा है. साथ ही, प्रॉक्सी को एपीआई कॉल के साथ भेजे गए एपीआई पासकोड या OAuth टोकन की जांच करनी होगी. कुंजी या टोकन से डेवलपर की पहचान होती है. ज़्यादा जानकारी के लिए, सबसे पहली बात: आंकड़ों का पूरा डेटा कैसे जनरेट करें लेख पढ़ें.

अगर ऊपर दी गई शर्तें पूरी नहीं होती हैं, तो आपको "(not set)" वैल्यू दिखेगी. Analytics में मौजूद इकाई की वैल्यू "(not set)" का क्या मतलब होता है? भी देखें.

गड़बड़ी का गलत कोड. उदाहरण के लिए: messaging.adaptors.http.flow.GatewayTimeout

एपीआई प्रॉक्सी में नाम वाला flow, जिसकी वजह से गड़बड़ी हुई है. उदाहरण के लिए, "PreFlow", "PostFlow" या आपके बनाए गए कंडीशनल फ़्लो का नाम.

ध्यान दें कि मैनेजमेंट एपीआई में इस्तेमाल किया जाने वाला पूरा नाम ax_execution_fault_flow_name है. इसमें लाइन ब्रेक नहीं है.

जहां कोई गड़बड़ी नहीं हुई, वहां आपको "(not set)" वैल्यू दिखेगी.

एपीआई प्रॉक्सी फ़्लो का नाम बताता है कि गड़बड़ियां बताई गई हैं, जैसे कि "PROXY_REQ_FLOW" या "TARGET_RESP_FLOW."

ध्यान दें कि मैनेजमेंट एपीआई में इस्तेमाल किया जाने वाला पूरा नाम ax_execution_fault_flow_state है, इसमें लाइन ब्रेक नहीं है.

उस नीति का नाम जिसकी वजह से गड़बड़ी हुई और एपीआई कॉल पूरी नहीं हो सकी.

ध्यान दें कि मैनेजमेंट एपीआई में इस्तेमाल किया जाने वाला पूरा नाम ax_execution_fault_policy_name है. इसमें लाइन ब्रेक नहीं है.

अगर किसी नीति के तहत गड़बड़ी दिखती है, लेकिन नीति के रूट एट्रिब्यूट continueOnError को true पर सेट किया जाता है, तो एपीआई प्रॉक्सी फ़्लो बिना रुकावट के जारी रहता है. साथ ही, नीति के दौरान हुई गड़बड़ी को इस डाइमेंशन में नहीं गिना जाता.

एपीआई प्रॉक्सी प्रॉक्सीEndpoint पर कॉन्फ़िगर किया गया BasePath. बेस पाथ में, एपीआई प्रॉक्सी यूआरएल का डोमेन और पोर्ट वाला हिस्सा शामिल नहीं है. उदाहरण के लिए, अगर किसी एपीआई प्रॉक्सी का बेस यूआरएल https://apigeedocs-test.apigee.net/releasenotes/ है, तो बेस पाथ /releasenotes होता है.

वैल्यू को proxy.basepath फ़्लो वैरिएबल में भी सेव किया जाता है.

एपीआई प्रॉक्सी बेस पाथ में जोड़ा गया संसाधन पाथ. उदाहरण के लिए, अगर किसी एपीआई प्रॉक्सी का बेस यूआरएल https://apigeedocs-test.apigee.net/hello/ है और https://apigeedocs-test.apigee.net/hello/json पर कोई कॉल किया जाता है, तो पाथफ़िक्स /json होता है.

अगर किसी भी पाथफ़िक्स का इस्तेमाल नहीं किया जाता है, तो वैल्यू खाली होती है.

वैल्यू को proxy.pathsuffix फ़्लो वैरिएबल में भी सेव किया जाता है.

इसमें मूल क्लाइंट का आईपी पता शामिल होता है. ax_resolved_client_ip डाइमेंशन की वैल्यू का हिसाब लगाने के लिए, ax_true_client_ip और x_forwarded_for_ip डाइमेंशन की वैल्यू का इस्तेमाल किया जाता है.

ध्यान दें कि क्लाइंट के सही आईपी पते को कैप्चर करने के लिए, अकामाई जैसे रूटिंग प्रॉडक्ट का इस्तेमाल करने पर, क्लाइंट आईपी को एचटीटीपी हेडर True-Client-IP में Edge को भेजा जाता है. इसके बाद, इसका इस्तेमाल ax_true_client_ip डाइमेंशन को सेट करने के लिए किया जाता है.

ax_resolved_client_ip डाइमेंशन की वैल्यू का हिसाब इस तरह लगाया जाता है:

1. अगर ax_true_client_ip शून्य नहीं है और उसमें लोकल आईपी पता मौजूद नहीं है, तो ax_resolved_client_ip को ax_true_client_ip पर सेट करें.
2. अगर ऐसा नहीं है, तो ax_resolved_client_ip को x_forwarded_for_ip के पहले गैर-स्थानीय आईपी पते पर सेट करें.
3. अगर ax_true_client_ip और x_forwarded_for_ip, दोनों में सिर्फ़ स्थानीय आईपी पते हैं, तो ax_resolved_client_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 एक लोकल आईपी पता है और x_forwarded_for_ip शून्य है, तो ax_resolved_client_ip को (not set) पर सेट करें.

कॉल करने वाले डिवाइस का ऑपरेटिंग सिस्टम वर्शन.

ऑपरेटिंग सिस्टम के वर्शन देखने के लिए, इसे ओएस फ़ैमिली (ax_ua_os_family) के साथ दूसरे "ड्रिल-डाउन" डाइमेंशन के तौर पर इस्तेमाल किया जा सकता है.

कॉल करने वाले क्लाइंट का आईपी पता, जिसे proxy.client.ip flow वैरिएबल में सेव किया गया है. यह अक्सर इनबाउंड कॉल का X-Forwarded-For पता होता है. यह आईपी पता एज होता है, जो आखिरी बार बाहरी टीसीपी हैंडशेक से मिलता था. यह कॉल करने वाला क्लाइंट या लोड बैलेंसर हो सकता है. जब X-Forwarded-For हेडर में एक से ज़्यादा आईपी होते हैं, तो यह सूची में दिया गया आखिरी आईपी होता है.

क्लाइंट के सही आईपी पते को कैप्चर करने के लिए, अकामाई जैसे रूटिंग प्रॉडक्ट का इस्तेमाल करते समय, क्लाइंट के आईपी, एचटीटीपी हेडर True-Client-IP में Edge को भेजे जाते हैं. यह डाइमेंशन, उस हेडर से उन सही क्लाइंट आईपी को कैप्चर करता है.

ax_resolved_client_ip डाइमेंशन की मदद से ऐक्सेस किए जाने वाले ओरिजनल क्लाइंट आईपी पते का पता लगाने के लिए, Edge ax_true_client_ip और x_forwarded_for_ip डाइमेंशन का इस्तेमाल करता है.

टारगेट सेवा का रिसॉर्स पाथ, जिसमें डोमेन शामिल नहीं है. इसमें क्वेरी पैरामीटर शामिल नहीं हैं.

उदाहरण के लिए, Apigee सैंपल टारगेट http://mocktarget.apigee.net में, कई संसाधन शामिल होते हैं. इनमें /user शामिल है, जो वेलकम मैसेज दिखाता है. आपका एपीआई प्रॉक्सी, http://mocktarget.apigee.net/user को चाहे किसी भी तरह से कॉल करे, request_path /user है.

टारगेट सेवा का रिसॉर्स पाथ, जिसमें डोमेन शामिल नहीं है. इसमें क्वेरी पैरामीटर भी शामिल हैं.

उदाहरण के लिए, Apigee सैंपल टारगेट http://mocktarget.apigee.net में, कई संसाधन शामिल होते हैं. इनमें, दिए गए नाम पर पसंद के मुताबिक वेलकम मैसेज देने के लिए, /user?user={name} रिसॉर्स और क्वेरी पैरामीटर शामिल हैं. आपका एपीआई प्रॉक्सी, http://mocktarget.apigee.net/user?user=Dude को चाहे किसी भी तरह से कॉल कर रहा हो, request_uri /user?user=Dude है.

एपीआई कॉल करने के लिए इस्तेमाल किए गए उपयोगकर्ता एजेंट या सॉफ़्टवेयर एजेंट का नाम. उदाहरण:

• Chrome से कॉल करता हुआ Pixel XL: 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 से कॉल करने वाला iPad: 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> में दी गई है.

उदाहरण के लिए, मान लें कि कोई एपीआई प्रॉक्सी इस टारगेट को कॉल करता है:

<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 शून्य होगा.

ट्रेस टूल में, जब फ़्लो डायग्राम के आखिर में मौजूद AX आइकॉन को चुना जाता है, तो target.basepath फ़्लो वैरिएबल, target_basepath डाइमेंशन पर मैप हो जाता है.

एपीआई प्रॉक्सी को टारगेट सेवा से मिलने वाला एचटीटीपी रिस्पॉन्स स्टेटस कोड, जैसे कि 200, 404, 503 वगैरह.

"शून्य" वैल्यू का मतलब है कि अनुरोध, टारगेट सेवा तक कभी नहीं पहुंचा. ऐसा तब होता है, जब रिस्पॉन्स कैश मेमोरी नीति से रिस्पॉन्स दिया जाता है या अनुरोध को प्रोसेस करने में कोई गड़बड़ी होती है.

यह रिस्पॉन्स स्टेटस कोड (response_status_code) डाइमेंशन से अलग होता है.

एपीआई प्रॉक्सी के TargetEndpoint में बताई गई टारगेट सेवा का पूरा यूआरएल.

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

इस उदाहरण में, target_url http://mocktarget.apigee.net/user?user=Dude है.

ध्यान दें कि एपीआई प्रॉक्सी प्रोसेसिंग के दौरान, यूआरएल को target.url फ़्लो वैरिएबल की मदद से भी बदला जा सकता है.

प्रॉक्सी चेन में और स्क्रिप्ट टारगेट (Node.js) का इस्तेमाल करते समय, कॉलिंग प्रॉक्सी में target_url शून्य होता है.

X-Forwarded-For हेडर में आईपी पतों की सूची.

ax_resolved_client_ip डाइमेंशन की मदद से ऐक्सेस किए जाने वाले ओरिजनल क्लाइंट आईपी पते का पता लगाने के लिए, Edge ax_true_client_ip और x_forwarded_for_ip डाइमेंशन का इस्तेमाल करता है.

24 घंटे की घड़ी के आधार पर, 2-अंकों का घंटा जिसमें एपीआई कॉल किए गए थे. उदाहरण के लिए, रात 10 बजे से 11 बजे के बीच किए गए एपीआई कॉल की संख्या, ax_hour_of_day होगी.

समय की वैल्यू यूटीसी में है.