Prometheus में मेट्रिक्स, Grafana में डैशबोर्ड, लोकी में लॉग, टेम्पो में वितरित ट्रेस, अलर्टमेनेजर के माध्यम से चेतावनी - सभी प्लेटफार्म के साथ स्व-होस्ट किए गए हैं जो वे देखते हैं. निगरानी एक परियोजना का वह हिस्सा है जो बजट के तनाव के साथ कट जाता है, और यह वह हिस्सा है जिसकी अनुपस्थिति सबसे अधिक लागत होती है.
| माप | मूल्य | स्रोत | मापा |
|---|---|---|---|
| ऑब्जर्वेबिलिटी घटक चल रहा है | 5 (Prometheus, Grafana, Loki, Tempo, Alertmanager) | kubectl get deployments,statefulsets -n monitoring | |
| मेट्रिक संग्रह के अंतर्गत सेवाएँ | 65 deployments in the platform namespace | kubectl get deployments -n kamo |
क्या इमारत यह हमें सिखाया
लगभग हर तंत्र जो हमसे लेना कहा जाता है उसमें एक ही अंतराल होता है. इसके उपयोग के अलावा यह बताने का कोई तरीका नहीं है कि यह काम कर रहा है या नहीं. कोई नहीं जानता कि सामान्य कैसे दिखता है, इसलिए कोई नहीं कह सकता है कि यह कब बंद हो जाता है. समस्या का पहला संकेत ग्राहक की शिकायत है, जिसका अर्थ है कि घड़ी किसी ने देखा इससे पहले ही शुरू हो जाती है.
वितरित ट्रेसिंग सबसे ज्यादा लापता टुकड़ा है और सबसे ज्यादा निर्णायक. चालीस सेवाओं के एक तंत्र में, 'पृष्ठ धीमी है' एक निदान नहीं है - यह टीमों के बीच एक तर्क की शुरुआत है. एक ट्रेस एक मिनट में तर्क को समाप्त करता है, यह दिखाकर कि कौन सा कॉल समय लेता है. हम इसका उपयोग प्रारंभ करने से पहले क्लाइंट सिस्टम के लिए करते हैं, क्योंकि ट्रैसिंग को एक चल रहे तंत्र में रीफिटिंग करना इसे बनाने के कई गुना काम है.
यह भी बदलता है कि एक समर्थन बातचीत कैसी है. जब एक किराएदार रिपोर्ट करता है कि एक विजेट्स एक योजना परिवर्तन के बाद टूट जाता है, हम मेट्रिक्स से बता सकते हैं कि कनेक्शन पूल कारण हैं और यह खुद को साफ करेगा, बजाय सेवाओं को फिर से शुरू करने और इसे बदतर बनाने के. जानना कि क्या करना है एक संचालन कौशल है और यह पूरी तरह से देखने में सक्षम होने पर निर्भर करता है.
के साथ बनाया गया
- Prometheus
- Grafana
- Loki
- Tempo
- Alertmanager
- kube-state-metrics
हमें बताएं कि आप क्या करने की कोशिश कर रहे हैं
एक छोटी बातचीत आमतौर पर यह बताने के लिए पर्याप्त है कि क्या हम सही लोग हैं. यदि हम नहीं हैं, तो हम ऐसा कहेंगे और आपको कहीं बेहतर जगह दिखाएंगे.