, तल भन्दा माथिबाट होइन। सबैभन्दा भरपर्दो होस्ट फ्लीट व्यर्थ छ यदि अनुरोध असफल भइरहेका छन्, त्यसैले प्रयोगकर्ता-मुखी सँग शुरु गरिहाल्नुहोस् — , , — त्यसपछी चार golden signals जोडिहाल्नुहोस्, त्यसपछी infra मेट्रिक्स अन्तिममा।
, तल भन्दा माथिबाट होइन। सबैभन्दा भरपर्दो होस्ट फ्लीट व्यर्थ छ यदि अनुरोध असफल भइरहेका छन्, त्यसैले प्रयोगकर्ता-मुखी सँग शुरु गरिहाल्नुहोस् — , , — त्यसपछी चार golden signals जोडिहाल्नुहोस्, त्यसपछी infra मेट्रिक्स अन्तिममा।
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 र disk हेरिहाल्नुहुन्छ (तल भन्दा माथिबाट), तपाई पूर्ण रूपमा हरियो हुन सक्नुहुन्छ जबकि प्रयोगकर्ताहरूले 500s पाइरहेका छन्। पहिले SLI हेरिहाल्नु (माथिबाट तल) अर्थ प्रयोगकर्ताहरूले वास्तवमा महसुस गरेको लक्षणहरूमा सतर्क गरिहाल्नु, त्यसपछी कारण खोज्न golden signals र infra मा ड्रिल गरिहाल्नु।
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% availability, p99 < 300ms), तिनलाई dashboard गरिहाल्नुहोस्, र SLO जोखिममा पडेको बेला सतर्क गरिहाल्नुहोस् — हरेक उचल गर्दा होइन।
तलबाट माथिबाट निर्माण गरिएको निगरानी भन्दा तपाईलाई बताउँछ कि disk 80% भरिएको छ तर यो कि ग्राहकहरू खरीद पूरा गर्न सक्दैनन्। प्रयोगकर्ता-मुखी SLI बाट सुरु गर्नु प्रत्येक dashboard र सतर्कलाई वास्तविक प्रयोगकर्ता प्रभाव फिर्ता गर्दछ, शोर कम राख्दछ, र स्पष्ट ड्रिल-डाउन पथ (लक्षण → golden signal → infra कारण) दिन्छ कहिले केही भाँचिन्छ।