API monitoring: 4 temel metrik (latency, error, throughput, saturation)

API monitoring ilk kurduğumda 40 farklı metrik takip ediyordum. Her biri teorik olarak önemli. Pratikte incident olduğunda hangisinde sorun olduğunu bulmak 20 dakika sürüyordu. Google SRE kitabının “Four Golden Signals” yaklaşımına geçtim, dashboard sadeleşti, incident detection hızlandı. Paylaşayım.

Dört temel sinyal

1. Latency (gecikme): isteklerin cevap süresi.
2. Error rate (hata oranı): başarısız isteklerin yüzdesi.
3. Throughput (yoğunluk): saniyede istek sayısı.
4. Saturation (doygunluk): sistem kapasitesinin kullanım oranı.

Bu dördü dışındaki metrikler bunlardan türev veya detail drill-down. Ana dashboard’da sadece bunlar olsun.

Latency

Ortalama gecikme yalan söyler. Yüzdelik kullanın:

• p50 (median): çoğunluk kullanıcı nasıl?
• p95: nispeten yavaş kullanıcılar
• p99: worst case
• p99.9: tail latency, outlier’lar

Bir API’nin ortalama latency’si 200ms olabilir, p99’u 3 saniyedir. Ortalama bakarsanız sorunu fark etmezsiniz.

Prometheus query:

histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))

Alert eşiği projenize göre ama örnek:
– p95 > 500ms → warning
– p95 > 1s → page
– p99 > 2s → page

Latency artışı genelde downstream bir servisin yavaşladığının ilk sinyali. Database’in yorulması, cache’in isabetsizliği, ağ problemi, vs.

Error rate

HTTP 5xx hatası oranı. 4xx’i ayrı ölçün, kullanıcı hatası kategorisi.

Prometheus query:

sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

Bu oran genelde %0.1 altında olur normal koşullarda. %1 görünce dikkat, %5 görünce panik.

Alert eşiği:
– %0.5 → warning
– %1 → page

Error rate sıçraması genelde deployment sonrası bug, database connection tükenmesi, third-party API kesintisi sinyali.

Throughput

Saniyede istek sayısı (RPS). Hem bir kapasite metriği hem de business’ı yansıtan bir sinyal.

sum(rate(http_requests_total[1m]))

Üç pattern dikkat çeker:

1. Ani düşüş: trafik birden kesildi. Load balancer problemi? DNS? Frontend hata alıp istek atmıyor olabilir.
2. Ani artış: DDoS? Viral moment? Retry storm? Rate limit devreye girmesi gerekebilir.
3. Beklenen trafik dışında anomaly: cuma 14:00’te normal 200 RPS, bu cuma 50 RPS. Sorun var.

Throughput alert’i eşik değil anomali tespiti daha iyi. Ortalama ±standard deviation’un dışındaysa uyar.

Saturation

Sistem kaynaklarının doygunluk oranı. CPU, memory, disk I/O, ağ bant genişliği, database connection pool, thread pool.

Özellikle dikkat edilecekler:

• CPU: %80 üstü sürekliyse darboğaz.
• Memory: %85 üstü, OOM riski.
• DB connection pool: %80 kullanımda, tükenme yakın.
• Disk I/O: iowait yüksekse DB yavaşlar.
• Queue length: job queue biriktiyse consumer yetersiz.

Saturation diğer üç sinyalin öncü göstergesi. Saturation artıyor ama henüz latency düşmemişse hâlâ müdahale şansınız var.

Dashboard tasarımı

Tek sayfada dört sinyal, trafik ışığı renkleriyle:

┌─────────────┬─────────────┐
│  Latency    │  Error rate │
│  p95: 180ms │  0.2%       │
│  ● yeşil    │  ● yeşil    │
├─────────────┼─────────────┤
│  Throughput │  Saturation │
│  450 rps    │  CPU 62%    │
│  ● yeşil    │  DB 45/100  │
└─────────────┴─────────────┘

Drill-down için altına servis bazlı kırılımlar, endpoint listesi, database metrics.

Alert fatigue’den kaçın

Her anomaliye uyarı koymayın. Anomali ≠ incident.

• Alert sadece action gerektiriyorsa.
• Multi-window: 5 dakika + 1 saat window. İkisi de aynı anda eşiği geçerse alert.
• Symptom-based alert. “CPU %80” alert’i gereksiz, “latency bozuluyor ve CPU %80” alert’i değerli.

Burnrate alerts SRE book’ta detaylı anlatılır. SLO bütçesini takip edip bütçenin hızla tükendiği durumlarda uyarır.

Logging + tracing

Metrikler “bir şey oldu” der. Ne olduğunu anlamak için:

• Logging: yapılandırılmış JSON log. Error, user_id, request_id, endpoint.
• Tracing: istek bir servis ağı boyunca nasıl hareket etti? OpenTelemetry, Jaeger.
• Profiling: CPU/memory profile on-demand. Pprof veya Continuous Profiling.

Metric + log + trace = observability triad. Üçü bir arada olmadan incident debug uzun sürüyor.

Tool stack

Kullandığım tipik kombinasyon:

• Metrics: Prometheus + Grafana.
• Logs: Loki veya ELK.
• Tracing: Tempo veya Jaeger.
• Alerting: Alertmanager + PagerDuty.
• SLO tracking: Nobl9 veya custom Grafana dashboard.

Küçük ölçekte tek tool (Datadog, New Relic) entegre çözüm sunuyor ama pahalı. Büyük ölçekte açık kaynak stack ekonomik.

Başlangıç önerisi

İlk gün dört sinyali koyun. Tek dashboard. Sadece kritik alert’ler. İncident oldukça drill-down metric eklersiniz. Sonuna kadar 40 metric’le başlamayın.