Prometheus Alerting Rules ve Recording Rules Yazma Rehberi
Gece saat 03:00. Telefonunuz acı acı çalıyor. Gözlerinizi kırpıştırarak ekrana bakıyorsunuz: “CPU Usage is High!”. Kalbiniz küt küt atarak bilgisayarı açıyor, Kubernetes cluster’ına bağlanıyor ve aslında her şeyin normal olduğunu, sadece anlık bir cron job’ın CPU’yu tetiklediğini görüyorsunuz. Tebrikler, “Alert Fatigue” (alarm yorgunluğu) kulübüne hoş geldiniz! Modern devops ve sre dünyasında, yanlış yapılandırılmış bir prometheus ve alerting altyapısı kadar ekipleri yıpratan çok az şey vardır. Bu rehberde, uykularınızı kaçırmayacak, gerçekten aksiyon alınabilir alert kuralları yazmayı ve recording rules kullanarak Prometheus sunucunuzun CPU’sunu nasıl rahatlatacağınızı konuşacağız.
1. Alert Felsefesi: “Semptom” vs. “Sebep”
Bir alert kuralı yazmadan önce kendimize sormamız gereken ilk soru şudur: “Bu alarm çaldığında birinin yataktan kalkıp hemen bir şey yapması gerekiyor mu?” Cevap hayır ise, o bir alert değil, sadece bir metric veya en fazla bir dashboard grafiğidir.
SRE dünyasında alert’leri ikiye ayırırız:
- Semptom Tabanlı (Symptom-based): “Kullanıcılar 500 hatası alıyor.” (Hemen müdahale edilmeli!)
- Sebep Tabanlı (Cause-based): “Node CPU kullanımı %92.” (Belki de Kubernetes bunu zaten scale edecek, neden uyandırılıyorum?)
Her zaman semptomlara alert kurmaya çalışın. CPU yükselmesi tek başına bir felaket değildir; eğer bu durum latency (gecikme) artışına veya hata oranının (error rate) yükselmesine sebep olmuyorsa, bırakın Prometheus sessizce metric toplamaya devam etsin.
2. Etkin Prometheus Alerting Rules Yazmak
Prometheus üzerinde alert tanımlarken PromQL dilinin gücünden faydalanırız. Ancak verimsiz yazılan sorgular hem Prometheus’u yorar hem de yanlış alarmlara (false positive) yol açar.
Kötü Bir Örnek ve Analizi
- alert: HighCPUUsage
expr: node_cpu_seconds_total{mode="idle"} < 10
for: 1m
labels:
severity: critical
annotations:
summary: "CPU usage is high on {{ $labels.instance }}"
Bu kural neden kötü?
- Çok kısa süre (for: 1m): 1 dakikalık bir CPU yükselmesi geçici bir spike (anlık sıçrama) olabilir. Hemen alarm tetiklemek anlamsızdır.
- Ham metric kullanımı: `node_cpu_seconds_total` doğrudan kullanılmamalı, rate() veya irate() fonksiyonları ile normalize edilmelidir.
- Aksiyon yok: “CPU yüksek” bilgisini alan bir mühendis ne yapmalı? Annotation içinde bir runbook linki yok.
Daha İyi Bir Yaklaşım
- alert: NodeCPUUtilizationHigh
expr: (100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)) > 85
for: 15m
labels:
severity: warning
team: platform
annotations:
summary: "Node {{ $labels.instance }} CPU utilization is above 85% for 15 minutes."
description: "High CPU might impact application performance. Check Pod distribution."
runbook_url: "https://wiki.kertenkerem.net/ops/runbooks/high-node-cpu"
Burada neyi değiştirdik? Sorguyu 5 dakikalık pencerelerde `rate` alacak şekilde optimize ettik, bekleme süresini (`for`) 15 dakikaya çıkararak geçici spike’ları eledik ve en önemlisi, alarmı alan mühendis için bir `runbook_url` ekledik.
3. Prometheus’u Coşturmak: Recording Rules
Prometheus her `evaluation_interval` süresinde (genelde 15-30 saniye) tüm alert kurallarını sıfırdan hesaplar. Eğer yukarıdaki gibi ağır matematiksel işlemler içeren yüzlerce kuralınız ve binlerce node/pod içeren bir cluster’ınız varsa, Prometheus sunucunuzun CPU ve Memory kullanımı tavan yapacaktır. İşte burada sahneye recording rules çıkıyor.
Recording rules, karmaşık ve sık çalıştırılan PromQL sorgularının sonuçlarını önceden hesaplayıp yeni bir metric olarak kaydetmenizi sağlar. Böylece alert kuralları veya Grafana dashboard’ları bu karmaşık sorguyu her seferinde çalıştırmak yerine, önceden hesaplanmış hazır veriyi okur.
Yavaş Sorgu Örneği (Kubernetes Pod CPU Utilization)
Grafana dashboard’unuzda veya alert kuralınızda her 15 saniyede bir şu sorgunun çalıştığını hayal edin:
sum by (namespace, pod) (rate(container_cpu_usage_seconds_total{container!=""}[5m]))
Bunu optimize etmek için bir recording rule tanımlayalım:
groups:
- name: kertenkerem.cpu.rules
rules:
- record: namespace_pod:container_cpu_usage:rate5m
expr: sum by (namespace, pod) (rate(container_cpu_usage_seconds_total{container!=""}[5m]))
Artık Prometheus arkada bu sorguyu sessizce çalıştırıp sonucu `namespace_pod:container_cpu_usage:rate5m` isimli yeni ve tertemiz bir metric olarak kaydedecek. Şimdi alert kuralımızı bu yeni metric üzerinden yazalım:
- alert: PodCPULimitApproaching
expr: namespace_pod:container_cpu_usage:rate5m > 0.90
for: 10m
labels:
severity: warning
Prometheus artık her sorgulamada diskten gigabaytlarca veri okuyup CPU hesaplaması yapmak zorunda kalmayacak. Doğrudan hazır hesaplanmış tek bir metric değerine bakacak. Disk I/O ve CPU tüketiminizde inanılmaz bir düşüş göreceksiniz.
4. Alertmanager ile Gürültüyü Engelleme: Inhibition ve Silence
Prometheus alert’i üretir, ancak bu alert’lerin nereye (Slack, PagerDuty, Webhook) nasıl gideceğini yöneten yer Alertmanager bileşenidir. Alert gürültüsünü kesmek için iki can kurtaran silahımız var: Inhibition Rules ve Silences.
Inhibition Rules (Engelleme Kuralları)
Bir veri merkezindeki tüm sunucuların bağlı olduğu ana switch çöktüğünde ne olur? Muhtemelen o switch arkasındaki 50 sunucu ve üzerindeki 500 pod için ayrı ayrı “Node Down” ve “Pod Down” alarmı alırsınız. Telefonunuz bildirim yağmurundan kilitlenir.
Inhibition rules, belirli bir ana alarm aktifken, onunla ilişkili alt alarmların susturulmasını sağlar. Klasik bir Alertmanager konfigürasyon örneği:
inhibit_rules:
- source_matchers: [alertname="NodeNetworkDown"]
target_matchers: [alertname="InstanceDown"]
equal: ['node', 'instance']
Yukarıdaki kural der ki: Eğer bir node için `NodeNetworkDown` alarmı zaten tetiklendiyse, aynı node üzerindeki servisler için `InstanceDown` (servis ulaşılamaz) alarmı gönderme, onu block’la. Mühendis zaten ağın gittiğini biliyor, servislerin de gitmiş olacağını tahmin etmek için dahi olmaya gerek yok!
Silencing (Susturma) ve Maintenance
Planlı bir bakım çalışması (maintenance window) yapıyorsunuz ve Kubernetes cluster’ındaki bazı node’ları restart edeceksiniz. Bu sırada Slack kanalınızın “CRITICAL” loglarıyla dolmasını istemezsiniz.
Bunun için Alertmanager UI üzerinden veya `amtool` CLI aracını kullanarak hızlıca geçici “silence” tanımları yapabilirsiniz:
amtool silence add alertname="NodeCPUUtilizationHigh" node="node-01" --duration=2h --comment="Planli kernel upgrade calismasi"
Bu komut, `node-01` üzerindeki yüksek CPU alarmlarını 2 saat boyunca askıya alır. Bakım bittiğinde sistem otomatik olarak normal haline döner.
Sonuç: Temiz Alarmlar, Huzurlu Geceler
Prometheus ile monitoring kurmak kolaydır; ancak akıllıca tasarlanmış bir alarm yapısı kurmak gerçek bir mühendislik disiplini gerektirir. Özetlemek gerekirse:
- Sadece aksiyon almanız gereken durumlarda telefonunuzu çaldırın.
- Ağır PromQL sorgularınızı recording rules ile önceden hesaplayarak Prometheus’u rahatlatın.
- Alertmanager’ın inhibition kurallarını kullanarak kriz anlarında alarm bombardımanına tutulmaktan kaçının.
Bir sonraki yazımızda görüşmek üzere, metrics’iniz bol, geceleriniz sessiz olsun!
