निरीक्षणीयता तीन स्तंभ — लॉग्स, मेट्रिक्स आणि ट्रेसेस — वर आधारित आहे आणि लक्ष्य म्हणजे "काय चुकीचे आहे आणि का" या प्रश्नाचे उत्तर देणे अशा प्रणालीसाठी जी हाताने तपासण्यासाठी खूप मोठी आहे. मोठ्या प्रमाणावर, धोरण संबंध, नमुनाकरण आणि खर्चाबद्दल आहे.
निरीक्षणीयता तीन स्तंभ — लॉग्स, मेट्रिक्स आणि ट्रेसेस — वर आधारित आहे आणि लक्ष्य म्हणजे "काय चुकीचे आहे आणि का" या प्रश्नाचे उत्तर देणे अशा प्रणालीसाठी जी हाताने तपासण्यासाठी खूप मोठी आहे. मोठ्या प्रमाणावर, धोरण संबंध, नमुनाकरण आणि खर्चाबद्दल आहे.
| स्तंभ | उत्तरे | साधने |
|---|
| मेट्रिक्स | काहीतरी चुकीचे आहे का? (दर, विलंबता) | Prometheus, Grafana |
| ट्रेसेस | प्रवाहात कुठे? | OpenTelemetry, Jaeger |
| लॉग्स | नक्की काय घडले? | ELK, Loki |
Metrics alert ─▶ trace pinpoints the slow service ─▶ logs explain the cause
(broad) (path) (detail)
ट्रेस/सहसंबंध ID ने मेट्रिक्स लेबल्स, लॉग लाइन्स आणि स्पॅन्समधून जाणे आवश्यक आहे, जेणेकरून आपण त्यांच्या दरम्यान पिव्होट करू शकता.
log line: level=error trace_id=abc123 service=payments msg="gateway timeout"
^^^^^^^^^^^^^^^ same id appears in the trace + metrics
✓ Standardize: OpenTelemetry across all services
✓ Use structured (JSON) logs — queryable, not grep-only
✓ Sample traces (e.g. keep all errors + 1% of success) to control cost
✓ Define SLOs and alert on symptoms (latency/error rate), not noise
✓ RED/USE method for dashboards (Rate, Errors, Duration)
100% वर सर्वकाही लॉग करणे वहनीय नाही आणि सिग्नलला बुडवते. त्याऐवजी नमुना, संरचना आणि SLOs वर सावधानी घ्या.
शेकडो सेवांसह, आपण SSH मध्ये जाऊ शकत नाही आणि पाहू शकत नाही — निरीक्षणीयता हा उत्पादन व्यवहार समजण्याचा एकमात्र मार्ग आहे.
जिंकणारी धोरण सहसंबंधित, नमुना आणि SLO-चालित आहे: ते टेलीमेट्री स्टोरेजवर आपल्याला दिवाळखोर न करता किंवा on-call ला गोंधळात बुडवून हलक्या समस्या जलद दिसून येतात.