Gece saat 03:00. Cep telefonunuz ardı ardına titriyor. Zabbix size “CPU usage high on prod-db-01” başlıklı tam 142 adet SMS göndermiş. Gözlerinizi oğuşturarak bilgisayarı açıyorsunuz ve durumun aslında sadece planlı bir veritabanı yedeğinden (backup job) ibaret olduğunu, diskin veya veritabanının çökmediğini görüyorsunuz. Bu esnada sinirden köpürürken kendinize şu soruyu soruyorsunuz: “Neden bu alarmları gruplayamadım? Neden nöbetçi arkadaşım yerine tüm ekip ayağa kalktı?”

İşte tam bu noktada, geleneksel izleme canavarımız zabbix ile modern bulut dünyasının alarm yönetim standardı olan alertmanager‘ı evlendirmenin vakti gelmiş demektir. Bu makalede, Zabbix’in topladığı metrik ve trigger’ları Alertmanager’a köprüleyecek, oradan da slack ve pagerduty entegrasyonları ile akıllı, gürültüsüz ve insan odaklı bir oncall yönetim yapısı kuracağız.

Neden Doğrudan Zabbix Değil de Alertmanager?

Zabbix, metrik toplama (polling), agent yönetimi ve esnek trigger tanımlama konularında harika bir araçtır. Ancak iş alarm yönetimine (alert routing, deduplication, inhibition ve silencing) geldiğinde Zabbix’in aksiyon (Action) arayüzü hantal kalır. GitOps felsefesine uygun değildir, sürüm kontrolü (version control) zordur ve karmaşık eskalasyon senaryolarında konfigürasyon cehennemine dönüşebilir.

Alertmanager ise Prometheus ekosisteminin kalbidir ancak sadece Prometheus ile sınırlı olmak zorunda değildir. Bize sunduğu avantajlar şunlardır:

• Deduplication (Tekilleştirme): Aynı anda patlayan 50 benzer alarmı tek bir Slack mesajında birleştirir.
• Inhibition (Bastırma): Eğer bir veri merkezi (datacenter) çöktüyse, o veri merkezinin içindeki 100 makine için “Node Down” alarmı göndermez; sadece “Datacenter Offline” alarmını geçirir, diğerlerini bastırır.
• Dynamic Routing (Dinamik Yönlendirme): Alarma basılan etiketlere (labels) göre alarmı anında doğru ekibe (DBA, Network, Frontend) yönlendirir.

Adım 1: Zabbix Webhook ile Alertmanager API Köprüsü Kurmak

İlk yapmamız gereken iş, Zabbix’te bir trigger tetiklendiğinde bunu Alertmanager’ın /api/v2/alerts endpoint’ine gönderecek bir “Media Type” tanımlamaktır. Alertmanager, kendisine gönderilen JSON payload’unda belirli standartlar bekler.

Zabbix arayüzünde Administration -> Media Types sekmesine gidin ve “Create media type” butonuna tıklayın. Tipi Webhook olarak seçin ve aşağıdaki parametreleri ekleyin:

// Zabbix Webhook Script içeriği
try {
    var params = JSON.parse(value),
        req = new HttpRequest(),
        payload = [];

    if (typeof params.AlertmanagerURL === 'undefined') {
        throw 'AlertmanagerURL parametresi eksik.';
    }

    // Alertmanager API v2 formatı
    var alert = {
        "labels": {
            "alertname": params.AlertName,
            "severity": params.Severity,
            "instance": params.HostName,
            "service": params.Service || "infrastructure",
            "environment": params.Environment || "production"
        },
        "annotations": {
            "summary": params.TriggerDescription,
            "value": params.TriggerValue,
            "zabbix_url": params.ZabbixURL + "/tr_events.php?triggerid=" + params.TriggerID
        }
    };

    // Zabbix alarm durumuna göre durumu eşle (Eğer OK ise çözüldü olarak gönder)
    if (params.TriggerStatus === 'OK') {
        alert["endsAt"] = new Date().toISOString();
    } else {
        alert["startsAt"] = new Date().toISOString();
    }

    payload.push(alert);

    req.addHeader('Content-Type: application/json');
    var response = req.post(params.AlertmanagerURL + '/api/v2/alerts', JSON.stringify(payload));

    if (req.getStatus() !== 200 && req.getStatus() !== 201) {
        throw 'HTTP hatası: ' + req.getStatus() + '\nResponse: ' + response;
    }

    return 'OK';
} catch (error) {
    Zabbix.log(3, 'Alertmanager webhook hatası: ' + error);
    throw error;
}

Bu JS kodu, Zabbix trigger’ı tetiklendiğinde ya da çözüldüğünde (OK durumuna geçtiğinde) Alertmanager’a RFC3339 formatında zaman damgasıyla birlikte durumu iletir. Böylece Alertmanager alarmın çözüldüğünü (resolved) anlar ve Slack/PagerDuty üzerindeki açık alarmı otomatik olarak kapatır.

Adım 2: Alertmanager Konfigürasyonu (`alertmanager.yml`)

Şimdi Alertmanager tarafında bu alarmları nasıl karşılayacağımızı ve nereye yönlendireceğimizi tanımlayalım. production ortamlarında genellikle kritik alarmların PagerDuty’ye (ve dolayısıyla nöbetçi mühendisin telefonuna), uyarı seviyesindeki alarmların ise sadece Slack kanalına gitmesini isteriz.

global:
  resolve_timeout: 5m

route:
  group_by: ['alertname', 'instance', 'environment']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'slack-default'
  routes:
    # Kritik üretim alarmları hem Slack'e hem PagerDuty'ye gitsin
    - match:
        severity: 'disaster'
        environment: 'production'
      receiver: 'pagerduty-critical'
      continue: true
    
    # Tüm üretim alarmları Slack kanalına düşsün
    - match:
        environment: 'production'
      receiver: 'slack-production'

receivers:
- name: 'slack-default'
  slack_configs:
  - api_url: 'https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX'
    channel: '#ops-alerts-test'
    send_resolved: true
    text: "Alarm: {{ .CommonAnnotations.summary }}\nSeverity: {{ .CommonLabels.severity }}\nHost: {{ .CommonLabels.instance }}"

- name: 'slack-production'
  slack_configs:
  - api_url: 'https://hooks.slack.com/services/T00000000/B00000000/YYYYYYYYYYYYYYYYYYYYYYYY'
    channel: '#prod-alerts'
    send_resolved: true
    title: "[{{ .Status | toUpper }}] {{ .CommonLabels.alertname }}"
    text: "Host: {{ .CommonLabels.instance }}\nDetay: {{ .CommonAnnotations.summary }}\nZabbix Linki: {{ .CommonAnnotations.zabbix_url }}"

- name: 'pagerduty-critical'
  pagerduty_configs:
  - service_key: 'YOUR_PAGERDUTY_INTEGRATION_KEY_HERE'
    severity: 'critical'
    send_resolved: true
    client: 'Alertmanager'
    client_url: 'https://alertmanager.kertenkerem.net'
    description: "{{ .CommonAnnotations.summary }} - Host: {{ .CommonLabels.instance }}"

Adım 3: PagerDuty Üzerinde Akıllı On-Call ve Eskalasyon Politikaları

Alertmanager entegrasyonunu tamamladıktan sonra topu pagerduty tarafına atıyoruz. PagerDuty üzerinde bir servis (Service) oluşturup entegrasyon tipini “Prometheus/Alertmanager” olarak seçtiğinizde size yukarıdaki YAML dosyasında kullandığımız service_key (Integration Key) değerini verecektir.

Ancak iş sadece entegrasyonla bitmiyor. Gerçek bir oncall kültüründe şu üç yapıyı kurmanız gerekir:

1. Schedules (Nöbet Takvimleri)

Haftalık rotasyonlar tanımlayın. Örneğin, her Salı günü saat 09:00’da nöbet bir sonraki mühendise devretsin. PagerDuty üzerinde Primary ve Secondary (yedek) olmak üzere iki farklı takvim oluşturmak hayat kurtarır. Eğer Primary nöbetçisi o an ulaşılamaz durumdaysa (örneğin uçaktaysa), sistem otomatik olarak yedek nöbetçiyi arar.

2. Escalation Policies (Eskalasyon Politikaları)

Alarmların sahipsiz kalmaması için eskalasyon zinciri şarttır. Örnek bir kurumsal politika şu şekilde olmalıdır:

• Adım 1: Alarm tetiklendiğinde o anki nöbetçiyi (Primary) ara ve SMS gönder. (0. dakika)
• Adım 2: Eğer 10 dakika içinde “Acknowledge” (onay) gelmezse, yedek nöbetçiyi (Secondary) ara. (10. dakika)
• Adım 3: Eğer hala ses çıkmıyorsa, tüm DevOps ekibine push notification at ve takım liderini devreye sok. (20. dakika)

3. Slack Entegrasyonu ve ChatOps

PagerDuty Slack uygulamasını kurarak, Slack kanalı üzerinden tek tıkla alarmı üstlenebilir (Acknowledge) veya çözebilirsiniz (Resolve). Bu, gece yarısı telefondan PagerDuty uygulamasına girmeye çalışırken harcayacağınız 30 saniyeyi size geri kazandırır.

Alert Fatigue (Alarm Yorgunluğu) ile Savaşmak

Sistemi kurduk ancak her gün 500 defa çalan bir pager sistemi, bir süre sonra mühendislerin uyarıları görmezden gelmesine (alert fatigue) sebep olur. Bunu engellemek için şu taktikleri uygulayın:

• Sadece aksiyon alınabilir alarmları PagerDuty’ye gönderin: “Disk doluluğu %81 oldu” bir PagerDuty alarmı değildir, sadece Slack’e gitmelidir. Ancak “Disk doluluğu %95 ve 10 dakika içinde tamamen dolacak” alarmı nöbetçiyi yataktan kaldırmalıdır.
• Inhibit Rules kullanın: Switch çöktüğünde arkasındaki 30 sunucu için tek tek “ping down” alarmı almamak için Alertmanager inhibit kurallarını tanımlayın.
• Susturma (Silences): Planlı bakım çalışmalarından önce Alertmanager veya PagerDuty arayüzünden ilgili servisleri mutlaka susturun (Silence).

Özet

Zabbix’in köklü izleme yeteneklerini Alertmanager’ın modern yönlendirme mimarisiyle birleştirmek, altyapı yönetiminde adeta çağ atlatır. Bu sayede hem production ortamınızdaki anomalileri saniyeler içinde yakalarsınız, hem de ekibinizin akıl sağlığını gereksiz gürültülü alarmlardan korumuş olursunuz.

Bir sonraki yazımızda Alertmanager üzerinde gelişmiş inhibit_rules yazımını inceleyeceğiz. O zamana kadar, alarmınız az, uykunuz bol olsun!