Apigee Edge दस्तावेज़ देखा जा रहा है.
Apigee X दस्तावेज़ पर जाएं. जानकारी
Edge API Analytics, पहले से मौजूद एक बेहतरीन सुविधा है, जो Apigee Edge की ओर से दी गई है. यह अलग-अलग एपीआई के डेटा को इकट्ठा करती है और उसका विश्लेषण करती है. आंकड़ों के कैप्चर किए गए डेटा से, काम की अहम जानकारी मिल सकती है. उदाहरण के लिए, किसी समयावधि में एपीआई ट्रैफ़िक की संख्या में किस तरह का बदलाव दिख रहा है? सबसे ज़्यादा इस्तेमाल किया जाने वाला एपीआई कौनसा है? किन एपीआई में गड़बड़ी की दर ज़्यादा है?
इस डेटा और अहम जानकारी का नियमित विश्लेषण करने पर, सही कार्रवाइयां की जा सकती हैं. जैसे, मौजूदा इस्तेमाल, कारोबार, और आने वाले समय में निवेश से जुड़े फ़ैसलों के आधार पर, आने वाले समय में एपीआई की क्षमता प्लान करना वगैरह.
Analytics डेटा और उसका स्टोरेज
API Analytics कई अलग-अलग तरह का डेटा कैप्चर करता है, जैसे:
- एपीआई के बारे में जानकारी - अनुरोध यूआरआई, क्लाइंट का आईपी पता, रिस्पॉन्स के स्टेटस कोड वगैरह
- एपीआई प्रॉक्सी की परफ़ॉर्मेंस - सफलता/असफलता की दर, अनुरोध और जवाब प्रोसेस होने में लगने वाला समय वगैरह
- टारगेट सर्वर परफ़ॉर्मेंस - सफलता/फ़ेल होने की दर, प्रोसेस होने में लगने वाला समय
- गड़बड़ी की जानकारी - गड़बड़ियों की संख्या, गड़बड़ी का कोड, विफल होने की नीति, Apigee की संख्या, और टारगेट सर्वर की वजह से गड़बड़ियां हुईं.
- अन्य जानकारी - डेवलपर, डेवलपर ऐप्लिकेशन वगैरह की ओर से किए गए अनुरोधों की संख्या
यह पूरा डेटा, analytics स्कीमा में सेव किया जाता है. इसे Apigee Edge के Postgres डेटाबेस में बनाया और मैनेज किया जाता है.
आम तौर पर, वैनिला एज इंस्टॉलेशन में Postgres में ये स्कीमाटा मौजूद होगा:
EDGE analytics नाम के स्कीमा का इस्तेमाल करके, हर संगठन और एनवायरमेंट के आंकड़ों का डेटा सेव करता है. अगर कमाई करने की सुविधा इंस्टॉल की गई है, तो rkms स्कीमा होगा. अन्य स्कीमाटा, Postgres इंटरनल के लिए हैं.
analytics स्कीमा बदलता रहेगा, क्योंकि Apigee Edge, रनटाइम के दौरान इसमें डाइनैमिक तौर पर नई तथ्य टेबल जोड़ देगा. Postgres सर्वर कॉम्पोनेंट, तथ्यों के डेटा को एग्रीगेट टेबल में एग्रीगेट करेगा. इस डेटा को Edge यूज़र इंटरफ़ेस (यूआई) पर लोड किया जाता है और दिखाया जाता है.
एंटीपैटर्न
एसक्यूएल क्वेरी का इस्तेमाल करके निजी क्लाउड एनवायरमेंट में, Postgres के डेटाबेस में सीधे तौर पर Apigee के मालिकाना हक वाले schemata में कस्टम कॉलम, टेबल, और/या व्यू जोड़ने की सलाह नहीं दी जाती है, क्योंकि इससे डेटा पर बुरा असर पड़ सकता है.
आइए, इसे विस्तार से समझाने के लिए एक उदाहरण लेते हैं.
मान लें कि account नाम की एक कस्टम टेबल को Analytics स्कीमा के तहत बनाया गया है. इसका उदाहरण नीचे दिया गया है:
कुछ समय बाद, मान लें कि Apigee Edge को पुराने वर्शन से नए वर्शन में अपग्रेड करने की ज़रूरत है. Private Cloud Apigee Edge को अपग्रेड करने के लिए, Postgres को कई अन्य कॉम्पोनेंट के साथ अपग्रेड किया जाता है. अगर Postgres डेटाबेस में कोई कस्टम कॉलम, टेबल या व्यू जोड़ा गया है, तो कस्टम ऑब्जेक्ट के बारे में गड़बड़ियां होने पर Postgres अपग्रेड नहीं हो पाएगा. ऐसा इसलिए है, क्योंकि उन्हें Apigee Edge से नहीं बनाया गया है. इस तरह, Apigee Edge भी अपग्रेड नहीं हो सकता और इसे पूरा नहीं किया जा सकता.
इसी तरह Apigee Edge की रखरखाव से जुड़ी गतिविधियों के दौरान गड़बड़ियां हो सकती हैं, जहां Postgres डेटाबेस के साथ Edge के कॉम्पोनेंट का बैक अप लिया जाता है और उन्हें पहले जैसा किया जाता है.
असर
- Apigee Edge का अपग्रेड पूरा नहीं हो सका, क्योंकि Postgres कॉम्पोनेंट को अपग्रेड नहीं किया जा सका. इसकी वजह यह है कि ऐसे कस्टम ऑब्जेक्ट के बारे में गड़बड़ियां हैं जिन्हें Apigee Edge से नहीं बनाया गया है.
- Apigee Analytics सेवा के रखरखाव (बैकअप/रिस्टोर) की प्रोसेस को पूरा करने में आने वाली गड़बड़ियां (और गड़बड़ियां).
सबसे सही तरीका
- कॉलम, टेबल, व्यू, फ़ंक्शन, और प्रोसेस के रूप में कोई भी कस्टम जानकारी सीधे तौर पर Apigee के मालिकाना हक वाले किसी भी स्कीमा में न जोड़ें, जैसे कि
analyticsवगैरह - अगर कस्टम जानकारी के साथ काम करने की ज़रूरत है, तो इसे
analyticsस्कीमा में स्टैटिस्टिक्स कलेक्टर नीति का इस्तेमाल करके, कॉलम (फ़ील्ड) के तौर पर जोड़ा जा सकता है.