समस्या की पृष्ठभूमि: Critical और Warning alert channels को अलग किया गया और Critical alerts पर फ़ोन कॉल रिसीव करने की व्यवस्था भी शुरू की गई, लेकिन हर महीने 10,000 से अधिक Warning alerts की बाढ़ आ जाने से alerts को नज़रअंदाज़ करने और on-call fatigue बढ़ने की समस्या पैदा हुई.
मुख्य insight: अत्यधिक alerts मैसेंजर को health checker में बदल देते हैं और system visibility को बाधित करते हैं. alerts कम करने के लिए Slack emoji (👀, ✅) का उपयोग करते हुए 'alert response rate' को एक मुख्य metric के रूप में मापने का प्रस्ताव रखा गया.
समाधान प्रक्रिया:
वे alerts जिनकी शुरुआती configuration intent अब मौजूदा environment से मेल नहीं खाती थी, उन्हें समायोजित या हटाया गया. उदाहरण: EBS volume expansion threshold का mismatch.
ऐसे बेअर्थ alerts, जिनमें पहले काम करने वाले की मंशा समझ में नहीं आती थी, उन्हें भी साहसपूर्वक हटा दिया गया.
अतिरिक्त उपलब्धि: alert noise हटाने के बाद यह पता चला कि एक विशेष server में high iowait का कारण वास्तविक workload की तुलना में जरूरत से ज़्यादा सेट किया गया ZFS recordsize था, जिसे बाद में सामान्य किया गया.
परिणाम: Warning alerts में 95.7% की कमी (मासिक 10,553 → 453). देर रात/छुट्टियों में आने वाली Critical phone calls में 70% से अधिक की कमी. on-call के दौरान नींद की कमी की समस्या सुलझी और system availability व visibility में वास्तविक सुधार हुआ.
3 टिप्पणियां
लॉग, मेट्रिक्स और अलार्म के लिए समय-समय पर उन्हें ट्यून करने की प्रैक्टिस ज़रूरी होती है।
मुझे लगा यह यूज़रनेम कहीं देखा हुआ है, तो याद आया कि ये वही व्यक्ति हैं जिन्होंने पहले cron output पर एक मज़ेदार लेख लिखा था। इस बार का लेख भी बहुत अच्छा लगा :D
यह जानकर खुशी हुई कि आपको यह दिलचस्प लगा।