Alertmanager ile Uyarı Kurulumu

İzleme kurmanın en tatlı yanı grafiklerdir, en zor yanı ise uyarılardır. Metrik toplamak teknik bir iş; hangi durumda kimin telefonunun çalacağına karar vermek ise neredeyse bir tasarım problemidir. Fazla uyarı kurarsan ekip iki hafta sonra bildirimleri sessize alır ve gerçek arıza kimsenin dikkatini çekmez. Az kurarsan sabah müşteriden öğrenirsin. Alertmanager kurulumu bu dengeyi kurmanı sağlayan katmandır: Prometheus'un ürettiği ham uyarıları alır, gruplar, tekrarları bastırır, doğru ekibe yönlendirir ve bakım pencerelerinde susturur.

Bu rehberde Prometheus ile Alertmanager arasındaki iş bölümünü, Alertmanager'ı kurup Prometheus'a bağlamayı, ilk uyarı kuralını for ve annotations alanlarıyla birlikte doğru yazmayı, yönlendirme ağacının nasıl kurgulandığını, e-posta ve Slack bildirimlerini, susturma ile bastırma arasındaki farkı ve gürültülü bir uyarı sisteminin nasıl sakinleştirileceğini anlatacağım.

Prometheus ve Alertmanager Arasındaki İş Bölümü#

Yeni başlayanların en çok kafasını karıştıran nokta, uyarı kurallarının nerede yaşadığıdır. Kural Prometheus'ta tanımlanır, bildirim Alertmanager'da gönderilir. Prometheus her değerlendirme turunda kural dosyalarındaki PromQL ifadelerini çalıştırır; ifade sonuç döndürüyorsa o seri için bir uyarı üretir ve HTTP üzerinden Alertmanager'a iter. Alertmanager ise bu uyarıyı alır, benzerleriyle gruplar, susturulmuş mu diye bakar, hangi alıcıya gideceğini belirler ve bildirimi yollar.

Bu ayrımın pratik sonucu şudur: "uyarı gelmiyor" dediğinde iki farklı yerde arama yapman gerekir. Prometheus arayüzündeki Alerts sekmesi kuralın tetiklenip tetiklenmediğini gösterir. Uyarı orada FIRING görünüyor ama telefonun çalmıyorsa sorun Alertmanager tarafındadır — yönlendirme, alıcı yapılandırması ya da susturma kuralı. Uyarı INACTIVE ise sorun PromQL ifadesindedir. Bu iki ekranı ayırt etmek, teşhis süresini dakikalara indirir.

Bir uyarının yaşam döngüsü üç durumdan geçer:

Aradaki PENDING durumu gürültüyü kesen asıl mekanizmadır; birazdan for alanında buna döneceğiz.

Alertmanager Kurulumu ve Prometheus'a Bağlama#

Alertmanager da Prometheus gibi tek binary olarak dağıtılır. Yığının kalanı Docker'daysa aynı Compose dosyasına eklemek en pratiği olur:

# docker-compose.yml
services:
  alertmanager:
    image: prom/alertmanager:latest
    container_name: alertmanager
    restart: unless-stopped
    ports:
      - "127.0.0.1:9093:9093"
    volumes:
      - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml:ro
      - alertmanager-data:/alertmanager
    command:
      - '--config.file=/etc/alertmanager/alertmanager.yml'
      - '--storage.path=/alertmanager'

volumes:
  alertmanager-data:

Kalıcı birimi atlama; susturma kayıtları ve bildirim geçmişi orada tutulur, konteyneri yeniden oluşturduğunda aktif susturmaların silinmesini istemezsin. Ardından Prometheus'a Alertmanager'ın adresini ve kural dosyalarının yolunu tanıtırsın:

# prometheus.yml
rule_files:
  - '/etc/prometheus/rules/*.yml'

alerting:
  alertmanagers:
    - static_configs:
        - targets: ['alertmanager:9093']

Yapılandırmayı değiştirdiğinde iki dosyayı da doğrulamayı alışkanlık haline getir; hatalı bir kural dosyası Prometheus'un yeniden yüklemeyi tamamen reddetmesine yol açar:

# Prometheus yapılandırması ve kural dosyaları
promtool check config /etc/prometheus/prometheus.yml
promtool check rules /etc/prometheus/rules/*.yml

# Alertmanager yapılandırması
amtool check-config /etc/alertmanager/alertmanager.yml

# Sıcak yeniden yükleme
curl -X POST http://localhost:9090/-/reload
curl -X POST http://localhost:9093/-/reload

Prometheus tarafındaki temel yapılandırmayı henüz kurmadıysan önce Prometheus kurulumu yazısındaki adımları tamamla; Alertmanager tek başına hiçbir şey ölçmez.

İlk Uyarı Kuralını Doğru Yazmak#

Bir uyarı kuralı dört parçadan oluşur ve her biri işini yapmazsa uyarı ya gürültü olur ya işe yaramaz. expr koşulu, for süresi, labels yönlendirme bilgisini, annotations ise insanın okuyacağı metni taşır.

# /etc/prometheus/rules/sunucu.yml
groups:
  - name: sunucu-saglik
    interval: 30s
    rules:
      - alert: SunucuErisilemiyor
        expr: up{job="node"} == 0
        for: 2m
        labels:
          severity: critical
          ekip: altyapi
        annotations:
          ozet: "{{ $labels.instance }} erişilemiyor"
          aciklama: "Node Exporter 2 dakikadır cevap vermiyor. Sunucu kapalı ya da ağ erişimi kesilmiş olabilir."

      - alert: DiskDoluyor
        # Önümüzdeki 4 saatte kök disk dolacak gibi görünüyorsa
        expr: predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[6h], 4*3600) < 0
        for: 15m
        labels:
          severity: warning
          ekip: altyapi
        annotations:
          ozet: "{{ $labels.instance }} kök diski 4 saat içinde dolabilir"
          aciklama: "Mevcut boş alan {{ $value | humanize1024 }}B. Log rotasyonunu ve yedek dizinini kontrol et."

      - alert: YuksekBellekKullanimi
        expr: (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 > 90
        for: 10m
        labels:
          severity: warning
          ekip: altyapi
        annotations:
          ozet: "{{ $labels.instance }} bellek kullanımı %90 üzerinde"
          aciklama: "10 dakikadır yüksek. OOM killer devreye girmeden önce süreçleri incele."

Buradaki for alanı üzerinde özellikle durmak istiyorum, çünkü gürültünün yüzde sekseni onu atlamaktan doğar. for olmadan yazılmış bir CPU uyarısı, yedek betiği iki dakika çalıştığında tetiklenir ve hemen kapanır; ekip günde on beş kez "CPU yüksek / CPU normal" çifti alır ve kısa sürede hepsini görmezden gelmeye başlar. for: 10m yazdığında koşulun on dakika kesintisiz sağlanması gerekir, yani geçici tepeler süzülür.

annotations alanını da baştan savma doldurma. Gece üçte telefonu çalan kişi, uyarı metnini okuyup ne yapacağını anlayabilmeli. İyi bir açıklama üç şeyi içerir: neyin bozulduğu, hangi eşiğin aşıldığı ve ilk bakılacak yer. {{ $labels.instance }} ve {{ $value }} şablon değişkenleri metni somutlaştırır; humanize1024 gibi biçimlendiriciler ise ham bayt sayısını okunabilir hale getirir.

Yönlendirme Ağacı ve Gruplama#

Alertmanager'ın kalbi route ağacıdır. Gelen her uyarı kök route'tan başlayarak alt route'lara bakılır; etiketleri eşleşen ilk alt route'a düşer, eşleşme yoksa köke ait alıcıya gider. Bu yapı sayesinde veritabanı uyarısını veritabanı ekibine, kritik olanları çağrı sistemine, geri kalanını e-postaya yollarsın.

# alertmanager.yml
route:
  receiver: 'varsayilan-eposta'
  # Aynı sunucu ve aynı uyarı adı tek bildirimde toplansın
  group_by: ['alertname', 'instance']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h

  routes:
    - matchers:
        - severity = "critical"
      receiver: 'kritik-slack'
      # Kritik uyarılar daha sık hatırlatılsın
      repeat_interval: 1h
      continue: false

    - matchers:
        - ekip = "veritabani"
      receiver: 'veritabani-ekibi'

receivers:
  - name: 'varsayilan-eposta'
    email_configs:
      - to: '[email protected]'

  - name: 'kritik-slack'
    slack_configs:
      - channel: '#alarm'
        send_resolved: true

  - name: 'veritabani-ekibi'
    email_configs:
      - to: '[email protected]'

Dört zamanlama parametresi ilk bakışta birbirine karışır; anlamları şöyle ayrışır:

group_by seçimi gürültü açısından kritiktir. ['alertname'] ile gruplarsan on sunucu birden düştüğünde tek bildirim alırsın — bir anahtar arızasında bu tam istediğin şeydir. ['alertname', 'instance'] dersen her sunucu için ayrı bildirim gelir; küçük filoda bilgi verici, büyük filoda felakettir. group_by: ['...'] özel değeri ise gruplamayı tamamen kapatır ve genellikle istemediğin şeydir.

Bildirim Kanalları ve Şablonlar#

E-posta en yaygın başlangıç kanalıdır ama üretimde tek başına yeterli değildir; posta kutusu gece üçte kimseyi uyandırmaz. Yine de doğru kurulması gerekir:

global:
  smtp_smarthost: 'smtp.firmaniz.com:587'
  smtp_from: '[email protected]'
  smtp_auth_username: '[email protected]'
  smtp_auth_password: 'SMTP_PAROLASI'
  smtp_require_tls: true

receivers:
  - name: 'varsayilan-eposta'
    email_configs:
      - to: '[email protected]'
        send_resolved: true
        headers:
          subject: '[{{ .Status | toUpper }}] {{ .CommonLabels.alertname }}'

SMTP ayarları çalışmıyorsa Alertmanager loglarında dial tcp ... connection refused ya da kimlik doğrulama hatası görürsün. Port ve TLS modu uyumsuzluğu en sık nedendir; hangi portun hangi şifreleme modunu beklediğini ve komut satırından nasıl test edileceğini SMTP test aracı üzerinden hızlıca doğrulayabilirsin. Uyarı e-postalarının spam klasörüne düşmemesi için gönderen alan adının SPF ve DKIM kayıtlarının düzgün olması da şart — kritik bir uyarının spam'e düşmesi, hiç gönderilmemesiyle aynı sonucu verir.

Webhook alıcısı ise en esnek seçenektir; kendi yazdığın küçük bir servise JSON gönderip oradan istediğin kanala (SMS ağ geçidi, çağrı sistemi, dahili panel) dağıtabilirsin:

  - name: 'webhook-kopru'
    webhook_configs:
      - url: 'http://kopru.firmaniz.local:8080/alert'
        send_resolved: true
        max_alerts: 20

Susturma, Bastırma ve Bakım Pencereleri#

Planlı bakım yaparken uyarıların susmasını istersin; bunun doğru yolu kuralı silmek değil silence oluşturmaktır. Alertmanager arayüzünden ya da komut satırından süre ve etiket eşleşmesi vererek uyarıyı geçici olarak susturursun:

# web-01 sunucusunun tüm uyarılarını 2 saat sustur
amtool silence add instance="10.0.0.11:9100" \
  --duration=2h \
  --author="ozan" \
  --comment="Planli cekirdek guncellemesi"

# Aktif susturmaları listele
amtool silence query

# Süresi dolmadan kaldır
amtool silence expire <silence-id>

--comment alanını boş bırakma; üç gün sonra "bu neden susturulmuş" sorusuna cevap veren tek şey odur. Susturmaya her zaman bir süre ver, süresiz susturma en sonunda unutulan ve gerçek arızayı gizleyen şeye dönüşür.

Inhibition (bastırma) ise farklı bir mekanizmadır: bir uyarı aktifken başka bir uyarıyı otomatik olarak bastırır. Klasik örnek, sunucu tamamen erişilemez olduğunda o sunucuya ait disk ve bellek uyarılarının gönderilmemesidir — makine kapalıyken diskinin dolacağını haber vermenin anlamı yok.

inhibit_rules:
  - source_matchers:
      - alertname = "SunucuErisilemiyor"
    target_matchers:
      - severity = "warning"
    # Aynı sunucuya ait uyarılar bastırılsın
    equal: ['instance']

Sık Yapılan Hatalar ve Tuzaklar#

for alanını hiç kullanmamak. Anlık dalgalanmalar bildirime dönüşür, ekip iki hafta içinde bildirimleri filtreye alır ve sistem işlevsiz kalır. Neredeyse her kurala en az for: 5m koy.

Uyarıyı çözülebilir hale getirmemek. "CPU yüksek" bir uyarı değil bir gözlemdir. İyi bir uyarı, kullanıcıyı etkileyen bir belirtiyi ölçer: istekler hata dönüyor, disk dolmak üzere, servis cevap vermiyor. Kaynak kullanımı yüksek ama kimse etkilenmiyorsa bu bir pano konusudur, bildirim konusu değil.

Alertmanager'ı yapılandırmadan bırakmak. Varsayılan yapılandırmayla Alertmanager uyarıları kabul eder ama hiçbir yere göndermez. Prometheus arayüzünde FIRING görüp bildirim beklerken saatler geçebilir; amtool config routes test komutuyla bir uyarının hangi alıcıya düşeceğini önceden sınayabilirsin.

Bildirim kanalını test etmemek. Kural doğru, yönlendirme doğru, ama SMTP parolası yanlış. amtool ile sahte bir uyarı gönderip zinciri baştan sona doğrula; ilk gerçek arıza test anın olmasın.

Susturmayı süresiz yapmak. "Şimdilik kapatalım" diye açılan süresiz susturmalar aylarca yaşar. Bakım penceresi ne kadarsa süreyi o kadar ver.

Aynı uyarıyı hem Grafana'da hem Prometheus'ta tanımlamak. İki motor da tetiklenir, ekip her olayda çift bildirim alır ve hangisinin doğru olduğunu kimse bilmez. Uyarı mantığını tek yerde tut; panolar için Grafana dashboard oluşturma yazısındaki ayrımı takip et.

Sıkça Sorulan Sorular#

Uyarı kuralları Prometheus'ta mı Alertmanager'da mı tanımlanır#

Kurallar Prometheus'ta, rule_files ile gösterilen YAML dosyalarında tanımlanır. Alertmanager kural bilmez; yalnızca Prometheus'un ürettiği uyarıları alır, gruplar ve yönlendirir. Bu yüzden bir uyarının tetiklenip tetiklenmediğini Prometheus arayüzündeki Alerts sekmesinden, bildirimin gidip gitmediğini ise Alertmanager arayüzünden kontrol edersin.

Alertmanager olmadan Prometheus uyarı gönderebilir mi#

Hayır. Prometheus uyarı koşullarını değerlendirir ve durumu kendi arayüzünde gösterir, ancak e-posta, Slack ya da webhook gönderme yeteneği yoktur; bu iş tamamen Alertmanager'a bırakılmıştır. Alertmanager tanımlı değilse uyarılar FIRING durumunda kalır ama hiçbir yere iletilmez. Tek istisnası, Grafana'nın kendi uyarı motorunu kullanmayı tercih etmendir.

Uyarı tetiklendi ama bildirim gelmiyor, ne kontrol etmeliyim#

Sırayla dört şeye bak. Prometheus arayüzünde uyarı gerçekten FIRING mi, yoksa hâlâ PENDING mi. Alertmanager arayüzünde uyarı görünüyor mu — görünmüyorsa Prometheus'un alerting bloğundaki hedef yanlıştır. Aktif bir susturma ya da bastırma kuralı var mı. Son olarak amtool config routes test ile uyarının hangi alıcıya düştüğünü sına; çoğu zaman etiket eşleşmesi beklediğin route'a denk gelmiyordur.

Gece uyarılarını nasıl azaltırım#

En etkili üç yöntem şunlar: her kurala yeterli bir for süresi koy, severity etiketiyle kritik olanları ayır ve yalnızca kritikleri çağrı kanalına yönlendir, geri kalanı sabah bakılacak bir e-posta ya da sohbet kanalına düşür. Ayrıca bastırma kurallarıyla ardışık uyarıları tek bir kök nedene indir. Bir uyarı gece uyandırmayı hak etmiyorsa gece kanalında olmamalıdır.

Uyarı eşiklerini hangi değerlere göre belirlemeliyim#

Sabit sayılar yerine hizmet hedeflerinden geriye doğru çalış. Kullanıcıya verdiğin erişilebilirlik ve yanıt süresi taahhüdü neyse, eşikler o taahhüdü tehlikeye atmadan önce haber verecek şekilde ayarlanır. Ne kadar kesinti süresinin hangi erişilebilirlik yüzdesine denk düştüğünü görmek için uptime SLA hesaplayıcı aracımız iyi bir başlangıç noktası verir. Kaynak eşikleri içinse birkaç haftalık geçmiş veriye bakıp normal tepe noktalarının biraz üstünü seç.

Alertmanager'ı yedekli çalıştırabilir miyim#

Evet, Alertmanager kümeleme (clustering) destekler. Birden fazla örneği --cluster.peer parametresiyle birbirine tanıtırsın; örnekler bildirim durumunu paylaşır ve aynı uyarı için tek bildirim gönderilir. Prometheus tarafında ise alertmanagers listesine tüm örnekleri yazarsın, Prometheus uyarıyı hepsine iletir ve tekrarı Alertmanager kümesi kendi arasında çözer. Kritik ortamlarda en az iki örnek çalıştırmak makul bir tercihtir.

Kapanış#

İyi bir uyarı sistemi, çok uyarı kurandan değil doğru uyarıyı doğru kişiye ulaştırandan çıkar. Aklında kalması gereken dört alışkanlık: her kurala anlamlı bir for süresi ver, annotations alanına gece üçte okunabilecek somut bir yönerge yaz, group_by ve severity ile gürültüyü kaynağında kes, ve bakım pencerelerinde kuralı silmek yerine süreli bir susturma kullan. Bir uyarıyı kapatmak istediğini fark ettiğin an, o uyarı ya yanlış eşikte ya da hiç kurulmaması gereken bir uyarıdır.

Bu yığını çalıştırmak sürekli açık bir sunucu ve dışa açık bir bildirim kanalı ister. Kendi izleme sunucunu kurmak için VDS ya da bulut sunucu paketlerimiz uygun bir zemin sunar; uyarı e-postalarının teslim edilebilirliğini önemsiyorsan SMTP sunucu çözümümüz ayrılmış IP ve kurulu bir posta yığınıyla gelir. Kurulumu ve uyarı kurallarının bakımını üstlenmemizi isterseniz sunucu yönetimi hizmetimiz bu kapsamı da içeriyor.