ਉਪਭੋਗਤਾਵਾਂ ਜੋ ਮਹਸੂਸ ਕਰਦੇ ਹਨ ਉੱਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਹੇਠੋਂ-ਉੱਪਰ ਨਹੀਂ। ਸਭ ਤੋਂ ਭਰੋਸੇਮੰਦ ਹੋਸਟ ਫਲੀਟ ਬੇਕਾਰ ਹੈ ਜੇ ਬੇਨਤੀਆਂ ਫੇਲ ਹੋ ਰਹੀਆਂ ਹਨ, ਇਸ ਲਈ ਉਪਭੋਗਤਾ-ਫੁੱਲ — , , — ਦੁਆਰਾ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਚਾਰ ਸੁਨਹਰੀ ਸਿਗਨਲ ਜੋੜੋ, ਫਿਰ ਅਵਸਰ ਮੈਟਰਿਕਸ ਆਖਰ ਵਿੱਚ।
ਉਪਭੋਗਤਾਵਾਂ ਜੋ ਮਹਸੂਸ ਕਰਦੇ ਹਨ ਉੱਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਹੇਠੋਂ-ਉੱਪਰ ਨਹੀਂ। ਸਭ ਤੋਂ ਭਰੋਸੇਮੰਦ ਹੋਸਟ ਫਲੀਟ ਬੇਕਾਰ ਹੈ ਜੇ ਬੇਨਤੀਆਂ ਫੇਲ ਹੋ ਰਹੀਆਂ ਹਨ, ਇਸ ਲਈ ਉਪਭੋਗਤਾ-ਫੁੱਲ — , , — ਦੁਆਰਾ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਚਾਰ ਸੁਨਹਰੀ ਸਿਗਨਲ ਜੋੜੋ, ਫਿਰ ਅਵਸਰ ਮੈਟਰਿਕਸ ਆਖਰ ਵਿੱਚ।
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 ਪਹਿਲਾਂ ਦੇਖਣਾ (ਉੱਪਰ-ਹੇਠੋਂ) ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਲੱਛਣਾਂ 'ਤੇ ਸਾਵਧਾਨ ਕਰਦੇ ਹੋ ਜੋ ਉਪਭੋਗਤਾਵਾਂ ਅਸਲ ਮਹਸੂਸ ਕਰਦੇ ਹਨ, ਫਿਰ ਕਾਰਨ ਲੱਭਣ ਲਈ ਸੁਨਹਰੀ ਸਿਗਨਲ ਅਤੇ ਅਵਸਰ ਵਿੱਚ ਡ੍ਰਿਲ ਕਰਦੇ ਹੋ।
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 ਖ਼ਤਰੇ ਵਿੱਚ ਹੋਵੇ — ਹਰ ਹਿੱਲੋਲ ਤੇ ਨਹੀਂ।
ਹੇਠੋਂ-ਉੱਪਰ ਬਣੀ ਨਿਗਰਾਨੀ ਤੁਹਾਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ ਇੱਕ disk 80% ਭਰਿਆ ਹੋਆ ਹੈ ਪਰ ਇਹ ਨਹੀਂ ਕਿ ਗ੍ਰਾਹਕ ਚੈਕਆਉਟ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਉਪਭੋਗਤਾ-ਫੁੱਲ SLI ਤੋਂ ਸ਼ੁਰੂ ਕਰਨਾ ਹਰੇਕ ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਸਾਵਧਾਨੀ ਨੂੰ ਅਸਲ ਉਪਭੋਗਤਾ ਪ੍ਰਭਾਵ ਵਿੱਚ ਬੰਨ੍ਹਦਾ ਹੈ, ਸ਼ੋਰ ਘੱਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਪਸ਼ਟ ਡ੍ਰਿਲ-ਡਾਊਨ ਮਾਰਗ ਦਿੰਦਾ ਹੈ (ਲੱਛਣ → ਸੁਨਹਰੀ ਸਿਗਨਲ → ਅਵਸਰ ਕਾਰਨ) ਜਦੋਂ ਕੁਝ ਟੁੱਟਦਾ ਹੈ।