Zabbix’te LLD ile Dinamik Host ve Servis Keşfi: El Yordamıyla İzlemeye Son

Gece yarısı gelen bir “disk doldu” alert’üyle uyanıp, aslında o diskin iki gün önce geçici olarak sisteme bağlanmış bir yedekleme mount’u olduğunu fark ettiğinizde hissettiğiniz o derin bıkkınlığı bilirsiniz. Ya da yeni ayağa kalkan onlarca mikroservisin monitoring süreçlerini manuel yönetmeye çalışırken kaybettiğiniz saatleri… İşte tam bu noktada modern altyapı yönetiminin can simidi olan zabbix dünyasının en güçlü silahı, yani lld (Low-Level Discovery) devreye giriyor. Bu yazıda, statik şablonların ötesine geçip discovery süreçlerini nasıl gerçek bir otomasyon harikasına dönüştüreceğimizi konuşacağız.

Neden LLD? Statik Dünyanın Sonu

Geleneksel monitoring yaklaşımlarında, her yeni sunucu veya servis için el yordamıyla template atamak, disk harflerini tek tek girmek veya portları hardcoded yazmak kabul edilebilir bir yöntemdi. Ancak günümüzün dinamik altyapılarında (Auto-scaling grupları, dinamik Kubernetes podları, sürekli değişen Docker container’ları) bu yaklaşım tam bir operasyonel intihardır.

LLD, hedef makinedeki değişken yapıları (disk partition’ları, network interface’leri, custom veritabanı instance’ları vb.) otomatik olarak tarar, bulur ve Zabbix üzerinde bunlara ait item, trigger ve grafikleri dinamik olarak oluşturur. Bizim yapmamız gereken tek şey, Zabbix’e “neyi, nasıl arayacağını” söylemektir.

LLD’nin Anatomisi: JSON Esastır

Bir LLD kuralının çalışabilmesi için Zabbix Agent’ın veya harici bir script’in Zabbix Server’a belirli bir formatta JSON döndürmesi gerekir. Zabbix, bu JSON içerisindeki makroları (örneğin {#FSNAME} veya {#PORT}) okur ve bunları prototiplerle eşleştirerek gerçek item’lara dönüştürür.

Zabbix’in beklediği modern JSON şablonu tam olarak şöyledir:

[
  {
    "{#APP_NAME}": "payment-api",
    "{#APP_PORT}": "8081",
    "{#ENV}": "production"
  },
  {
    "{#APP_NAME}": "notification-service",
    "{#APP_PORT}": "8082",
    "{#ENV}": "production"
  }
]

Buradaki anahtar nokta, süslü parantez ve diyez işaretiyle başlayan {#MACRO_ADI} tanımlamalarıdır. Zabbix bu makroları gördüğü an, arkasındaki değeri değişken olarak kabul eder.

Uygulama: Özel Bir LLD Scripti ile Servis Keşfi

Senaryomuz şu olsun: Sunucularımızda çalışan dinamik Node.js veya Go uygulamalarımız var. Bu uygulamaların durumlarını ve port erişilebilirliklerini otomatik olarak keşfedip izlemek istiyoruz. Statik template yazamayız çünkü hangi sunucuda hangi servisin çalışacağı dinamik olarak değişiyor.

Adım 1: Keşif Scriptini Yazalım

Öncelikle sunucuda koşan belirli isimdeki servisleri ve portlarını bulan ufak bir bash script yazıyoruz. Bu script bize yukarıda bahsettiğimiz JSON formatını döndürecek. Scripti /usr/local/bin/app_discovery.sh yoluna kaydedelim.

#!/bin/bash

# Aktif dinlenen portları ve servis isimlerini yakala (Örn: app- ile başlayanlar)
services=$(netstat -tlpn | grep -oP '(?<=::|0.0.0.0:)\d+.*(?=/)' | awk '{print $1,$2}' | grep 'app-')

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

echo "["
first=1
echo "$services" | while read -r port process; do
    service_name=$(echo "$process" | cut -d'-' -f2-)
    if [ $first -ne 1 ]; then
        echo ","
    fi
    echo "  {"
    echo "    \"{#APP_NAME}\": \"${service_name}\","
    echo "    \"{#APP_PORT}\": \"${port}\""
    echo "  }"
    first=0
done
echo "]"

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

chmod +x /usr/local/bin/app_discovery.sh

Adım 2: Zabbix Agent Konfigürasyonu (UserParameter)

Şimdi Zabbix Agent’a bu scripti bir anahtar (key) olarak tanıtmamız gerekiyor. /etc/zabbix/zabbix_agentd.d/userparameter_apps.conf dosyasını oluşturup içine şu satırı ekliyoruz:

UserParameter=custom.apps.discovery,/usr/local/bin/app_discovery.sh

Değişikliğin devreye girmesi için agent’ı restart ediyoruz:

systemctl restart zabbix-agent

Zabbix Server veya Proxy üzerinden bu kuralın çalışıp çalışmadığını test etmek için şu komutu kullanabilirsiniz:

zabbix_get -s 127.0.0.1 -k custom.apps.discovery

Zabbix Arayüzünde Template ve LLD Yapılandırması

Sunucu tarafındaki işimiz bitti. Şimdi Zabbix Web arayüzüne geçip bu veriyi anlamlı monitoring öğelerine dönüştürelim.

1. Discovery Rule Oluşturma

• Yeni bir template oluşturun (örn: Template App Dynamic Monitoring).
• Discovery rules sekmesine gelin ve Create discovery rule butonuna tıklayın.
• Name: Dynamic App Discovery
• Type: Zabbix agent (veya aktifi kullanıyorsanız active)
• Key: custom.apps.discovery
• Update interval: 1h (Bu kritik! Keşif süreçleri sistemi yormasın diye sık çalıştırılmamalıdır. Saatte bir idealdir.)

2. Item Prototypes (Öğe Prototipleri) Tanımlama

Keşif kuralını yazdıktan sonra, bulunan her bir uygulama için hangi metrikleri toplayacağımızı belirlemeliyiz. LLD kuralının altındaki Item prototypes sekmesine gidin.

• Name: Application {#APP_NAME} Port {#APP_PORT} Status
• Key: net.tcp.service[tcp,,{#APP_PORT}]
• Type of information: Numeric (unsigned)

Burada dikkatinizi çekti mi? Tek bir prototip tanımlayarak, keşfedilen tüm portlar için ayrı ayrı item’ların otomatik oluşmasını sağladık. “Neden böyle?” derseniz, Zabbix her bir JSON objesindeki {#APP_PORT} değerini alıp buradaki key’in içine yerleştirecektir.

3. Trigger Prototypes (Tetikleyici Prototipleri) Tanımlama

Portun kapalı olması durumunda alert almak istiyorsak, bir tetikleyici prototipi tanımlamalıyiz. Trigger prototypes sekmesine gelin:

• Name: Application {#APP_NAME} on port {#APP_PORT} is DOWN
• Expression: last(/Template App Dynamic Monitoring/net.tcp.service[tcp,,{#APP_PORT}])=0
• Severity: High

Performans ve Güvenlik: Senior SRE Taktikleri

Uygulamayı yaptık, harika çalışıyor. Ancak prod ortamında işlerin çığırından çıkmaması için şu üç altın kuralı aklınızdan çıkarmayın:

Lifetime (Keep lost resources period) Ayarı

Keşfedilen bir servis silindiğinde veya port kapatıldığında, Zabbix bu item’ı ne kadar süre saklamalı? Varsayılan ayar 30 gündür. Dinamik ortamlarda bu değer veritabanının şişmesine neden olur. LLD kuralındaki Keep lost resources period değerini 3d (3 gün) veya stateful olmayan yapılar için 0 yapın.

Discard Unchanged (Preprocessing) Kullanımı

Eğer keşif çıktınız (JSON) saatler boyunca değişmiyorsa, Zabbix’in sürekli aynı veriyi veritabanına yazmasını engelleyin. LLD Rule içerisindeki Preprocessing sekmesine gidin ve Discard unchanged with heartbeat ekleyerek süreyi 1h veya 12h yapın. Bu, DB I/O değerlerinizi inanılmaz derecede rahatlatacaktır.

Filtreleri Etkin Kullanın

Keşif çıktısında gelen her şeyi izlemek zorunda değilsiniz. LLD kuralı içindeki Filters sekmesini kullanarak, sadece belirli regex kurallarına uyan servisleri (örneğin sadece production ortamındakileri) içeri alıp diğerlerini ignore edebilirsiniz.

Zabbix LLD, doğru kurgulandığında operasyonel yükü sıfıra indiren bir mühendislik harikasıdır. Manuel eklemelerle vedalaşın ve altyapınızın kendi kendini izlemesini izlemenin keyfini çıkarın!