logs, metrics और traces में क्या फर्क है, और आप हर एक को कब उठाते हैं?

metrics समय के साथ जोड़े गए आंकड़े हैं, स्टोर करने में सस्ते, और alert इन्हीं पर लगते हैं। logs अलग अलग घटनाएं हैं जिनमें ब्यौरा होता है, वे तब पढ़े जाते हैं जब आपको मोटा मोटी पता हो कि कहां देखना है। traces एक request का कई सर्विसेज तक पीछा करते हैं और बताते हैं कि वक्त कहां गया। किसी incident में आम तौर पर आप पता लगाने के लिए metrics, जगह ढूंढने के लिए traces और समझने के लिए logs इस्तेमाल करते हैं, तो जिस सिस्टम में तीन में से कोई एक नहीं है वहां डिबग करना जरूरत से ज्यादा धीमा हो जाता है।

metrics समय के साथ जोड़े गए counters और histograms हैं। वे सस्ते हैं, alert मैं उन्हीं पर लगाता हूं, और वे बताते हैं कि कुछ गलत है लेकिन कभी नहीं बताते कि क्यों। logs संदर्भ के साथ अलग अलग घटनाएं हैं, ज्यादा मात्रा में महंगे, और उन्हें मैं तब पढ़ता हूं जब पता हो कि कहां देखना है। traces एक request को हर उस सर्विस के आर पार सिल देते हैं जिसे उसने छुआ और हर span का वक्त दिखाते हैं, जो यह जानने का सबसे तेज तरीका है कि दिक्कत हमारी है या किसी dependency की। incident में तरीका मोटे तौर पर यही है: पता लगाने के लिए metrics, जगह ढूंढने के लिए traces, समझने के लिए logs। इन्हें साथ काम करने लायक जो चीज बनाती है वह है हर कॉल में आगे बढ़ने वाली और हर structured log line में शामिल correlation id, जिससे किसी धीमे trace से मैं सीधे ठीक उन्हीं log entries पर कूद सकता हूं। जो गलती मैंने की है वह cardinality की है: मैंने एक बार user id को metric label बना दिया और time series की गिनती फट पड़ी, जो जल्दी ही महंगी पड़ गई। ज्यादा cardinality traces और logs में रहनी चाहिए, metric labels में नहीं।