Zabbix LLD ile Dinamik Altyapı İzleme: SRE El Kitabı
Modern karmaşık altyapılarda monitoring süreçlerini otomatize etmek artık bir lüks değil; zabbix üzerinde lld (Low-Level Discovery) kullanarak dinamik sunucu ve servis keşfi yapmak ise bu otomasyon sürecinin tam kalbinde yer alıyor. YAML dosyaları arasında kaybolduğumuz, Kubernetes cluster’larının her saniye pod döküp topladığı bir dünyada, kimsenin Zabbix arayüzüne girip elle host ekleyecek, yeni bir disk mount edildiğinde onun için manuel item tanımlayacak vakti yok. Eğer hala “Yeni makine geldi, IP’sini Zabbix’e ekleyelim” diyorsanız, bu makale operasyonel yükünüzü sıfıra indirmek için yazıldı.
Neden Standart Discovery Değil de LLD?
Zabbix kullanan ekiplerin sıklıkla düştüğü ilk hata, Network Discovery ile Low-Level Discovery (LLD) kavramlarını karıştırmaktır. Network Discovery, belirli IP bloklarını tarayıp “Burada bir cihaz var, işletim sistemi de Linux” der ve host’u sisteme ekler. Ancak o host’un içine girdikten sonra işler değişir.
LLD ise bir host’un mikroskobik anatomisini dinamik olarak çıkartır. Sunucuda o an çalışan Docker container’larını, mount edilmiş disk partition’larını, aktif dinlenen TCP portlarını veya dinamik olarak ayağa kalkan systemd servislerini otomatik olarak tespit eder. LLD’nin arkasındaki sihirli güç JSON formatıdır. Zabbix Agent veya bir external script, Zabbix Server’a standardize edilmiş bir JSON döndürür; Server ise bu JSON’ı parse ederek dinamik prototiplerden gerçek Item, Trigger ve Graph’lar üretir.
Uygulama Senaryosu: Dinamik Mikroservis Port Keşfi
Geliştirme ekibinin her hafta yeni bir mikroservis deploy ettiği, her servisin rastgele (veya belirli bir pattern’e sahip) portlardan ayağa kalktığı bir senaryoyu ele alalım. Amacımız: Sunucuda dinlenen dynamic portları keşfetmek, bunları izlemek ve port kapandığında alarm üretmek.
Adım 1: Custom LLD Scripti Yazımı
Öncelikle hedef sunucuda çalışacak ve dinlenen portları Zabbix’in anlayacağı LLD formatında (JSON) döndürecek bir Bash scriptine ihtiyacımız var. Zabbix 5.0 ve üzeri sürümler artık flat JSON formatını da destekliyor, ancak biz geriye dönük uyumluluk ve standart olması açısından klasik LLD macro array formatını kullanacağız.
Aşağıdaki scripti hedef sunucuda /etc/zabbix/scripts/discover_ports.sh yoluna kaydedelim:
#!/bin/bash
# Dinlenmekte olan 8000-9000 arasındaki portları bulalım (mikroservis port aralığı)
PORTS=$(netstat -tlnp | awk '{print $4}' | grep -o '[0-9]*$' | sort -u | awk '$1>=8000 && $1<=9000')
echo "{"
echo " \"data\": ["
FIRST=1
for PORT in $PORTS; do
# Servis adını systemd veya prosesten çekmeye çalışalım
SERVICE_NAME=$(ss -tlnp | grep ":$PORT " | awk -F'pid=' '{print $2}' | cut -d, -f1 | tr -d '"')
if [ -z "$SERVICE_NAME" ]; then
SERVICE_NAME="unknown-service"
fi
if [ $FIRST -ne 1 ]; then
echo ","
fi
echo " {"
echo " \"{#MICROSERVICE_PORT}\": \"$PORT\","
echo " \"{#MICROSERVICE_NAME}\": \"$SERVICE_NAME\""
echo " }"
FIRST=0
done
echo " ]"
echo "}"Bu scriptin çıktısı tam olarak aşağıdaki gibi bir JSON olmalıdır. Zabbix LLD motoru, anahtar kelime olarak süslü parantez ve diyez ile başlayan makroları ({#MACRO}) arar:
{
"data": [
{
"{#MICROSERVICE_PORT}": "8081",
"{#MICROSERVICE_NAME}": "auth-service"
},
{
"{#MICROSERVICE_PORT}": "8085",
"{#MICROSERVICE_NAME}": "payment-service"
}
]
}Adım 2: UserParameter Tanımlama
Zabbix Agent’ın bu scripti çalıştırıp çıktıyı sunucuya gönderebilmesi için yetkilendirilmesi gerekir. /etc/zabbix/zabbix_agentd.d/userparameter_services.conf dosyasını oluşturup şu satırı ekliyoruz:
UserParameter=custom.microservice.discovery,sudo /etc/zabbix/scripts/discover_ports.shBurada kritik bir detay var: Script netstat ve ss komutlarını kullandığı için proses isimlerini okurken root yetkisine ihtiyaç duyabilir. Bu yüzden /etc/sudoers dosyasına zabbix kullanıcısı için şifresiz çalıştırma izni eklemeyi unutmayın:
zabbix ALL=(ALL) NOPASSWD: /etc/zabbix/scripts/discover_ports.shKonfigürasyonu yaptıktan sonra agent servisini restart ediyoruz:
systemctl restart zabbix-agentZabbix Arayüzünde Template ve LLD Yapılandırması
Artık altyapıyı hazırladığımıza göre, Zabbix Server tarafında bu veriyi işleyecek kuralları tanımlayabiliriz.
Discovery Rule Oluşturma
- Zabbix Web UI’da Configuration > Templates sekmesine gidin ve yeni bir template oluşturun (Örn:
Template App Microservices Dynamic). - Oluşturduğunuz template’in içindeki Discovery rules sekmesine tıklayın ve Create discovery rule butonuna basın.
- Name: Microservice Port Discovery
- Type: Zabbix agent (veya zabbix agent active – mimarinize göre)
- Key:
custom.microservice.discovery - Update interval: 1h (Üretim ortamında her dakika keşif yapmak gereksiz yük bindirir, 1 saat veya duruma göre 15 dakika idealdir).
Item Prototiplerini Tanımlama
Discovery Rule oluştuktan sonra, bu kuralın altında Item prototypes sekmesine giriyoruz. Burada tanımlayacağımız her item, keşfedilen her port için otomatik olarak klonlanacak.
Create item prototype diyerek ilk prototipimizi oluşturalım:
- Name: Service {#MICROSERVICE_NAME} on Port {#MICROSERVICE_PORT} Status
- Key:
net.tcp.service[tcp,,{#MICROSERVICE_PORT}] - Type: Simple check (veya Agent üzerinden kontrol etmek için agent key’leri kullanabilirsiniz)
- Type of information: Numeric (unsigned)
Burada kritik nokta, Key alanında dinamik makromuz olan {#MICROSERVICE_PORT} ifadesini kullanmış olmamızdır. Zabbix her keşifte bu değeri gerçek port numarasıyla değiştirecektir.
Trigger Prototiplerini Tanımlama
Sadece izlemek yetmez, servis çöktüğünde alarm üretmeliyiz. Aynı Discovery Rule altındaki Trigger prototypes sekmesine gidiyoruz:
- Name: Microservice {#MICROSERVICE_NAME} on port {#MICROSERVICE_PORT} is DOWN
- Expression:
last(/Template App Microservices Dynamic/net.tcp.service[tcp,,{#MICROSERVICE_PORT}])=0 - Severity: Average (veya High)
Bu tanım sayesinde, örneğin 8085 portundaki `payment-service` çöktüğünde trigger otomatik olarak evaluate edilecek ve alarm başlığı dinamik olarak çözümlenerek “Microservice payment-service on port 8085 is DOWN” şeklinde Slack/PagerDuty entegrasyonlarınıza düşecektir.
SRE Gözünden LLD Optimizasyonları ve Best Practice’ler
Büyük ölçekli ortamlarda (10.000+ host, 500.000+ item) LLD kullanırken dikkat edilmezse Zabbix Server database’i ve LLD housekeeper süreçleri darboğaza girebilir. Aşağıdaki optimizasyonları mutlaka dikkate alın:
1. Discard Unchanged (Throttling) Kullanın
Keşif scriptiniz her çalıştığında aynı JSON çıktısını üretiyorsa, Zabbix Server’ın her seferinde bu veriyi veritabanına yazıp işlem yapmasına gerek yoktur. Discovery Rule konfigürasyonundaki Preprocessing sekmesine gidin ve Discard unchanged with heartbeat ekleyin. Heartbeat süresini 12h veya 24h yapın. Bu, DB write I/O oranınızı dramatik ölçüde düşürür.
2. Keep Lost Resources Period Ayarı
Bir mikroservis kapatıldığında veya taşındığında, ona ait eski item ve trigger verilerinin ne kadar süre sistemde kalacağını belirleyen parametre LLD rule içindeki Keep lost resources period seçeneğidir. Varsayılan olarak 30 gündür. Dinamik ortamlarda bu değeri 1d (1 gün) veya 12h gibi düşük sürelere çekin. Aksi takdirde, artık var olmayan yüzlerce geçici portun “Unknown” statüsündeki çöpleriyle uğraşırsınız.
3. Filtreleri Doğru Kullanın
Scriptinizden gelen tüm verileri izlemek istemeyebilirsiniz. LLD kuralındaki Filters sekmesini kullanarak sadece belirli pattern’e uyan makroları işleme alabilirsiniz. Örneğin, sadece {#MICROSERVICE_NAME} değeri “prod-” ile başlayanları izlemek için regex filtresi koyabilirsiniz:
{#MICROSERVICE_NAME} matches ^prod-.*Özet
Zabbix LLD, altyapınızın dinamik yapısına ayak uydurabilen, kendi kendini temizleyen ve sürekli güncel kalan bir monitoring katmanı kurmanın en efektif yoludur. Statik template mantığından çıkıp, veriyi doğrudan kaynaktan (OS, API, Docker socket) çekerek otomatik kural setleri türetmek, SRE ekiplerinin operasyonel yükünü minimize eder. Bir sonraki aşamada bu LLD mekanizmasını Kubernetes API’si ile entegre ederek cluster dışındaki Zabbix cluster’ınızdan pod seviyesinde keşifler tetikleyebilirsiniz.
