वापरकर्त्यांना जाणवणाऱ्या गोष्टींपासून वरून खाली, अवसंरचना पासून खाली वरून नाही असे सुरू करा. सर्वात विश्वसनीय होस्ट फ्लीट व्यर्थ आहे जर विनंत्या अयोग्य होत असतील, म्हणून वापरकर्ता-सामोरे सह सुरू करा — , , — नंतर चार सोन्यांचे सिग्नल जोडा, नंतर अवसंरचना मेट्रिक्स शेवटी.
1. USER-FACING SLIs → what the user experiences (latency, errors, availability)
2. GOLDEN SIGNALS → latency, traffic, errors, saturation per service
3. INFRA METRICS → CPU, memory, disk, network (causes, not symptoms)
जर तुम्ही फक्त CPU आणि डिस्क (वरून खाली) पाहत असाल तर तुम्ही पूर्णपणे हरित असू शकता जेथे वापरकर्ते 500 मिळवत आहेत. पहिल्या SLI (वरून खाली) पाहणे म्हणजे तुम्ही वापरकर्त्यांना वास्तविकपणे जाणवणाऱ्या लक्षणांवर सतर्क करता, नंतर कारण शोधण्यासाठी सोन्यांचे सिग्नल आणि अवसंरचनामध्ये खोदा.
INSTRUMENT app emits metrics/logs/traces (e.g. request_duration_seconds histogram)
↓
COLLECT a TSDB scrapes/ingests them (Prometheus, Datadog agent)
↓
DASHBOARD visualize SLIs + golden signals (Grafana) for humans to read
↓
ALERT fire on SLO violations / burn rate, routed to on-call
# Availability SLI: fraction of requests that succeed
sum(rate(http_requests_total{status!~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
# Latency SLI: p99 request latency
histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))
प्रत्येक SLI वर SLO व्याख्या करा (उदा. 99.9% उपलब्धता, p99 < 300ms), त्यांचे डॅशबोर्ड करा, आणि जेव्हा SLO जोखीमीमध्ये असेल तेव्हा सतर्क करा — प्रत्येक हिचकीवर नाही.
वरून खाली बांधलेली निरीक्षण तुम्हाला सांगते की डिस्क 80% भरलेली आहे परंतु ग्राहकांना चेकआउट करू शकत नाहीत असे नाही. वापरकर्ता-सामोरे SLI पासून सुरू केल्याने प्रत्येक डॅशबोर्ड आणि सतर्क वास्तविक वापरकर्ता प्रभावाशी बांधलेले आहेत, शोर कमी ठेवतात, आणि कधी काहीतरी तुटते तेव्हा स्पष्ट ड्रिल-डाउन मार्ग (लक्षण → सोन्यांचे सिग्नल → अवसंरचना कारण) प्रदान करतात.