Ekim 17 2025

Zabbix LLD ve Host Prototypes ile Dinamik Altyapı İzleme

Modern altyapılarda monitoring süreçlerini ölçeklemek, her gün onlarca microservice’in veya sanal makinenin ayağa kalkıp kapandığı dinamik ortamlarda statik konfigürasyonlarla tam bir kabustur. İşte bu noktada zabbix üzerinde otomasyon gücünü sonuna kadar kullanmamızı sağlayan lld (Low-Level Discovery) ve dinamik host discovery mekanizmaları devreye giriyor. Bu makalede, klasikleşmiş disk veya network arayüzü keşfinin ötesine geçerek; dinamik hedef sunucuları, AWS EC2 instance’larını veya Kubernetes pod’larını birer “Host Prototype” kullanarak Zabbix’e nasıl dinamik host olarak ekleyeceğimizi ele alacağız.

Neden Doğrudan API Değil de LLD ve Host Prototypes?

SRE dünyasında sıklıkla yapılan hatalardan biri, yeni bir sunucu ayağa kalktığında bir CI/CD pipeline’ı veya Ansible playbook’u üzerinden Zabbix API’sine istek atarak host oluşturmaktır. Peki bu yaklaşım neden sürdürülebilir değil?

State Senkronizasyonu: Sunucu kapandığında veya silindiğinde, onu Zabbix’ten silecek mekanizmayı da yönetmeniz gerekir. Aksi takdirde “ghost” host’larla dolu bir monitoring çöplüğünüz olur.
Rate Limiting ve Ağ Kesintileri: Provisioning sırasında Zabbix API’sine erişilemezse, o sunucu asla izlenemez.
Yetkilendirme Sınırları: Pipeline’lara yüksek yetkili Zabbix API token’ları dağıtmak ciddi bir güvenlik riski barındırır.

LLD tabanlı Host Prototypes kullandığımızda ise Zabbix, belirlediğimiz periyotlarda kaynağı (source of truth) sorgular; yeni gelenleri ekler, silinenleri ise “Keep lost resources period” parametresine göre otomatik olarak sistemden temizler. Yani state yönetimi tamamen Zabbix’in kendi engine’ine bırakılır.

Adım 1: Keşif Betiğini (Discovery Script) Hazırlamak

Zabbix LLD mekanizmasının çalışması için tek bir kural vardır: Geriye mutlaka belirli bir JSON formatı dönülmelidir. Geleneksel formatta {"data": [...]} yapısı kullanılsa da modern Zabbix versiyonlarında doğrudan bir JSON array dönmek yeterlidir. Makroların ise {#MACRO_ADI} formatında olması zorunludur.

Senaryomuzda, bir cloud provider veya internal API üzerinden aktif sanal makineleri çeken bir Bash script yazalım. Bu script, dinamik olarak IP, Hostname ve kritik bir etiket (environment) bilgisi döndürecek.

#!/usr/bin/env bash
# /etc/zabbix/scripts/discover_vms.sh

# Gerçek senaryoda burası bir AWS CLI, Consul veya k8s API çağrısı olabilir.
# Simülasyon amaçlı statik ama dinamik formatta bir JSON üretiyoruz.

cat <<EOF
[
  {
    "{#VM.UUID}": "i-091a2b3c4d5e6f7g8",
    "{#VM.NAME}": "prod-api-node01",
    "{#VM.IP}": "10.100.20.14",
    "{#VM.ENV}": "Production"
  },
  {
    "{#VM.UUID}": "i-056x7y8z9w0v1u2t3",
    "{#VM.NAME}": "prod-worker-node02",
    "{#VM.IP}": "10.100.20.15",
    "{#VM.ENV}": "Production"
  },
  {
    "{#VM.UUID}": "i-012a3b4c5d6e7f8g9",
    "{#VM.NAME}": "stage-api-node01",
    "{#VM.IP}": "10.100.50.8",
    "{#VM.ENV}": "Staging"
  }
]
EOF

Scripti çalıştırılabilir kılmayı ve yetkilerini ayarlamayı unutmayın:

chmod +x /etc/zabbix/scripts/discover_vms.sh

Adım 2: UserParameter Tanımlama ve Ajan Konfigürasyonu

Zabbix Server veya Proxy’nin bu betiği tetikleyebilmesi için, betiğin çalıştığı makinedeki (bu genellikle bir yönetim sunucusu veya Zabbix Proxy’nin kendisidir) Zabbix Agent konfigürasyonuna bir UserParameter eklemeliyiz.

# /etc/zabbix/zabbix_agentd.d/custom_lld.conf

UserParameter=custom.vms.discovery,/etc/zabbix/scripts/discover_vms.sh

Değişikliğin aktif olması için agent servisini yeniden başlatıyoruz:

systemctl restart zabbix-agent

Zabbix Server veya Proxy üzerinden bu anahtarın çalışıp çalışmadığını doğrulamak, canlıya almadan önceki en kritik adımdır. zabbix_get ile testi gerçekleştiriyoruz:

zabbix_get -s 127.0.0.1 -k custom.vms.discovery

Adım 3: Zabbix Arayüzünde Template ve LLD Kuralı Oluşturma

Şimdi Zabbix GUI’ye geçip bu veriyi anlamlı host’lara dönüştürecek şablonu tasarlayalım.

1. Template Tanımlama

Öncelikle “Template Dynamic VM Discovery” adında boş bir template oluşturun.

2. Discovery Rule Ekleme

Oluşturduğunuz template içinde Discovery rules sekmesine gidin ve “Create discovery rule” butonuna tıklayın:

Name: Discover Dynamic VMs
Type: Zabbix agent (veya proxy kullanıyorsanız agent active)
Key: custom.vms.discovery
Update interval: 1h (Altyapı dinamikliğinize göre 5m ile 1h arasında ayarlayabilirsiniz. Çok sık çalıştırmak API limitlerinizi zorlayabilir.)
Keep lost resources period: 3d (Silinen sunucuların Zabbix’ten hemen değil, 3 gün sonra temizlenmesini sağlar. Geçici kesintilerde veri kaybını önler.)

3. Host Prototypes Tanımlama

İşte sihrin gerçekleştiği yer burası. Discovery kuralının altındaki Host prototypes sekmesine gidin ve “Create host prototype” deyin:

Host name: {#VM.NAME}-{#VM.UUID} (Tekil bir isim olması şarttır, UUID kullanımı çakışmaları önler.)
Visible name: {#VM.NAME}
Templates: Yeni oluşturulacak sunuculara otomatik bağlanmasını istediğiniz template’leri seçin (Örn: Linux by Zabbix agent).
Group prototypes: Sunucuları mantıksal gruplara ayırmak için VMs/{#VM.ENV} şeklinde dinamik bir grup tanımlayın. Zabbix bu grupları otomatik oluşturacaktır.
Interfaces: IP adresini statik yazmak yerine LLD makromuzu gömüyoruz: IP address alanına {#VM.IP} yazın. DNS name boş kalabilir, Port varsayılan 10050.

Adım 4: Trigger Prototipleri ile Dinamik Eşik Değerleri

Sadece host oluşturmak yetmez; her host’un kendi doğasına göre trigger üretmesi gerekir. Örneğin, Staging ortamındaki sunucular için CPU alarm eşiği %95 iken, Production için %85 olmalıdır.

Bunu Host Prototype seviyesinde tanımlayacağımız kullanıcı makroları (User Macros) ile çözüyoruz. Host Prototype içerisindeki Macros sekmesine gidin ve şu tanımlamayı yapın:

Macro: {$CPU.ALERT.THRESHOLD}
Value: 85

Eğer ortam bazlı esneklik istiyorsanız, LLD filtresi kullanarak farklı Host Prototype’lar tanımlayabilir ve her birine farklı makro değerleri atayabilirsiniz. Örneğin:

Host Prototype Production: Filtre -> {#VM.ENV} matches Production, Makro -> {$CPU.ALERT.THRESHOLD} = 85
Host Prototype Staging: Filtre -> {#VM.ENV} matches Staging, Makro -> {$CPU.ALERT.THRESHOLD} = 95

Performans ve Ölçekleme Notları

Büyük ölçekli (1000+ host) ortamlarda LLD üzerinden host üretirken dikkat etmeniz gereken bazı SRE pratikleri vardır:

1. Zabbix Trapper Tercihi

Zabbix Agent’ın aktif/pasif modda sürekli sorgulanması yerine, harici bir cronjob veya event-driven bir script (örn: AWS Lambda) yardımıyla verileri toplayıp zabbix_sender ile doğrudan bir LLD trapper item’ına göndermek, Zabbix Server üzerindeki poller yükünü neredeyse sıfıra indirir.

# Trapper kuralına veri gönderme örneği
zabbix_sender -z zabbix-server-ip -s "Master-Discovery-Host" -k custom.vms.discovery -o "[{...}]"

2. Unreachable Delay Ayarları

Dinamik sunucular hızlıca kapanıp açılabildiğinden, geçici olarak ulaşılamayan ajanlar Zabbix’in poller’larını kilitleyebilir. zabbix_server.conf dosyasında StartPingers ve UnreachableDelay parametrelerini optimize etmeyi ihmal etmeyin.

# /etc/zabbix/zabbix_server.conf
UnreachableDelay=15
UnavailableDelay=60

LLD ve Host Prototypes kombinasyonu, manuel envanter yönetimini tamamen ortadan kaldırarak izleme altyapınızı “declarative” bir yapıya kavuşturur. Altyapınız büyürken monitoring sisteminiz de onunla birlikte, insan müdahalesine gerek kalmadan, güvenle ölçeklenir.

Posted 17 Ekim 2025 by Kerem Danış in category "Genel