आप किसी मेट्रिक या लॉग की जगह distributed trace की तरफ कब जाएंगे?

मेट्रिक्स बताते हैं कि कुछ गड़बड़ है और मोटे तौर पर कहां। लॉग बताते हैं कि एक प्रोसेस के अंदर क्या हुआ। Traces बताते हैं कि एक रिक्वेस्ट का समय कई सर्विस के बीच कहां गया। trace की तरफ तब जाएं जब लेटेंसी ज्यादा हो पर कोई भी एक सर्विस बीमार न दिख रही हो, या जब रिक्वेस्ट कई hops पार करती हो। मेट्रिक्स सस्ते और सामूहिक हैं, लॉग विस्तृत और महंगे हैं, traces sampled और रिश्ते दिखाने वाले हैं।

मैं इसे तीन सवालों की तरह देखता हूं। मेट्रिक्स बताते हैं कि टूटा है या नहीं और कितना बुरी तरह, लॉग बताते हैं कि इस एक प्रोसेस में क्या हुआ, और traces बताते हैं कि पूरी रिक्वेस्ट में समय कहां गया। मैं trace की तरफ उसी पल जाता हूं जब कुल लेटेंसी बढ़ी हो पर हर सर्विस का डैशबोर्ड ठीक दिख रहा हो, जिसका लगभग हमेशा मतलब होता है कि समय किसी ऐसे hop में जा रहा है जिसका मालिक कोई नहीं। हमारे साथ यही हुआ था एक service mesh sidecar के साथ, जो ऐसे retries जोड़ रहा था जिनका हमें पता ही नहीं था; trace ने इसे करीब एक मिनट में साफ कर दिया क्योंकि हमें एक ही कॉल के नीचे तीन एक जैसे spans दिख गए। असली जोड़ यह है कि हर लॉग लाइन में trace और span id डालें, ताकि आप किसी सामूहिक मेट्रिक से एक धीमे exemplar trace तक और वहां से उसी रिक्वेस्ट की ठीक लॉग लाइनों तक कूद सकें। और मैं traces को कम दर पर head based sample करूंगा, साथ में एरर और धीमी रिक्वेस्ट के लिए tail based sampling, क्योंकि सब कुछ रखना बिल के लायक नहीं है।