कोई ग्राहक बताता है कि ऐप टूटा हुआ है पर आप उसे दोहरा नहीं पा रहे। आप क्या देखते हैं?

ठोस बातों से शुरू करें: कौन सा account, किस समय, कौन सा काम, उन्हें क्या दिखा। फिर उस request को logs, traces और error reports में एक साझा request या trace id से पीछा करें, ताकि आपको एक सर्विस नहीं, पूरा रास्ता दिखे। error rate और latency की तुलना कल की उसी खिड़की से करें ताकि असली गिरावट और आम शोर अलग हो जाएं। कुछ न दिखे तो कमी instrumentation की है, तो उस रास्ते पर structured logging जोड़ें।

पहला काम मैं यह करता हूं कि रिपोर्ट को ढूंढने लायक चीज़ में बदलूं: account id, timezone के साथ मोटा timestamp, कौन सा button, स्क्रीन पर क्या दिखा। गोलमोल रिपोर्टें अनसुलझी रह जाती हैं, तो वह बातचीत पांच मिनट के लायक है। फिर मैं उस खिड़की की किसी request का trace देखकर उसे सर्विसेज़ के आर पार पीछा करता हूं, क्योंकि किसी एक सर्विस की log line शायद ही बताती है कि नाकामी हमारी थी, डेटाबेस की, या तीसरे पक्ष की। इसके साथ मैं error rate और latency को पिछले दिन के उसी समय से तोलता हूं, क्योंकि किसी जाने पहचाने deploy के समय पर शुरू हुआ उछाल आमतौर पर पूरा जवाब होता है। जो चीज़ मैंने जल्दी जांचना सीखा है वह यह कि मामला environmental तो नहीं: एक region, एक ब्राउज़र, कोई बासी service worker जो पुराने assets दे रहा है, या कोई corporate proxy जो कोई header हटा दे रहा है। अगर कहीं कुछ दिखे ही नहीं, तो मैं ढूंढना बंद करके उसी को नतीजा मानता हूं, और उस रास्ते पर request id, user id और फैसलों की शाखाओं के साथ structured logs जोड़ देता हूं ताकि अगली रिपोर्ट मिनटों में निपटे। logs में पहचानकर्ता जाते हैं, tokens या निजी डेटा कभी नहीं।