डेटाबेस की मेट्रिक मॉनिटर करना

इस पेज पर, अपने डेटाबेस को मॉनिटर करने के लिए, Cloud Firestore के लिए Cloud Monitoring मेट्रिक इस्तेमाल करने का तरीका बताया गया है.

Cloud Firestore के लिए Cloud Monitoring मेट्रिक

यहां दिए गए सेक्शन में, Cloud Firestore के लिए उपलब्ध मेट्रिक की खास जानकारी दी गई है.

मॉनिटर किए गए संसाधन

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

Cloud Monitoring एपीआई का इस्तेमाल करके, Cloud Firestore की परफ़ॉर्मेंस को इस रिसॉर्स की मदद से मॉनिटर किया जाता है:

मेट्रिक

Cloud Firestore की मेट्रिक की पूरी सूची के लिए, Cloud Firestore मेट्रिक देखें. यहां दिए गए सेक्शन में, उपलब्ध कुछ मेट्रिक के बारे में बताया गया है.

सेवा के रनटाइम की मेट्रिक

serviceruntime मेट्रिक से, किसी प्रोजेक्ट के ट्रैफ़िक की खास जानकारी मिलती है. ये मेट्रिक, ज़्यादातर Google Cloud एपीआई के लिए उपलब्ध हैं. consumed_api मॉनिटर किए गए संसाधन के टाइप में, ये सामान्य मेट्रिक शामिल होती हैं. इन मेट्रिक का सैंपल हर 30 मिनट में लिया जाता है. इससे डेटा को बेहतर तरीके से दिखाया जाता है.

serviceruntime मेट्रिक के लिए, संसाधन का एक अहम लेबल method है. यह लेबल, कॉल किए गए आरपीसी के तरीके को दिखाता है. यह ज़रूरी नहीं है कि आपने जिस SDK टूल के फ़ंक्शन को कॉल किया है उसका नाम, आरपीसी के फ़ंक्शन के नाम से मेल खाता हो. इसकी वजह यह है कि एसडीके, हाई-लेवल एपीआई ऐब्स्ट्रैक्शन उपलब्ध कराता है. हालांकि, यह समझने के लिए कि आपका ऐप्लिकेशन Cloud Firestore के साथ कैसे इंटरैक्ट करता है, आरपीसी तरीके के नाम के आधार पर मेट्रिक को समझना ज़रूरी है.

अगर आपको यह जानना है कि एसडीके के किसी तरीके के लिए, आरपीसी का कौन सा तरीका इस्तेमाल किया जाता है, तो एपीआई से जुड़ा दस्तावेज़ देखें.

api/request_latencies

api/request_latencies मेट्रिक, पूरे हो चुके सभी अनुरोधों के लिए इंतज़ार के समय का डिस्ट्रिब्यूशन दिखाती है.

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

दस्तावेज़ से जुड़ी कार्रवाइयों की मेट्रिक

Cloud Firestore, डेटा को पढ़ने, लिखने, और मिटाने की संख्या दिखाता है. राइट मेट्रिक, 'CREATE' और 'UPDATE' ऑपरेशन के बीच का ब्रेकडाउन उपलब्ध कराती है. ये मेट्रिक, CRUD ऑपरेशन के हिसाब से अलाइन की जाती हैं.

यहां दी गई मेट्रिक का इस्तेमाल करके, यह समझा जा सकता है कि आपके डेटाबेस में डेटा को पढ़ने की प्रोसेस ज़्यादा होती है या डेटा को लिखने की प्रोसेस. साथ ही, नए दस्तावेज़ों और मिटाए गए दस्तावेज़ों की दर का भी पता लगाया जा सकता है.

• document/delete_ops_count: मिटाए गए दस्तावेज़ों की संख्या.
• document/read_ops_count: क्वेरी या लुकअप से, दस्तावेज़ को सही तरीके से पढ़ने की संख्या.
• document/write_ops_count: दस्तावेज़ में डेटा सेव करने की सफल कार्रवाइयों की संख्या.

बिलिंग मेट्रिक

बिलिंग के इस्तेमाल को समझने के लिए, इन मेट्रिक का इस्तेमाल करें. इन मेट्रिक में, एडमिन के ऑपरेशन (इंडेक्स करना, इंपोर्ट करना, एक्सपोर्ट करना, और एक साथ कई आइटम मिटाना) से होने वाली बिलिंग शामिल नहीं होती.

• api/billable_read_units: बिल की जा सकने वाली रीड यूनिट की संख्या. इस्तेमाल को सेवा के नाम और एपीआई के तरीके के हिसाब से बांटा जा सकता है.
• api/billable_realtime_read_units: रीयल-टाइम अपडेट से, रीयल-टाइम अपडेट की उन यूनिट की संख्या जिनके लिए बिल भेजा जा सकता है. यह सिर्फ़ नेटिव मोड में Cloud Firestore पर लागू होता है.
• api/billable_write_units: बिल की जा सकने वाली राइट यूनिट की संख्या. इस्तेमाल को सेवा के नाम और एपीआई के तरीके के हिसाब से बांटा जा सकता है.
• document/billable_managed_delete_write_units: टीटीएल जैसी मैनेज की गई मिटाने की सेवाओं से, बिल की जा सकने वाली राइट यूनिट की संख्या.

इंडेक्स मेट्रिक

इंडेक्स फ़ैनआउट को समझने के लिए, इंडेक्स राइट रेट की तुलना document/write_ops_count मेट्रिक से की जा सकती है.

• index/write_count: इंडेक्स में लिखे गए डेटा की संख्या.

TTL मेट्रिक

Cloud Firestore मेट्रिक के लिए टीटीएल मेट्रिक का इस्तेमाल, लागू की गई टीटीएल नीति के असर को मॉनिटर करने के लिए किया जाता है.

• document/ttl_deletion_count: टीटीएल सेवाओं से मिटाए गए दस्तावेज़ों की कुल संख्या.
• document/ttl_expiration_to_deletion_delays: टीटीएल की समयसीमा खत्म होने वाले दस्तावेज़ और उसे असल में मिटाए जाने के बीच का समय.

पहले से तय डैशबोर्ड देखना और कस्टम डैशबोर्ड बनाना

Cloud Firestore में पहले से तय किए गए डैशबोर्ड इस्तेमाल किए जा सकते हैं. इनमें Cloud Monitoring मेट्रिक का इस्तेमाल किया जाता है. आपके पास कस्टम डैशबोर्ड बनाने का विकल्प भी है.

डेटाबेस के इस्तेमाल की मेट्रिक देखना

Google Cloud console में इस्तेमाल से जुड़े डैशबोर्ड खोलें. इससे आपको समय के साथ दस्तावेज़ों को पढ़ने, लिखने, और मिटाने की जानकारी दिखेगी.

ऐक्सेस कंट्रोल

इस्तेमाल के डैशबोर्ड के लिए, monitoring.timeSeries.list पहचान और ऐक्सेस मैनेजमेंट (आईएएम) की अनुमति ज़रूरी है. प्रोजेक्ट के मालिक, एडिटर, और व्यूअर की भूमिकाओं वाले उपयोगकर्ताओं को यह अनुमति मिलती है. यह अनुमति, Cloud Monitoring भूमिका या कस्टम भूमिका के ज़रिए भी दी जा सकती है.

डेटाबेस के इस्तेमाल का डैशबोर्ड

Cloud Firestore डेटाबेस के इस्तेमाल से जुड़ी मेट्रिक देखने के लिए, यह तरीका अपनाएं.

1. Google Cloud console में, डेटाबेस पेज पर जाएं.

   डेटाबेस पर जाएं

2. डेटाबेस की सूची से वह डेटाबेस चुनें जिसकी आपको ज़रूरत है.

3. नेविगेशन मेन्यू में, इस्तेमाल पर क्लिक करें.

इस्तेमाल का डैशबोर्ड और बिलिंग रिपोर्ट

Console में मौजूद Cloud Firestore के इस्तेमाल से जुड़े डैशबोर्ड से, इस्तेमाल का अनुमान मिलता है. इनकी मदद से, इस्तेमाल में होने वाली बढ़ोतरी का पता लगाया जा सकता है. हालांकि, डैशबोर्ड पर बिल किए गए ऑपरेशन की सटीक जानकारी नहीं दिखती. बिल किया गया इस्तेमाल ज़्यादा हो सकता है. बिलिंग पर नज़र रखने के लिए, बिलिंग मेट्रिक देखें.

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

इंपोर्ट और एक्सपोर्ट की कार्रवाइयों की वजह से, इस्तेमाल के डैशबोर्ड और बिल किए गए इस्तेमाल के बीच अंतर होता है. इन कार्रवाइयों से किए गए रीड और राइट, इस्तेमाल के डैशबोर्ड में नहीं दिखते.

डेटाबेस की परफ़ॉर्मेंस मेट्रिक देखना

Google Cloud Console के Cloud Firestore सेक्शन में मौजूद मॉनिटरिंग पेज पर, पहले से तय किए गए मॉनिटरिंग डैशबोर्ड शामिल होते हैं. जैसे, अनुरोध में लगने वाला समय (P50 और P99), रिस्पॉन्स कोड, और क्वेरी के आंकड़े (P50). आपके पास एक कस्टम डैशबोर्ड बनाने का विकल्प भी है. किसी डेटाबेस के लिए मॉनिटरिंग पेज को ऐक्सेस करने के लिए, यह तरीका अपनाएं:

1. Google Cloud console में, Cloud Firestore डेटाबेस पेज खोलें.

   डेटाबेस पर जाएं

2. सूची में से कोई डेटाबेस चुनें.

3. डैशबोर्ड खोलने के लिए, नेविगेशन मेन्यू में जाकर Monitoring पर क्लिक करें.

कस्टम Cloud Monitoring डैशबोर्ड बनाना

Cloud Monitoring में, कस्टम डैशबोर्ड की मदद से, अपने काम की जानकारी को व्यवस्थित तरीके से दिखाया जा सकता है. उदाहरण के लिए, प्रोडक्शन एनवायरमेंट में अपने प्रोजेक्ट की परफ़ॉर्मेंस मेट्रिक और सूचना देने वाली नीतियों को दिखाने के लिए, डैशबोर्ड बनाया जा सकता है.

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

सूचना देने वाली नीति बनाना

Cloud Monitoring में, सूचनाएं बनाई जा सकती हैं. इससे आपको मेट्रिक की स्थिति में बदलाव होने पर सूचना मिलेगी. इन सूचनाओं का इस्तेमाल करके, संभावित समस्याओं के बारे में पहले ही जानकारी पाई जा सकती है. इससे, उपयोगकर्ताओं पर इन समस्याओं का असर पड़ने से पहले ही इन्हें ठीक किया जा सकता है.

सूचनाएं बनाने के बारे में ज़्यादा जानने के लिए, मेट्रिक-थ्रेशोल्ड की सूचना देने वाली नीतियां बनाना लेख पढ़ें.

नीचे दिए गए उदाहरण को देखें, जिसमें हमने इंतज़ार के समय के लिए चेतावनी देने वाली नीति बनाई है. सूचना देने की नीति, पांच मिनट की रोलिंग विंडो में p99 लेटेंसी की जांच करती है. अगर p99 लेटेंसी पांच मिनट तक 250 मि॰से॰ से ज़्यादा रहती है, तो सूचना ट्रिगर हो जाती है.

fetch consumed_api
| metric 'serviceruntime.googleapis.com/api/request_latencies'
| filter (resource.service == 'firestore.googleapis.com')
| group_by 5m,
    [value_request_latencies_percentile:
      percentile(value.request_latencies, 99)]
| every 5m
| condition val() > 0.25 's'