Monitoring & Observability
Sistem çöktükten sonra değil, anormallik başladığı an haberdar olun. Sadece metrik toplamıyor, şirketinizde gözlemlenebilirlik kültürü kuruyoruz.
Observability Ekosistemi
Ne yapıyoruz?
Alarm geldiğinde değil, sorun oluşmadan önce fark etmek. Metrics, logs ve traces — üç pileri birleştiren ve ekibin gerçekten kullandığı bir gözlemlenebilirlik sistemi kuruyoruz.
Observability Stratejisi
Metrics, logs ve traces: gözlemlenebilirliğin üç sütununu birlikte ele alan mimari tasarımı. Hangi araç nerede, neden — net kararlarla.
Prometheus Kurulum ve Konfigürasyon
Prometheus kurulumu, scrape konfigürasyonu, recording rule'lar ve remote write ile uzun süreli metric depolama (Thanos/Cortex).
Grafana Dashboard Tasarımı
RED method (Rate, Errors, Duration) ve USE method (Utilization, Saturation, Errors) bazlı servis ve altyapı dashboard'ları.
Alertmanager Kural Seti
Anlamlı, düşük gürültülü alert tanımları. On-call rotasyonu için PagerDuty, OpsGenie veya Slack entegrasyonu. Alarm yorgunluğunu önlemek için threshold kalibrasyonu.
Distributed Tracing
Jaeger veya Tempo ile servisler arası istek izleme. Yavaş endpoint ve darboğaz tespiti için trace görselleştirmesi.
SLI / SLO Tanımı
Servis bazında SLI (availability, latency) ve SLO hedeflerinin tanımlanması. Error budget takibi ve burn rate alerting.
Observability Kurulum Süreci
Metric envanterinden on-call entegrasyonuna — ekibinizin gece uyuyabileceği bir alarm sistemi.
- 1
Metric Envanteri
Mevcut alerting boşlukları, 'silent failure' senaryoları ve hangi metriklerin gerçekten aksiyon alınabilir olduğu analiz edilir.
- 2
Prometheus Stack
Scrape konfigürasyonu, recording rule'lar ve remote write ile Thanos'a uzun süreli metric depolama kurulumu.
- 3
Dashboard & SLO
RED/USE metodoloji bazlı Grafana dashboard'ları, SLI/SLO tanımı ve error budget takibi konfigürasyonu.
- 4
Alerting & On-Call
Anlamlı, düşük gürültülü alert kuralları, Alertmanager routing ve PagerDuty/Slack/Teams on-call entegrasyonu.
Alarmdan Aksiyona: Incident Akış Senaryosu
HighCPU metriği eşiği aştığında, bir mühendis konuya bakan olmadan önce Slack'te aksiyon alınabilir bir bildirim oluşur. Sıfır manuel müdahale.
Alert Kuralı
alert: HighCPUUsage
expr: avg(rate(container_cpu_usage_seconds_total[5m])) by (node) > 0.85
for: 5m
labels:
severity: critical
team: platform
annotations:
summary: "Node {{ $labels.node }} CPU yüksek"
description: "CPU {{ $value | humanizePercentage }} - 5 dakikadır"
runbook_url: "https://runbooks.internal/k8s-highcpu"Eşleşen Route
severity = critical
→ ops-critical receiver
Deduplikasyon
group_wait: 30s
group_interval: 5m
Susturma
İş dışı saatlerde
repeat_interval: 1h
Node: worker-node-03 | CPU: %92 | Süre: 7 dakika
Pod: api-gateway-7f8b4c-xk9p2 | NS: production
Neden bu önemli: Sistemin %92 CPU'da 7 dakika çalıştığını fark etmek için kimsenin ekrana bakması gerekmiyor. Alarm, doğrudan nedenle ve runbook bağlantısıyla geliyor — ortalama MTTR 45 dakikadan 8 dakikaya iniyor.
Gözlemlenebilirliğin üç sütunu
Prometheus · Grafana · Thanos
CPU, memory, latency, error rate — sayısal veriler. Trend analizi, kapasite planlaması ve SLO takibi için.
Loki · Fluent Bit · OpenSearch
Olayların kronolojik kaydı. 'Ne oldu, ne zaman, hangi serviste' sorusunun cevabı.
Jaeger · Tempo · OpenTelemetry
Servisler arası istek akışı. Yavaş endpoint ve bağımlılık darboğazlarının tespiti.
Teknolojiler
Kimler için?
Üretim sistemleri olan ve downtime veya performance sorunlarını proaktif çözmek isteyen ekipler. Özellikle alerting'i olmayan ya da her alarm geldiğinde tüm ekibin uyandığı (alert yorgunluğu) ve bunu kökten düzeltmek isteyen mühendislik ekipleri için.
Mevcut durumu konuşmaya hazır mısınız?
Mevcut altyapınızı ve en kritik iyileştirme noktalarını doğrudan konuşalım.
Ücretsiz değerlendirme talep et