एक बार मुझे 47 डैशबोर्ड पैनल वाला एक Grafana इंस्टेंस विरासत में मिला। CPU उपयोग, मेमोरी उपयोग, डिस्क I/O, नेटवर्क बाइट्स, JVM हीप — हर वह मीट्रिक जिसकी आप कल्पना कर सकते हैं। सब कुछ हरा था। हर समय।
दो दिन बाद, API 4 घंटे के लिए डाउन हो गया। एक भी अलर्ट नहीं फायर हुआ।
क्यों? क्योंकि CPU 22% पर था, मेमोरी 45% पर, और डिस्क 30% पर। सब "स्वस्थ।" असली समस्या कनेक्शन पूल का खत्म होना था — एक मीट्रिक जिसे कोई नहीं देख रहा था।
चार गोल्डन सिग्नल (और कुछ नहीं)
Google के SRE बुक ने इसे सही किया। आपको ठीक चार सिग्नल चाहिए:
1. लेटेंसी — अनुरोधों में कितना समय लगता है? औसत लेटेंसी नहीं — वह समस्याओं को छिपाती है। P50, P95, और P99 ट्रैक करें:
- P50 = 200ms का मतलब है कि आधे उपयोगकर्ताओं को 200ms में प्रतिक्रिया मिलती है (अच्छा)
- P95 = 800ms का मतलब है कि 20 में से 1 उपयोगकर्ता 800ms प्रतीक्षा करता है (स्वीकार्य)
- P99 = 5000ms का मतलब है कि 100 में से 1 उपयोगकर्ता 5 सेकंड प्रतीक्षा करता है (समस्या)
आपका P99 ही आपका वास्तविक प्रदर्शन है। औसत झूठ बोलता है।
2. ट्रैफ़िक — आप कितने अनुरोध संभाल रहे हैं? यह आपका आधार रेखा है। यदि मंगलवार को दोपहर 2 बजे ट्रैफ़िक 80% गिर जाता है, तो कुछ गड़बड़ है, भले ही अन्य सभी मीट्रिक हरे हों।
3. एरर — कितने प्रतिशत अनुरोध विफल होते हैं? एरर काउंट नहीं, एरर रेट ट्रैक करें। 1 मिलियन अनुरोधों में से 100 एरर (0.01%) ठीक है। 200 अनुरोधों में से 100 एरर (50%) एक आउटेज है।
4. सैचुरेशन — आपका सिस्टम कितना भरा है? डेटाबेस कनेक्शन, मेमोरी, क्यू डेप्थ, थ्रेड पूल। जब कोई संसाधन 80% उपयोग पर पहुंचता है, तो आपको कार्रवाई करने की आवश्यकता है — इसलिए नहीं कि यह टूट गया है, बल्कि इसलिए कि आपने अपना हेडरूम खो दिया है।
मेरा वास्तविक मॉनिटरिंग सेटअप
Nexural प्लेटफ़ॉर्म के लिए:
\\
