Zabbix’te Action ve Alarm Bildirimi Yapılandırma

Yazar:komut.io ekibi Zabbix ile Sunucu İzleme ve Yönetimi
0 Yorum

Zabbix kurulumu tamamlandı, host’lar eklendi, trigger’lar tanımlandı… Ve tam da bu noktada çoğu sistem yöneticisi “tamam, monitoring kuruldu” diyerek işi bitirilmiş sayar. Ama asıl iş burada başlıyor: bir şeyler patladığında sen nasıl haberdar olacaksın? Üç saat sonra dashboarda bakıp “aa disk dolmuş” demek izleme değil, geç kalmış tanıdır. Bu yazıda Zabbix’in Action ve Media Type mekanizmalarını gerçekten işe yarar hale getirmenin yolunu konuşacağız.

Kavramsal Çerçeve: Action Nedir, Ne Değildir?

Zabbix’te bir sorun tespit edildiğinde otomatik olarak ne yapılacağını Action tanımlar. E-posta göndermek, Telegram mesajı atmak, bir script çalıştırmak ya da başka bir host’ta remote command tetiklemek… Bunların hepsi Action kapsamındadır.

Action’ın çalışabilmesi için üç şeyin bir arada olması gerekir:

  • Trigger: Sorunun ne zaman başladığını ve bittiğini belirler
  • Media Type: Bildirimin hangi kanaldan gideceğini tanımlar (e-posta, webhook, SMS…)
  • Action: Hangi koşulda, kime, ne zaman bildirim gönderileceğini orkestre eder

Bu üçü birbirinden bağımsız yapılandırılır ve birbirine bağlanır. Çoğu zaman karışıklık bu ayrımı anlamamaktan kaynaklanır. “Action kurdum ama mail gitmiyor” diyenlerin yüzde sekseninde Media Type ya eksik yapılandırılmış ya da kullanıcıya atanmamıştır.

Media Type Yapılandırması

Önce bildirimin nasıl gideceğini tanımlayalım. Administration > Media Types altında Zabbix’in yerleşik media type’ları gelir. E-posta için SMTP ayarlarını yapmak gerekir.

E-posta Media Type Kurulumu

Administration > Media Types > Email seçeneğini açtığınızda karşınıza çıkan temel parametreler:

  • SMTP Server: Mail sunucunuzun adresi (örn: smtp.sirket.com.tr)
  • SMTP Server port: 587 (TLS için) veya 465 (SSL için)
  • SMTP helo: Genellikle sunucunuzun FQDN’i
  • SMTP email: Gönderici adresi ([email protected] gibi)
  • Connection security: TLS ya da SSL seçin, None’dan kaçının
  • Authentication: Username ve password ile

Test butonunu kullanmayı unutmayın. Kaydetmeden önce buradan gerçekten mail çıkıyor mu diye kontrol edin.

Webhook ile Telegram Entegrasyonu

E-posta göndermek 2024’te yeterli değil. On dakikada bir kontrol ettiğiniz bir mail kutusuna giden alarm bildiriminin pratik değeri sınırlı. Telegram entegrasyonu kurun, özellikle mobilde anlık bildirim için çok daha efektif.

Zabbix 6.x ile gelen yerleşik Telegram media type’ı oldukça kullanışlı. Administration > Media Types > Telegram açın.

Bot oluşturmak için önce @BotFather’a gidin ve /newbot komutu ile botunuzu oluşturun. Size bir token verecek. Bu token’ı media type yapılandırmasına girin.

Chat ID almak için botunuza bir mesaj gönderin, ardından şu URL’yi çağırın:

curl -s "https://api.telegram.org/bot<TOKEN>/getUpdates" | python3 -m json.tool | grep '"id"' | head -5

Grup bildirimi için botu gruba ekleyip aynı yöntemi kullanın, grup ID’leri negatif sayı olarak gelir.

Özel Script ile Media Type

Bazen yerleşik seçenekler yetmez. Slack’e özel format göndermek, şirket içi ticket sistemi oluşturmak ya da PagerDuty entegrasyonu kurmak istiyorsunuz diyelim. Bunun için Script tipi media type kullanırsınız.

mkdir -p /usr/lib/zabbix/alertscripts
chmod 755 /usr/lib/zabbix/alertscripts

Örnek bir Slack webhook script’i:

#!/bin/bash
# /usr/lib/zabbix/alertscripts/slack_notify.sh

TO="$1"
SUBJECT="$2"
MESSAGE="$3"

WEBHOOK_URL="https://hooks.slack.com/services/XXXX/YYYY/ZZZZ"

PAYLOAD=$(cat <<EOF
{
    "channel": "${TO}",
    "username": "Zabbix Alert",
    "icon_emoji": ":zap:",
    "attachments": [
        {
            "color": "danger",
            "title": "${SUBJECT}",
            "text": "${MESSAGE}",
            "footer": "Zabbix Monitoring",
            "ts": $(date +%s)
        }
    ]
}
EOF
)

curl -s -X POST -H 'Content-type: application/json' 
    --data "${PAYLOAD}" 
    "${WEBHOOK_URL}"
chmod +x /usr/lib/zabbix/alertscripts/slack_notify.sh

Script’i Administration > Media Types > Create Media Type ile tanımlayın. Type olarak Script seçin, script adını tam olarak dosya adıyla aynı girin. Parameters kısmına {ALERT.SENDTO}, {ALERT.SUBJECT}, {ALERT.MESSAGE} makrolarını sırayla ekleyin.

Kullanıcılara Media Ata

Media Type tanımlandı, peki kimler bildirim alacak? Bu adım sıkça atlanıyor.

Administration > Users altında ilgili kullanıcıyı açın, Media sekmesine geçin. Add diyerek:

  • Type: Az önce tanımladığınız media type
  • Send to: E-posta adresi, Telegram chat ID, Slack kanal adı…
  • When active: Hangi saatler arasında bildirim gelsin (1-7,00:00-24:00 tüm hafta demektir)
  • Use if severity: Hangi öncelik seviyelerinden bildirim gelsin

Mesai saatleri dışında sadece Critical ve Disaster seviyelerinde uyarmak için:

  • 1-5 günleri için 08:00-18:00 ile tüm severity’leri işaretleyin
  • 6-7 (hafta sonu) için ayrı bir media ekleyin, sadece Critical ve Disaster seçin

Bu ince ayarı yapmadan tüm izleme alarmlarını 7/24 almak yorgunluk yaratır ve alarm yorgunluğu gerçek sorunları gözden kaçırmanıza yol açar.

Action Oluşturma

Asıl işe geldik. Configuration > Actions > Trigger Actions > Create Action.

Action Conditions (Koşullar)

Burası en kritik kısım. Hangi durumlarda bu action çalışacak?

Örnek senaryo: Üretim ortamındaki sunucularda disk, CPU ya da bellek sorunu olduğunda nöbetçi ekibe bildirim gönder.

Condition Type: Trigger severity >= High
Condition Type: Host group = Production Servers
Condition Type: Trigger name contains "disk" OR "cpu" OR "memory"

Koşullar arasında AND/OR ilişkisini dikkatli kurun. Varsayılan olarak AND gelir, bazen OR’a çevirmeniz gerekir.

Action Operations (Bildirim Operasyonları)

Operations sekmesi altında ne yapılacağını tanımlarsınız.

Send message ile bildirim göndermek için:

  • Send to users: Kullanıcı veya kullanıcı grubu seçin
  • Send only to: Belirli bir media type seçebilirsiniz, boş bırakırsanız kullanıcının tüm media’larına gider
  • Default message: İşaretli bırakın ya da özel mesaj yazın
  • Step: Kaçıncı adım (escalation için kullanılır)
  • Duration: Bu adımın kaç saniye/dakika geçerli olacağı

Escalation Senaryosu

Gerçek dünyada çokça kullanılan bir yapı: Alarm geldi, 15 dakika kimse müdahale etmedi, ikinci kişiyi de uyar. 30 dakika geçti hâlâ çözülmedi, müdür de haberdar olsun.

Step 1: Duration 0 (hemen)
  -> Junior admin'e Telegram gönder

Step 2: Duration 900 saniye (15 dk sonra, sorun hâlâ devam ediyorsa)
  -> Senior admin'e Telegram + e-posta gönder

Step 3: Duration 1800 saniye (30 dk sonra)
  -> Tüm nöbet grubuna e-posta gönder

Her adımı ayrı Operation olarak eklersiniz, Duration değerleri bir sonraki adıma geçiş süresini belirtir. Step from ve Step to alanlarıyla hangi adım aralığında çalışacağını belirtin.

Recovery Operations

Sorun çözüldüğünde de bildirim gelmesini ister misiniz? Evet istersiniz. “Alarm düzeldi” bildirimi gelmeden kimse rahatlayamaz.

Recovery Operations sekmesine geçin, aynı şekilde Send message ekleyin. Burada message template farklı olacak çünkü konu artık “sorun bitti” mesajı.

Varsayılan recovery mesajı yeterli olabilir ama özelleştirmek isteyebilirsiniz:

Subject: [RESOLVED] {TRIGGER.NAME} on {HOST.NAME}

Sorun çözüldü.

Host: {HOST.NAME} ({HOST.IP})
Trigger: {TRIGGER.NAME}
Severity: {TRIGGER.SEVERITY}
Başlangıç: {EVENT.DATE} {EVENT.TIME}
Çözüm: {EVENT.RECOVERY.DATE} {EVENT.RECOVERY.TIME}
Süre: {EVENT.DURATION}

Acknowledgment Operations

Bir operatör problemi acknowledge (onayladı) ettiğinde de bildirim tetiklenebilir. Bu özellikle nöbet süreçlerinde “evet, aldım, bakıyorum” mesajını takıma iletmek için kullanışlıdır. Acknowledge Operations sekmesinden yapılandırabilirsiniz.

Mesaj Şablonlarını Özelleştirme

Varsayılan mesaj şablonları yeterince bilgi verse de pratik değil. Bir alarm geldiğinde şunları hemen görmek istersiniz: hangi host, hangi IP, ne sorun var, severity nedir, ne zamandan beri devam ediyor.

Administration > Media Types içinde ilgili media type’ı açın, Message Templates sekmesine bakın. Problem, Recovery ve Update için ayrı şablonlar tanımlayabilirsiniz.

Kullanışlı bir e-posta şablonu:

Subject: [{TRIGGER.SEVERITY}] {TRIGGER.NAME} - {HOST.NAME}

=== ALARM BİLDİRİMİ ===

Durum    : {TRIGGER.STATUS}
Sunucu   : {HOST.NAME}
IP       : {HOST.IP}
Trigger  : {TRIGGER.NAME}
Severity : {TRIGGER.SEVERITY}
Tarih    : {EVENT.DATE} {EVENT.TIME}

Problem Açıklaması:
{TRIGGER.DESCRIPTION}

Son Değer:
{ITEM.VALUE}

Zabbix'te görüntüle:
{TRIGGER.URL}
{$ZABBIX.URL}/tr_events.php?triggerid={TRIGGER.ID}

---
Bu mesaj otomatik olarak oluşturulmuştur.
Zabbix Monitoring - {HOST.HOST}

Telegram için daha kısa ve okunabilir bir format:

{TRIGGER.STATUS}: {TRIGGER.NAME}

Host: {HOST.NAME} ({HOST.IP})
Severity: {TRIGGER.SEVERITY}
Time: {EVENT.DATE} {EVENT.TIME}
Value: {ITEM.VALUE}

{$ZABBIX.URL}/tr_events.php?triggerid={TRIGGER.ID}

Zabbix API ile Action Yönetimi

Onlarca ortam yönetiyorsanız UI üzerinden tek tek action oluşturmak yerine API’yi kullanın. Özellikle aynı konfigürasyonu farklı Zabbix instance’larına uygulamak gerektiğinde hayat kurtarıcı.

Önce API token alın:

curl -s -X POST 
  -H "Content-Type: application/json" 
  -d '{
    "jsonrpc": "2.0",
    "method": "user.login",
    "params": {
      "username": "Admin",
      "password": "zabbix"
    },
    "id": 1
  }' 
  http://zabbix.sirket.com.tr/api_jsonrpc.php

Mevcut action listesini çekin:

curl -s -X POST 
  -H "Content-Type: application/json" 
  -d '{
    "jsonrpc": "2.0",
    "method": "action.get",
    "params": {
      "output": ["actionid", "name", "status"],
      "eventsource": 0
    },
    "auth": "TOKEN_BURAYA",
    "id": 2
  }' 
  http://zabbix.sirket.com.tr/api_jsonrpc.php | python3 -m json.tool

Yeni action oluşturmak için action.create metodunu kullanırsınız. Mevcut bir action’ı JSON olarak export edip üzerinden template oluşturmak en pratik yaklaşım.

Sık Karşılaşılan Sorunlar ve Çözümleri

“Action kurdum ama bildirim gelmiyor”

Kontrol listesi:

  • Kullanıcıya Media Type atanmış mı? (Administration > Users > Media)
  • Media Type’ın kendisi enabled mı?
  • Action’ın status’u Enabled mi?
  • Trigger gerçekten ateşlendi mi? (Monitoring > Problems ekranına bakın)
  • Zabbix server log’larına bakın: /var/log/zabbix/zabbix_server.log
tail -f /var/log/zabbix/zabbix_server.log | grep -i "alert|action|media"

“Test mesajı gidiyor ama gerçek alarm gitmiyor”

Bu klasik bir durumdur. Media Type test butonu doğrudan gönderim yapar, Action üzerinden geçmez. Action’ın koşullarını tekrar gözden geçirin. Trigger severity eşiğini kontrol edin, belki alarm “Warning” seviyesinde tetikleniyordur ama Action sadece “High” ve üzeri için yapılandırılmıştır.

“Çok fazla bildirim geliyor, spam gibi”

İki çözüm var: ya trigger’larınızın hysteresis değerlerini düzeltin ya da Action’da Multiple PROBLEM events yerine Problem event seçeneğini kullanın. Ayrıca maintenance window tanımlayın, planlı bakım saatlerinde alarm gelmesin.

“Escalation çalışmıyor”

Step Duration değerlerini saniye cinsinden girdiğinizden emin olun. 15 dakika için 900 yazın. Ayrıca problem acknowledge edilmişse escalation durur. Bu davranışı değiştirmek için Action’da Pause operations for suppressed problems ayarına bakın.

Maintenance Window ile Alarm Yönetimi

Planlı bakımlarda gereksiz alarm üretmemek için maintenance window kullanın. Configuration > Maintenance > Create Maintenance.

  • Name: Açıklayıcı bir isim (örn: “DB Sunucu Haftalık Yedek – Cumartesi”)
  • Active since/till: Maintenance’ın geçerli olduğu tarih aralığı
  • Periods: Periyodik bakım için haftalık, aylık dönemler tanımlayabilirsiniz
  • Hosts/Groups: Hangi host’ların bu maintenance kapsamında olduğu

Maintenance sırasında trigger’lar ateşlenir ama Action çalışmaz. Yani alarmlar kaybolmaz, sadece bildirim gitmez. Bakım bittikten sonra Monitoring > Problems üzerinden kontrol edebilirsiniz.

Remote Command ile Otomatik Müdahale

Action’lar sadece bildirim göndermekle sınırlı değil, Remote Command ile problemlere otomatik müdahale de edebilirsiniz.

Örneğin bir servis durduğunda otomatik restart denemesi:

# Zabbix agent'ın sudoers'a eklenmesi gerekir
echo "zabbix ALL=(ALL) NOPASSWD: /bin/systemctl restart nginx" >> /etc/sudoers.d/zabbix

Action’da Operation olarak Run remote commands seçin, Execute on: Zabbix agent seçin:

sudo systemctl restart nginx
sleep 5
systemctl is-active nginx && echo "Servis yeniden başlatıldı" || echo "Servis başlatılamadı"

Dikkat: Remote command’ları dikkatli kullanın. Yanlış yapılandırılmış bir otomatik restart komutu sorunlu bir servisi sürekli restart ederek log’ları doldurup asıl sorunu gizleyebilir. Bu özelliği üretim ortamında kullanmadan önce kapsamlı test edin ve komutu bir log dosyasına kaydedin.

Sonuç

Zabbix’te Action ve alarm bildirimi yapılandırması tek seferlik bir iş değil. Ortamınız değiştikçe, ekip büyüdükçe ve gereksinimler olgunlaştıkça bu yapılandırmaları güncellemeniz gerekecek. “Alarm geldi mi?” sorusundan “doğru alarm, doğru kişiye, doğru zamanda ulaştı mı?” sorusuna geçmek izleme olgunluğunun işaretidir.

Başlangıç için önerilen yol: önce e-posta bildirimleri düzgün çalışır hale getirin, sonra Telegram veya Slack entegrasyonu ekleyin, ardından escalation senaryolarını kurgulayın. Her değişiklikten sonra gerçek bir test yapın, yani bir trigger’ı elle tetikleyin veya geçici olarak eşiği düşürün ve alarm zincirinin uçtan uca çalıştığını doğrulayın.

En iyi izleme sistemi, bir şey patladığında sizi ilk haberdar eden sistemdir. Bunu başarabiliyorsanız Action yapılandırmanız doğru kurulmuş demektir.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir