हम औसत लेटेंसी की जगह p99 लेटेंसी पर अलर्ट क्यों रखते हैं?

औसत पूंछ को छिपा देता है। कोई सर्विस औसतन 80ms दे सकती है जबकि सौ में से एक रिक्वेस्ट चार सेकंड ले रही हो, और वे धीमी रिक्वेस्ट आम तौर पर आपके सबसे भारी यूजर पर गिरती हैं। percentile असली बंटवारे को बताता है, तो p99 बताता है कि आपके सबसे बुरी तरह सर्व हुए यूजर सच में क्या भुगत रहे हैं। एक चेतावनी: percentiles को अलग अलग होस्ट के बीच औसत नहीं किया जा सकता, इसलिए उन्हें प्रति होस्ट वैल्यू का औसत लेने के बजाय histogram से जोड़ें।

क्योंकि औसत वह अकेला नंबर है जिसकी गारंटी है कि वह किसी का भी हाल नहीं बताता। हमारा एक endpoint औसतन करीब 90ms दे रहा था और शिकायतें लगातार आ रही थीं, और p99 तीन सेकंड से थोड़ा ऊपर था, और वह पूरा का पूरा बड़े अकाउंट वाले ग्राहकों का था जो एक बिना index वाले query रास्ते पर जा रहे थे। औसत कभी हिला ही नहीं क्योंकि वे यूजर ट्रैफिक का 1% थे। fan out का असर भी है। अगर एक पेज तीस बैकएंड कॉल करता है, तो सौ में एक धीमी कॉल का मतलब है कि पेज लोड का एक ठीकठाक हिस्सा धीमा है, यानी सर्विस स्तर की tail latency यूजर के स्तर पर आम लेटेंसी बन जाती है। जिस चीज पर मैं ध्यान दिलाऊंगा वह है जोड़ने का तरीका। आप इंस्टेंस के p99 का औसत लेकर असली p99 नहीं पा सकते। हम Prometheus histograms एक्सपोर्ट करते थे और histogram_quantile से पूरे सेट पर quantile निकालते थे, जिससे बिना कुछ दोबारा गिने endpoint और कस्टमर टियर के हिसाब से काटना भी हो जाता था।