यी अवलोकनशीलताका तीन स्तम्भ हुन्। तिनले विभिन्न प्रश्नहरूको जवाब दिन्छन्: मेट्रिक्सले तपाईलाई बताउँछ कि के गलत छ, लग्सले तपाईलाई बताउँछ कि के भयो, र ट्रेसेसले तपाईलाई बताउँछ कि वितरित प्रवाहमा समय वा त्रुटि गएको हो।
यी अवलोकनशीलताका तीन स्तम्भ हुन्। तिनले विभिन्न प्रश्नहरूको जवाब दिन्छन्: मेट्रिक्सले तपाईलाई बताउँछ कि के गलत छ, लग्सले तपाईलाई बताउँछ कि के भयो, र ट्रेसेसले तपाईलाई बताउँछ कि वितरित प्रवाहमा समय वा त्रुटि गएको हो।
METRICS aggregate numbers over time (counters, gauges, histograms)
→ cheap, low cardinality, great for trends & ALERTING
→ e.g. error rate = 2%, p99 latency = 800ms
LOGS discrete, timestamped events with detail (often structured JSON)
→ rich context for DEBUGGING a specific request
→ e.g. {"level":"error","user":123,"msg":"payment declined"}
TRACES the path of one request across services, with timing per span
→ shows latency BREAKDOWN and where a call fails
→ e.g. checkout 800ms = api 50ms + db 700ms + email 50ms
1. METRIC alerts: "checkout p99 latency jumped to 2s" → you know THERE's a problem
2. TRACE a slow request: 1.8s of 2s is spent in the inventory service
→ you know WHERE it is
3. LOGS of the inventory service at that time: "slow query: missing index"
→ you know WHAT happened
मेट्रिक्सले तपाईलाई एक लक्षण र समय खिडकीमा सीमित गर्छ; ट्रेसेसले यसलाई सेवा वा कलमा स्थानीय गर्छ; लग्सले सटीक कारण दिन्छ। मेट्रिक्स बिना सीधै लग्समा जानु भर्खार खोज गर्नु जस्तो हो।
मेट्रिक्सहरू एकीकृत हुन्छन्, त्यसैले तिनी स्केलमा पनि सस्तो रहन्छन् — सधैं-सक्रिय ड्यासबोर्डहरू र अलर्टहरूको लागि आदर्श। लग्स र ट्रेसेसहरू प्रति-घटना हुन्छन् र महँगा हुन्छन्, त्यसैले तिनहरू सामान्यतः नमुना गरिएका हुन्छन् र अनुसन्धानको समयमा माग गरी क्वेरी गरिन्छन्।
गलत स्तम्भ प्रयोग गर्नु समय बर्बाद गर्छ: तपाई कच्चा लग्सलाई प्रभावकारीरूपमा अलर्ट गर्न सक्नुहुन्न (धेरै शोरगुल, धेरै महँगो), र तपाई एकल लग्सका मेट्रिकबाट विफल अनुरोध डिबग गर्न सक्नुहुन्न। मेट्रिक्सले पत्ता लगाउँछ, ट्रेसेसले स्थानीय गर्छ, र लग्सले व्याख्या दिन्छ भन्ने कुरा जानु "केही गलत छ" देखि मूल कारणमा पुग्न एक द्रुत, पुनरावृत्तिक मार्ग दिन्छ।