CloudWatch से EFS बर्स्ट क्रेडिट की मॉनिटरिंग कैसे करें

EFS फ़ाइल सिस्टम की अच्छी मॉनिटरिंग के लिए सिर्फ कम बैलेंस वाला एक अलार्म काफी नहीं है। वह चेतावनी दे सकता है कि गुंजाइश खत्म होने वाली है, लेकिन यह नहीं बताता कि बैलेंस क्यों गिर रहा है, कितनी जल्दी खत्म होगा या उपयोगकर्ता पहले से असर महसूस कर रहे हैं या नहीं।

उपयोगी EFS डैशबोर्ड क्षमता, माँग और ऐप पर असर को साथ दिखाता है।

संदर्भ समझाने वाले पाँच मेट्रिक

BurstCreditBalance Bursting Throughput इस्तेमाल करने वाले फ़ाइल सिस्टम में बचा हुआ बर्स्ट-क्रेडिट रिज़र्व दिखाता है।
MeteredIOBytes EFS के थ्रूपुट हिसाब में इस्तेमाल होने वाला मीटर्ड थ्रूपुट दर्शाता है।
PermittedThroughput दिखाता है कि फ़ाइल सिस्टम को अभी कितना थ्रूपुट चलाने की अनुमति है।
TotalIOBytesरीड, राइट और मेटाडेटा मेट्रिक के साथ मिलकर वास्तव में हुआ काम दिखाता है।
PercentIOLimit दिखाता है कि General Purpose परफ़ॉर्मेंस मोड की I/O सीमा कितनी पास है।

अक्सर सबसे उपयोगी दृश्य कोई अकेला ग्राफ नहीं, बल्कि उनके बीच का संबंध होता है। जब मीटर्ड माँग बार-बार अनुमत थ्रूपुट के पास पहुँचे और बर्स्ट क्रेडिट घटते रहें, तो वर्कलोड अस्थायी अतिरिक्त गुंजाइश खर्च कर रहा है।

डैशबोर्ड परतों में बनाएँ

परत 1: कितनी गुंजाइश बची है

ग्राफ बनाएँ BurstCreditBalance कम से कम 30 दिनों की अवधि में देखें। छोटी समय-सीमा में धीरे-धीरे घटता बैलेंस छिप जाता है। हर अवधि का सबसे कम बैलेंस देखने के लिए minimum statistic चुनें और रुझान समझने के लिए लंबी अवधि का दूसरा दृश्य भी रखें।

स्तर 2: मांग बनाम उपलब्ध क्षमता

ग्राफ बनाएँ MeteredIOBytes और PermittedThroughput इनके लिए समय-अवधि और इकाइयां एक जैसी रखें। AWS के अनुसार, जब metered throughput और permitted throughput बराबर होते हैं, तो फ़ाइल सिस्टम उस समय उपलब्ध पूरी throughput क्षमता इस्तेमाल कर रहा होता है।

स्तर 3: वर्कलोड में क्या चल रहा है

डेटा पढ़ने, डेटा लिखने और मेटाडेटा ऑपरेशन को अलग-अलग देखें। छोटे मेटाडेटा ऑपरेशन वाला वर्कलोड लगातार बड़े डेटा ट्रांसफ़र वाले वर्कलोड से अलग व्यवहार कर सकता है, भले ही कुल बाइट लगभग बराबर दिखें।

स्तर 4: सेवा पर असर

एप्लिकेशन अनुरोधों की लेटेंसी, टाइमआउट दर, वर्कर की व्यस्तता और होस्ट का I/O wait भी जोड़ें। इन्फ्रास्ट्रक्चर मेट्रिक्स तभी संचालन में मदद करती हैं जब उन्हें उपयोगकर्ता को दिखने वाले असर से जोड़ा जा सके।

अलार्म सिर्फ शून्य पर नहीं, रुझान पर भी लगाएं

कम बैलेंस पर लगने वाला तय अलार्म उपयोगी है, लेकिन वह आखिरी सुरक्षा होनी चाहिए। पहले चेतावनी पाने के लिए कई स्तर और लगातार घटते बैलेंस का संकेत इस्तेमाल किया जा सकता है। उदाहरण के लिए:

बैलेंस आपके सिस्टम के लिए तय बची हुई क्षमता की सीमा से नीचे जाए तो चेतावनी दें।
कई जांच अवधियों तक बैलेंस लगातार घटता रहे तो चेतावनी का स्तर बढ़ाएं।
Metered throughput लगातार permitted throughput के करीब रहे तो अलर्ट दें।
बढ़ती लेटेंसी या टाइमआउट से तुलना करें, ताकि क्षमता के जोखिम और चल रही घटना में फर्क किया जा सके।

क्रेडिट की कोई एक सीमा हर सिस्टम पर लागू नहीं होती, क्योंकि उसका मतलब खपत की दर पर निर्भर करता है। भारी वर्कलोड में बड़ा बैलेंस भी कुछ घंटों का हो सकता है, जबकि कम इस्तेमाल वाले सिस्टम में छोटा बैलेंस स्थिर रह सकता है।

अलार्म को कार्रवाई के फैसले से जोड़ें

रनबुक में अगले सवाल साफ होने चाहिए: क्या मांग थोड़े समय के लिए बढ़ी है? क्या Standard storage में रखा डेटा कम हुआ है? क्या किसी डिप्लॉयमेंट से असामान्य मेटाडेटा ट्रैफ़िक बन रहा है? क्या अनिश्चित वर्कलोड के लिए Elastic Throughput बेहतर होगा? क्या स्थिर, ज्ञात जरूरत के लिए Provisioned Throughput उचित है?

इन फैसलों का संदर्भ न हो तो अलार्म बस अनिश्चितता को डैशबोर्ड से ऑन-कॉल इंजीनियर तक पहुंचा देता है। अच्छी ऑब्ज़र्वेबिलिटी पेजर बजने से पहले क्षमता का मॉडल समझने में मदद करती है।