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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

हालांकि, अगर नीति में मौजूद <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 को जवाब मिलता है.

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

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

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

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

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

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

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

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

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

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

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

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

यह उस कैश मेमोरी का नाम है जिसमें Response Cache नीति के लिए इस्तेमाल की गई कुंजियां/वैल्यू शामिल होती हैं. इसके नाम में orgName__envName__ प्रीफ़िक्स होता है. उदाहरण के लिए, अगर संगठन "foo" है, एनवायरमेंट "test" है, और कैश मेमोरी का नाम "myCache" है, तो ax_cache_name foo__test__myCache होगा.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

एपीआई प्रॉक्सी में मौजूद, नाम वाले फ़्लो में गड़बड़ी हुई है. उदाहरण के लिए, "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 पर सेट किया जाता है, तो एपीआई प्रॉक्सी फ़्लो बिना किसी गड़बड़ी के जारी रहता है. साथ ही, इस डाइमेंशन में नीति के उल्लंघन को नहीं गिना जाता.

एपीआई प्रॉक्सी के ProxyEndpoint पर कॉन्फ़िगर किया गया 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 डाइमेंशन की वैल्यू के आधार पर लगाया जाता है.

ध्यान दें कि क्लाइंट के असली आईपी पतों को कैप्चर करने के लिए, Akamai जैसे राउटिंग प्रॉडक्ट का इस्तेमाल करते समय, क्लाइंट के आईपी पते को HTTP हेडर 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 फ़्लो वैरिएबल में सेव होता है. यह अक्सर इनबाउंड कॉल का X-Forwarded-For पता होता है. यह वह आईपी पता होता है जो Edge को आखिरी बाहरी टीसीपी हैंडशेक से मिला था. यह कॉलिंग क्लाइंट या लोड बैलेंसर हो सकता है. अगर X-Forwarded-For हेडर में एक से ज़्यादा आईपी पते हैं, तो यह आखिरी आईपी पता होता है.

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

क्लाइंट के ओरिजनल आईपी पते का पता लगाने के लिए, Edge ax_true_client_ip और x_forwarded_for_ip डाइमेंशन का इस्तेमाल करता है. इस पते को ax_resolved_client_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

useragent का वर्शन.

एजेंट फ़ैमिली (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 वगैरह.

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

यह जवाब का स्टेटस कोड (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 हेडर में मौजूद आईपी पतों की सूची.

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

24 घंटे की घड़ी के हिसाब से, एपीआई कॉल किए जाने का दो अंकों वाला घंटा. उदाहरण के लिए, अगर रात 10 बजे से 11 बजे के बीच एपीआई कॉल किए जाते हैं, तो ax_hour_of_day की वैल्यू 22 होगी.

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