Start , ikke bottom-up fra infrastruktur. Den mest pålidelige host fleet er værdiløs, hvis anmodninger fejler, så begin med brugerorienterede — , , — og tilføj derefter de fire gyldne signaler, og til sidst infrastruktur-metrics.
Start , ikke bottom-up fra infrastruktur. Den mest pålidelige host fleet er værdiløs, hvis anmodninger fejler, så begin med brugerorienterede — , , — og tilføj derefter de fire gyldne signaler, og til sidst infrastruktur-metrics.
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)
Hvis du kun overvåger CPU og disk (bottom-up), kan du være helt grøn, mens brugerne får 500s. At overvåge SLIs først (top-down) betyder, at du advarer om symptomer, som brugerne faktisk oplever, og derefter dykker ned i gyldne signaler og infrastruktur for at finde årsagen.
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])))
Definer en SLO på hvert SLI (f.eks. 99,9% tilgængelighed, p99 < 300ms), dashboard dem, og advar, når SLO er i risiko — ikke ved hver udsving.
Overvågning bygget bottom-up fortæller dig, at en disk er 80% fuld, men ikke at kunderne ikke kan tjekke ud. At starte fra brugerorienterede SLIs binder hvert dashboard og hver advarsel tilbage til reel brugerindflydelse, holder støj lav og giver en klar drildown-vej (symptom → gyldent signal → infrastruktur-årsag), når noget går i stykker.