Bagaimana Anda merancang monitoring untuk aplikasi dari awal?

Question

IT Interview Practice · Accepted Answer

Mulai **dari atas ke bawah dari apa yang pengguna rasakan**, bukan dari bawah ke atas dari infrastruktur. Fleet host yang paling andal tidak berarti apa-apa jika permintaan gagal, jadi mulai dengan **SLI** yang menghadap pengguna — **latency**, **error rate**, **availability** — kemudian tambahkan four golden signals, lalu metrik infra terakhir.

## The layering, from user inward

```text
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)
```

Jika Anda hanya mengawasi CPU dan disk (dari bawah ke atas), Anda bisa sepenuhnya hijau sementara pengguna mendapat 500s. Mengawasi SLI terlebih dahulu (dari atas ke bawah) berarti Anda alert pada **gejala yang benar-benar dirasakan pengguna**, kemudian drill down ke golden signals dan infra untuk menemukan penyebabnya.

## The pipeline: instrument → collect → dashboard → alert

```text
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
```

## A concrete starting point

```promql
# 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])))
```

Definisikan **SLO** pada setiap SLI (mis. 99.9% availability, p99 < 300ms), dashboard-kan mereka, dan alert ketika SLO berisiko — bukan pada setiap fluktuasi.

## Mengapa ini penting

Monitoring yang dibangun dari bawah ke atas memberi tahu Anda bahwa disk 80% penuh tetapi bukan bahwa pelanggan tidak dapat checkout. Memulai dari SLI yang menghadap pengguna mengikat setiap dashboard dan alert kembali ke dampak pengguna nyata, menjaga kebisingan rendah, dan memberikan jalur drill-down yang jelas (gejala → golden signal → penyebab infra) ketika sesuatu rusak.

The layering, from user inward

The pipeline: instrument → collect → dashboard → alert

A concrete starting point

Mengapa ini penting

Pertanyaan terkait