Zabbix’te Item ve Trigger Oluşturma: Adım Adım Rehber

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

Zabbix kurulumunu tamamladınız, agent’lar çalışıyor, host’lar eklendi. Ama dashboard’a bakıyorsunuz ve hiçbir şey izlenmiyor. İşte asıl iş burada başlıyor. Item ve trigger kavramlarını tam anlamıyla özümsemeden Zabbix’i kullanmak, pahalı bir alarm saatini sadece saat olarak kullanmaya benzer. Bu yazıda sıfırdan item oluşturmayı, trigger mantığını ve bunları birbirine bağlayan expression yapısını gerçek senaryolarla ele alacağız.

Item Nedir, Neden Önemlidir?

Item, Zabbix’in bir host’tan topladığı tek bir veri noktasıdır. CPU kullanımı, disk I/O, bir servisin çalışıp çalışmadığı, hatta bir web sayfasının cevap süresi, bunların hepsi birer item’dır. Trigger ise bu item’lardan gelen veriyi değerlendiren mantık katmanıdır.

Çoğu sysadmin’in yaptığı hata şu: Template’lerden gelen item’larla yetinip özel senaryolar için item yazmamak. Üretim ortamında mutlaka ihtiyaç duyacağınız, template’lerde bulunmayan onlarca özel metrik olacak. Bir uygulama logundaki hata sayısı, özel bir script’in çıktısı, veritabanı bağlantı havuzunun doluluk oranı gibi.

Zabbix Agent ile Basit Bir Item Oluşturmak

Önce en temel senaryodan başlayalım. Bir Linux sunucusunda belirli bir kullanıcı process’lerinin sayısını izleyelim.

Zabbix web arayüzünde Configuration > Hosts altında ilgili host’a tıklayın, Items sekmesine girin ve Create item butonuna basın.

Temel alanlar şunlar:

  • Name: Human-readable isim. Örneğin “Apache process count”
  • Type: Nasıl veri toplayacağınızı belirler. Zabbix agent, SNMP, HTTP agent, calculated item gibi seçenekler var
  • Key: Agent’a ne sorulacağını tanımlar
  • Type of information: Numeric, text, log gibi veri tipi
  • Update interval: Ne sıklıkla toplanacak

Apache process sayısı için key şöyle olur:

proc.num[apache2,,running]

Bu key doğrudan agent tarafından işlenir. Parametreler:

  • proc.num[name,user,state,cmdline]: Parametre sırası bu şekildedir
  • name: Process adı
  • user: Hangi kullanıcı altında çalıştığı (boş bırakılabilir)
  • state: running, sleeping, zombie gibi durumlar

Agent tarafında bu key’in çalışıp çalışmadığını test etmek için:

zabbix_agentd -t "proc.num[apache2,,running]"

Çıktı şuna benzer bir şey vermeli:

proc.num[apache2,,running]                    [u|3]

u unsigned integer anlamına gelir, 3 ise şu an çalışan apache2 process sayısıdır.

UserParameter ile Özel Item Tanımlamak

Standart Zabbix agent key’leri çoğu zaman yeterli gelmez. Kendi metriklerinizi toplamak için UserParameter direktifini kullanırsınız. Bu, Zabbix’in en güçlü özelliklerinden biridir.

Senaryomuz şu: Bir MySQL replikasyon ortamında, slave’in master’dan kaç saniye geride olduğunu izlemek istiyoruz.

Agent konfigürasyon dosyasına (/etc/zabbix/zabbix_agentd.conf veya /etc/zabbix/zabbix_agentd.d/ altına yeni bir .conf dosyası olarak) şunu ekleyin:

UserParameter=mysql.slave.lag,mysql -u zabbix -pZabbixPass123 -e "SHOW SLAVE STATUSG" 2>/dev/null | grep "Seconds_Behind_Master" | awk '{print $2}' | tr -d 'n'

Bu tanımı ekledikten sonra agent’ı restart edin:

systemctl restart zabbix-agent

Test:

zabbix_agentd -t "mysql.slave.lag"

Eğer slave sağlıklıysa 0 veya küçük bir sayı, sorun varsa büyük bir değer ya da NULL döner.

Zabbix web arayüzünde bu item için:

  • Key: mysql.slave.lag
  • Type: Zabbix agent
  • Type of information: Numeric (unsigned)
  • Update interval: 60s (replikasyon gecikmesi için dakikada bir kontrol makul)

Parametreli UserParameter Tanımlamak

Tek bir script ile birden fazla metrik toplamak istediğinizde parametreli yapı kullanılır. Örneğin farklı disk partition’ları için custom metrikler:

UserParameter=custom.disk.health[*],/usr/local/bin/disk_health_check.sh $1

[*] ifadesi bu key’in parametre kabul ettiğini belirtir. Script içeriği:

#!/bin/bash
# /usr/local/bin/disk_health_check.sh

PARTITION=$1

if [ -z "$PARTITION" ]; then
    echo "0"
    exit 1
fi

# Disk kullanim yuzdesi
USAGE=$(df -h "$PARTITION" | awk 'NR==2 {gsub(/%/,""); print $5}')
echo "$USAGE"
chmod +x /usr/local/bin/disk_health_check.sh

Zabbix’te bu item’ı kullanırken key şöyle yazılır:

  • /var partition için: custom.disk.health[/var]
  • /home için: custom.disk.health[/home]

Aynı item tanımı farklı parametrelerle birden fazla item oluşturmak için kullanılabilir. Bu yaklaşım template’ler yazarken çok işe yarar.

Calculated Item ile Türetilmiş Metrik Oluşturmak

Bazen var olan item’lardan matematik yaparak yeni bir metrik üretmek gerekir. Zabbix’in Calculated item tipi tam bunun için.

Örnek senaryo: Toplam bellek ile kullanılabilir belleği ayrı ayrı izliyorsunuz, ama bellek kullanım yüzdesini de görmek istiyorsunuz.

Önce iki standart item olduğunu varsayalım:

  • vm.memory.size[total] – Toplam RAM (bytes cinsinden)
  • vm.memory.size[available] – Kullanılabilir RAM

Şimdi yüzde hesaplayan bir calculated item oluşturun:

  • Type: Calculated
  • Key: custom.memory.usage.percent
  • Formula:
(last("vm.memory.size[total]") - last("vm.memory.size[available]")) / last("vm.memory.size[total]") * 100

Bu formülde last() fonksiyonu ilgili item’ın en son değerini getirir. Zabbix’in calculated item’larında kullanabileceğiniz başka fonksiyonlar da var: avg(), max(), min(), sum() gibi.

Trigger Oluşturma ve Expression Mantığı

Item’lar veriyi toplar, trigger’lar bu veriyi yorumlar ve alarm üretir. Trigger yazımı, Zabbix’te en çok kafa karıştıran konuların başında gelir.

Configuration > Hosts > Triggers > Create trigger yolunu izleyin.

Temel alanlar:

  • Name: Alarmın adı, bu metin bildirim mesajlarında görünür
  • Expression: Hangi koşulda tetikleneceğini tanımlayan mantık ifadesi
  • Severity: Information, Warning, Average, High, Disaster
  • Problem expression / Recovery expression: 6.x ve üzeri sürümlerde alarm açılış ve kapanış koşulları ayrı tanımlanabiliyor

Basit Bir Trigger Expression Yazmak

Apache process’lerinin hiç çalışmaması durumu için:

last(/YourHostName/proc.num[apache2,,running])=0

Bu expression şunu söylüyor: “YourHostName adlı host’ta proc.num[apache2,,running] item’ının son değeri 0’a eşitse, bu trigger tetiklensin.”

MySQL slave gecikmesi için daha karmaşık bir örnek:

last(/db-server-01/mysql.slave.lag)>30

Yani slave 30 saniyeden fazla gerideyse alarm ver.

Hysteresis ile Alarm Titremesini Önlemek

Gerçek ortamda sık karşılaşılan sorun şu: Bir değer alarm eşiğinin üzerinde ve altında sürekli gidip geliyor, bu da onlarca alarm ve recovery mesajı üretiyor. Buna “flapping” denir.

Bunu çözmek için ayrı bir recovery expression kullanın:

Problem expression:

last(/web-server-01/custom.memory.usage.percent)>90

Recovery expression:

last(/web-server-01/custom.memory.usage.percent)<85

Bu sayede alarm %90’da açılır, ama ancak %85’in altına indiğinde kapanır. Arada kalan değerlerde alarm durumunu korur, gereksiz titreme olmaz.

Çoklu Koşulla Trigger Yazmak

Bazen tek bir koşul yeterli değildir. Hem yüksek CPU hem de yüksek bellek kullanımı aynı anda varsa alarm vermek isteyebilirsiniz. and / or operatörleri kullanılır:

last(/app-server-01/system.cpu.util[,idle])<20 and last(/app-server-01/custom.memory.usage.percent)>95

Bu trigger, CPU idle’ı %20’nin altına düştüğünde ve bellek kullanımı %95’in üzerine çıktığında tetiklenir.

min() ve max() Fonksiyonlarıyla Daha Akıllı Trigger’lar

last() fonksiyonu sadece son değere bakar, bu çoğu zaman yeterli değildir. Anlık spike’lar gereksiz alarm üretebilir. Son 5 dakikanın ortalamasına veya maksimumuna bakın:

avg(/app-server-01/system.cpu.util[,idle],5m)<20

Veya son 3 ölçümün hepsinde de yüksek disk kullanımı varsa alarm ver:

min(/storage-01/custom.disk.health[/var],#3)>85

#3 ifadesi “son 3 değer” anlamına gelir. Bu sayede geçici yükselmeleri görmezden gelip, kalıcı sorunlarda alarm üretirsiniz.

Bir Arada Çalışan Tam Senaryo

Şimdi gerçek hayattan bir senaryoyu uçtan uca yazalım. Uygulama sunucusunda bir Java servisinin hem process olarak çalışıp çalışmadığını, hem de açtığı port’u dinleyip dinlemediğini izleyelim.

Adım 1: Agent Konfigürasyonu

# /etc/zabbix/zabbix_agentd.d/java-app.conf

UserParameter=java.app.process,pgrep -f "myapp.jar" | wc -l | tr -d ' '
UserParameter=java.app.port,ss -tlnp | grep -c ":8080"
systemctl restart zabbix-agent

Adım 2: Item’ları Test Et

zabbix_agentd -t "java.app.process"
zabbix_agentd -t "java.app.port"

Beklenen çıktı her ikisi için de 1 olmalı.

Adım 3: Zabbix’te Item’ları Oluştur

İlk item:

  • Name: Java App – Process Running
  • Key: java.app.process
  • Type of information: Numeric (unsigned)
  • Update interval: 60s

İkinci item:

  • Name: Java App – Port 8080 Listening
  • Key: java.app.port
  • Type of information: Numeric (unsigned)
  • Update interval: 60s

Adım 4: Trigger’ları Yaz

Process trigger’ı (Severity: High):

last(/app-server-01/java.app.process)=0

Port trigger’ı (Severity: Disaster, çünkü process çalışıyor ama port dinlenmiyorsa ciddi sorun):

last(/app-server-01/java.app.port)=0 and last(/app-server-01/java.app.process)>0

İkinci trigger, process çalışıyor ama port kapalıysa alarm verir. Bu, uygulamanın başlamış ama crash etmiş ya da port bind edememiş durumunu yakalar.

Trigger Dependencies ile Alarm Gürültüsünü Azaltmak

Bir sunucu tamamen down olduğunda, o sunucudaki tüm trigger’lar aynı anda patlayabilir. 50 item izliyorsanız 50 alarm alırsınız. Oysa asıl sorun sunucunun erişilemez olmasıdır.

Bunu trigger dependency ile çözersiniz. Önce “host unreachable” trigger’ına dependency ekleyin:

  • Java App Process trigger’ının Dependencies sekmesine gidin
  • “Add” ile Zabbix agent on app-server-01 is unreachable trigger’ını bağlayın

Artık sunucu erişilemezse, Java process trigger’ı tetiklense bile bildirim gönderilmez. Sadece master alarm çalar.

Zabbix Sender ile Dışarıdan Item Doldurmak

Bazen agent’ın çalıştığı sunucudan değil, dışarıdan veri göndermek gerekir. Örneğin bir backup job’ının başarılı olup olmadığını Zabbix’e bildirmek istiyorsunuz.

Önce Zabbix’te bir Zabbix trapper tipinde item oluşturun:

  • Type: Zabbix trapper
  • Key: backup.job.status
  • Type of information: Numeric (unsigned)

Sonra backup script’inizin sonuna şunu ekleyin:

#!/bin/bash

# Backup islemi
/usr/local/bin/backup.sh

if [ $? -eq 0 ]; then
    STATUS=1
    echo "Backup basarili"
else
    STATUS=0
    echo "Backup BASARISIZ"
fi

# Zabbix'e gonder
zabbix_sender -z zabbix-server-ip -p 10051 -s "backup-server-01" -k "backup.job.status" -o "$STATUS"

Trigger:

last(/backup-server-01/backup.job.status)=0

Bu yaklaşım, scheduled job’ların izlenmesinde çok kullanışlıdır. Agent pull modeli yerine job kendisi Zabbix’e push eder.

Item Prototype ile Dinamik İzleme

Son olarak, Low Level Discovery ile birlikte kullanılan item prototype konusuna değinelim. Disk partition’larını manuel tek tek eklemek yerine LLD otomatik keşfeder.

Discovery rule tanımlanmış olduğunu varsayarak (vfs.fs.discovery key’i ile), item prototype şöyle oluşturulur:

  • Key: vfs.fs.size[{#FSNAME},pused]
  • Name: Disk usage on {#FSNAME}

{#FSNAME} makrosu, discovery edilen her partition için otomatik genişler. /, /var, /home, /data gibi tüm partition’lar için ayrı item oluşturulur.

Trigger prototype da benzer şekilde:

last(/YourHost/vfs.fs.size[{#FSNAME},pused])>90

Bu sayede yeni bir disk partition eklendiğinde, Zabbix bunu otomatik keşfeder ve izlemeye başlar.

Sonuç

Item ve trigger mekanizmasını kavramak, Zabbix’te gerçek anlamda etkili bir izleme altyapısı kurmanın temelini oluşturur. UserParameter ile neredeyse sınırsız özelleştirme yapabilirsiniz. Trigger expression’larında last(), avg(), min(), max() fonksiyonlarını ve zaman/sayı tabanlı pencere ifadelerini kullanarak akıllı alarmlar yazabilirsiniz.

Recovery expression ve trigger dependency konuları, alarm fatigue yani alarm yorgunluğunu önlemede kritik rol oynar. Onlarca yanlış alarm alan bir ekip zamanla alarmları görmezden gelmeye başlar, bu da asıl kritik olayların gözden kaçmasına yol açar.

Şunu da söyleyeyim: Item ve trigger yazmak teknik bildiğiniz kadar deneyim isteyen bir iştir. Bir threshold’u çok sıkı koyarsanız gereksiz alarm boğulursunuz, çok gevşek koyarsanız sorunları geç fark edersiniz. İlk kurulumda mükemmel olmayacak, zamanla üretim verisine bakarak ayarlayacaksınız. Zabbix’teki en değerli trigger’lar, aylar içinde iyileştirilerek olgunlaşmış olanlardır.

Bir yanıt yazın

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