आपकी अपनी सर्विस के लिए अच्छी ऑब्जर्वेबिलिटी कैसी दिखती है?

आपको उन सवालों के जवाब मिल पाने चाहिए जिनका आपने पहले से अंदाज़ा नहीं लगाया था। यानी हर लाइन पर trace id वाले structured logs, ऐसे metrics जो rate, errors और duration के साथ आपके अहम resources का saturation भी दिखाएं, और distributed traces जो एक request को सर्विसेज़ के आर पार फॉलो करें। alerts उन symptoms पर बजें जो यूज़र को दिखते हैं और जो आपके service level objectives से जुड़े हों, dashboards ग्राहक के अनुभव से शुरू हों, और हर signal के labels एक जैसे हों ताकि आप उनके बीच घूम सकें।

मेरी कसौटी यह है कि क्या मैं ऐसा सवाल हल कर सकता हूं जो सर्विस बनाते वक्त किसी के दिमाग में नहीं था, मसलन एक ही ग्राहक के लिए एक ही endpoint पर requests धीमी क्यों हैं। इसके लिए तीनों signals का जुड़ा होना ज़रूरी है। हर log line structured होती है और उसमें trace id होता है, तो किसी धीमे trace से मैं सीधे उसी request के logs पर कूद सकता हूं, timestamp से grep करने की जगह। metrics हर endpoint के rate, errors और duration को औसत की जगह percentiles में दिखाते हैं, साथ ही उन चीज़ों का saturation जो सच में खत्म होती हैं: connection pools, queue depth, disk। traces sampled होते हैं, लेकिन errors और धीमी tail मैं हमेशा रखता हूं, क्योंकि औसत request मुझे कुछ नहीं सिखाती। alerts वह हिस्सा है जहां लोग गलती करते हैं: मैं उन symptoms पर alert करता हूं जो ग्राहक महसूस करते हैं और जो objective से जुड़े हैं, इस पर नहीं कि CPU अस्सी प्रतिशत है। और मैं लागत पर नज़र रखता हूं, क्योंकि metric label में user id डालना ही वह तरीका है जिससे दो सौ डॉलर का बिल रातोंरात छह हज़ार हो जाता है; यूज़र स्तर का ब्यौरा traces और logs में रहना चाहिए।