Zabbix Template Nedir ve Nasıl Kullanılır?

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

Zabbix kurulumunu bitirip ilk birkaç sunucuyu eklediğinizde fark ediyorsunuz: Her sunucu için tek tek item, trigger ve graph tanımlamak hem zaman kaybı hem de sürdürülemez bir yaklaşım. İşte tam bu noktada template’ler devreye giriyor. Bir kez iyi tasarlanmış bir template, onlarca hatta yüzlerce sunucuya saniyeler içinde uygulanabiliyor. Ben bu yazıda size hem template mantığını hem de gerçek hayatta nasıl kullandığımı aktaracağım.

Zabbix Template Mantığı

Template, Zabbix’te bir izleme şablonudur. İçinde item, trigger, graph, discovery rule ve hatta başka template’lere bağlantı (linked template) barındırabilir. Bir host’a template uyguladığınızda, o template’in tüm bileşenleri host’a devralınır.

Bunu şöyle düşünebilirsiniz: Siz bir kez “Linux sunucular için standart izleme seti” tanımlıyorsunuz. CPU kullanımı, RAM durumu, disk I/O, network trafiği, sistemin uptime’ı… Bunları template içine koyuyorsunuz. Bundan sonra yeni bir Linux sunucusu eklediğinizde tek yapmanız gereken o template’i host’a atamak. Beş saniyede o sunucu için tam izleme devreye giriyor.

Zabbix’in kendi içinde de hazır template’leri var. Configuration > Templates menüsüne gittiğinizde görürsünüz. “Linux by Zabbix agent”, “Windows by Zabbix agent”, “MySQL by Zabbix agent” gibi onlarca resmi template geliyor kurulumla birlikte. Ama bunlar her zaman ihtiyacınızı karşılamıyor. Bazen kendinize özel template yazmanız gerekiyor.

Template Bileşenleri

Bir template’in içinde ne olduğunu anlamak, nasıl kullanacağınızı da netleştiriyor.

Items: Toplanacak metrikler. CPU kullanımı, bir servisin durumu, bir dosyanın boyutu gibi. Her item bir “key” ile tanımlanır ve Zabbix agent, SNMP, JMX gibi çeşitli protokollerle veri toplar.

Triggers: Item verilerine dayalı alarm kuralları. “CPU kullanımı 5 dakika boyunca %85’in üzerindeyse alarm üret” gibi. Trigger’lar problem yaratır, problem çözüldüğünde kapanır.

Graphs: Metriklerin görselleştirilmesi. Item’lardan oluşturulan grafikler template’e dahil edilebilir, host’a uygulandığında otomatik grafik oluşur.

Discovery Rules: Dinamik izleme için. Örneğin bir sunucudaki tüm disk partition’larını, network interface’lerini ya da çalışan process’leri otomatik keşfeder ve item/trigger oluşturur.

Macros: Template içinde kullanabileceğiniz değişkenler. {$CPU_WARN} gibi bir makro tanımlayıp trigger’da kullanırsınız. Sonra bu değeri host bazında override edebilirsiniz. Farklı sunucular için farklı eşik değerleri tanımlamak çok kolaylaşıyor böylece.

Hazır Template Kullanımı

En hızlı başlangıç yolu Zabbix’in kendi template’lerini kullanmak. Örneğin bir Linux sunucusunu izlemeye almak için şunları yapıyorsunuz:

Önce Zabbix agent’ı sunucuya kuruyorsunuz:

# RHEL/CentOS için
rpm -Uvh https://repo.zabbix.com/zabbix/6.4/rhel/8/x86_64/zabbix-release-6.4-1.el8.noarch.rpm
dnf install zabbix-agent2 -y

# Ubuntu için
wget https://repo.zabbix.com/zabbix/6.4/ubuntu/pool/main/z/zabbix-release/zabbix-release_6.4-1+ubuntu22.04_all.deb
dpkg -i zabbix-release_6.4-1+ubuntu22.04_all.deb
apt update && apt install zabbix-agent2 -y

Agent konfigürasyonunu düzenliyorsunuz:

# /etc/zabbix/zabbix_agent2.conf dosyasında
Server=192.168.1.10          # Zabbix server IP'si
ServerActive=192.168.1.10    # Active check için
Hostname=web-prod-01         # Zabbix'teki host adıyla aynı olmalı

Agent’ı başlatıyorsunuz:

systemctl enable zabbix-agent2
systemctl start zabbix-agent2
systemctl status zabbix-agent2

Sonra Zabbix arayüzünde Configuration > Hosts > Create Host diyorsunuz, host bilgilerini giriyorsunuz ve Templates sekmesine geçip “Linux by Zabbix agent 2” template’ini ekliyorsunuz. Bu kadar. Birkaç dakika içinde metrikler gelmeye başlıyor.

Kendi Template’inizi Oluşturma

Hazır template’ler çoğu zaman yetmiyor. Uygulamaya özel izleme ihtiyaçları doğuyor. Ben birkaç yıl önce büyük bir e-ticaret projesinde çalışırken, uygulama sunucularındaki bir Java prosesinin sağlık durumunu izlemek için özel template yazmak zorunda kaldım. Standart Linux template’leri yeterli değildi.

Arayüzden Configuration > Templates > Create Template diyerek yeni template açıyorsunuz. Template adı, group ataması yapıyorsunuz. Sonra içine item’lar eklemeye başlıyorsunuz.

Örnek bir senaryo: Bir web sunucusunda özel bir Python uygulaması çalışıyor. Bu uygulamanın ürettiği bir log dosyasının boyutunu izlemek istiyorsunuz. Aynı zamanda uygulamanın kendi health check endpoint’ini kontrol etmek istiyorsunuz.

Bunun için önce Zabbix agent üzerinde UserParameter tanımlıyorsunuz:

# /etc/zabbix/zabbix_agent2.d/myapp.conf
UserParameter=myapp.logsize,stat -c%s /var/log/myapp/application.log
UserParameter=myapp.health,curl -s -o /dev/null -w "%{http_code}" http://localhost:8080/health
UserParameter=myapp.queue.size,redis-cli llen myapp:job:queue

Agent’ı yeniden başlatıyorsunuz:

systemctl restart zabbix-agent2

# Test etmek için Zabbix server'dan:
zabbix_get -s 192.168.1.50 -k myapp.logsize
zabbix_get -s 192.168.1.50 -k myapp.health

Sonra template içinde bu key’lere karşılık gelen item’ları oluşturuyorsunuz. Trigger’da ise şunu yazıyorsunuz: HTTP health check 200 dışında bir değer döndürüyorsa alarm ver.

Template Export ve Import

Template’leri XML ya da YAML formatında dışa aktarabilirsiniz. Bu hem yedekleme hem de farklı ortamlar arasında taşıma açısından kritik.

# Zabbix API ile template export
curl -s -X POST -H 'Content-Type: application/json' 
  -d '{
    "jsonrpc": "2.0",
    "method": "configuration.export",
    "params": {
      "options": {
        "templates": ["12345"]
      },
      "format": "yaml"
    },
    "auth": "your_auth_token",
    "id": 1
  }' 
  http://localhost/zabbix/api_jsonrpc.php > myapp_template.yaml

Auth token almak için önce login isteği atıyorsunuz:

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

Dışa aktardığınız YAML dosyası versiyon kontrolüne alınabilir. Git repository’nize koyup template değişikliklerini takip edebilirsiniz. Ekibinizdeki herkes template’i inceleyebilir, değişiklik önerebilir. Bu gerçekten iyi bir pratik ve bunu uygulayan takımlarda izleme konfigürasyonu çok daha sağlıklı oluyor.

Import etmek için arayüzde Configuration > Templates > Import diyebilir ya da API kullanabilirsiniz:

curl -s -X POST -H 'Content-Type: application/json' 
  -d "{
    "jsonrpc": "2.0",
    "method": "configuration.import",
    "params": {
      "format": "yaml",
      "rules": {
        "templates": {"createMissing": true, "updateExisting": true},
        "items": {"createMissing": true, "updateExisting": true},
        "triggers": {"createMissing": true, "updateExisting": true}
      },
      "source": "$(cat myapp_template.yaml)"
    },
    "auth": "your_auth_token",
    "id": 1
  }" 
  http://localhost/zabbix/api_jsonrpc.php

Template Hiyerarşisi ve Linked Templates

Template’ler birbirini referans alabilir. “Base Linux” diye bir template yapıyorsunuz, içine temel OS metrikleri koyuyorsunuz. Sonra “Web Server” template’i yapıyorsunuz, içine Base Linux’u linkliyorsunuz ve üstüne web server’a özgü item’lar ekliyorsunuz. Bu hiyerarşik yapı tekrara düşmeden kapsamlı izleme sağlıyor.

Bunu gerçek hayatta şöyle kullandım: Bir müşterinin altyapısında üç farklı uygulama vardı. Hepsi Linux üzerinde çalışıyordu. “Template Base Linux” oluşturdum, içine CPU, RAM, disk, network item’larını koydum. Sonra her uygulama için ayrı template yaptım, hepsi Base Linux’u link etti ve kendi özel item’larını ekledi. Bir sunucu hem web server hem de Redis çalıştırıyorsa iki template birden atadım. Böyle yapınca host’a her iki template’den gelen tüm item’lar devreye girdi.

Makro kullanımına da değinmek gerekiyor çünkü bu konuyu pas geçen çok fazla kaynak var. Template içinde şöyle bir trigger yazıyorsunuz:

{Template_Linux:system.cpu.util.avg(5m)}>{$CPU.UTIL.CRIT}

Burada {$CPU.UTIL.CRIT} bir makro. Template seviyesinde varsayılan değer olarak 85 atıyorsunuz. Ama yüksek yüklenmeye tasarlanmış bir hesaplama sunucunuz var, orada %95’e kadar normal kabul ediyorsunuz. Tek yapmanız gereken o host’a gidip makro değerini override etmek: {$CPU.UTIL.CRIT} = 95. Bütün diğer sunucularda %85 eşiği geçerliyken, bu sunucuda %95 oluyor.

Low-Level Discovery ile Dinamik İzleme

Template’lerin en güçlü özelliklerinden biri Low-Level Discovery (LLD). Bir sunucudaki partition sayısını önceden bilmiyorsunuz. Bazı sunucularda /, /var, /home var; başkasında onlarca farklı partition mevcut. LLD ile Zabbix bu partition’ları otomatik keşfeder ve her biri için item/trigger oluşturur.

Kendi discovery script’inizi de yazabilirsiniz. Zabbix JSON formatında output beklıyor:

#!/bin/bash
# /etc/zabbix/scripts/discover_apps.sh
# Çalışan Java uygulamalarını keşfeder

echo '{"data":['
first=true
for pid in $(pgrep -f "java -jar"); do
    appname=$(cat /proc/$pid/cmdline | tr '' ' ' | grep -oP '(?<=java -jar )S+' | xargs basename 2>/dev/null)
    port=$(ss -tlnp | grep "pid=$pid" | grep -oP ':K[0-9]+' | head -1)
    if [ ! -z "$appname" ]; then
        if [ "$first" = true ]; then
            first=false
        else
            echo ','
        fi
        echo -n "{"{#APPNAME}":"$appname","{#APPPORT}":"$port","{#PID}":"$pid"}"
    fi
done
echo ']}'

Bu script’i UserParameter olarak tanımlayıp template’de Discovery Rule olarak ekliyorsunuz. Item prototype’ında {#APPNAME} makrosunu kullanıyorsunuz. Zabbix her keşif döngüsünde script’i çalıştırıyor, yeni uygulama bulduysa otomatik item oluşturuyor, uygulama durmuşsa item’ı kaldırıyor.

Topluluk Template’leri

Zabbix’in resmi template’leri dışında topluluktan gelen template’ler de var. [Zabbix Share](https://share.zabbix.com) sitesinde yüzlerce hazır template bulunuyor. MySQL, PostgreSQL, Nginx, Apache, Redis, RabbitMQ, Kubernetes… Aklınıza gelen her şey için biri mutlaka bir şeyler yazmış.

Topluluk template’lerini kullanırken dikkat etmeniz gereken birkaç nokta var:

  • Template’in Zabbix versiyonuyla uyumluluğunu kontrol edin. Zabbix 6.x ile 5.x template’leri doğrudan uyumlu olmayabiliyor.
  • Import etmeden önce YAML/XML içeriğini inceleyin. Ne topladığını, hangi external script’lere ihtiyaç duyduğunu anlayın.
  • Template’in son güncellenme tarihine bakın. Uzun süredir bakım görmemiş template’ler güvenilir olmayabilir.

Ben PostgreSQL izlemesi için community template kullanıyorum ama her büyük Zabbix güncellemesinden sonra trigger expression’larını review etmek gerekiyor. Bazen syntax değişiyor.

Template Versiyonlama ve CI/CD Entegrasyonu

Ekip halinde çalışıyorsanız ve template’leriniz karmaşıklaşmaya başladıysa, bunu ciddiye almanız gerekiyor. Template’leri YAML olarak export edip Git’e koyun, her değişikliği commit’leyin.

#!/bin/bash
# zabbix_template_backup.sh
# Cron'a ekleyin, günlük çalıştırın

ZABBIX_URL="http://localhost/zabbix/api_jsonrpc.php"
BACKUP_DIR="/opt/zabbix-template-backups"
DATE=$(date +%Y%m%d_%H%M%S)

# Auth token al
TOKEN=$(curl -s -X POST -H 'Content-Type: application/json' 
  -d '{"jsonrpc":"2.0","method":"user.login","params":{"username":"backup_user","password":"'"$BACKUP_PASS"'"},"id":1}' 
  $ZABBIX_URL | python3 -c "import sys,json; print(json.load(sys.stdin)['result'])")

# Tüm template ID'lerini al
TEMPLATE_IDS=$(curl -s -X POST -H 'Content-Type: application/json' 
  -d '{"jsonrpc":"2.0","method":"template.get","params":{"output":["templateid","name"]},"auth":"'"$TOKEN"'","id":1}' 
  $ZABBIX_URL | python3 -c "
import sys,json
data = json.load(sys.stdin)
ids = [t['templateid'] for t in data['result']]
print(','.join(['"'+i+'"' for i in ids]))
")

mkdir -p $BACKUP_DIR
# Export ve kaydet
curl -s -X POST -H 'Content-Type: application/json' 
  -d '{"jsonrpc":"2.0","method":"configuration.export","params":{"options":{"templates":['"$TEMPLATE_IDS"']},"format":"yaml"},"auth":"'"$TOKEN"'","id":1}' 
  $ZABBIX_URL | python3 -c "import sys,json; print(json.load(sys.stdin)['result'])" 
  > $BACKUP_DIR/all_templates_$DATE.yaml

# Git'e commit
cd $BACKUP_DIR
git add .
git commit -m "Template backup $DATE"
git push origin main

Bu script’i cron’a ekleyip her gece çalıştırdığınızda template değişiklik geçmişiniz Git’te güvenle duruyor. Birisi yanlışlıkla bir template’i bozarsa git diff ile neyin değiştiğini görüp eski haline geri alabiliyorsunuz.

Yaygın Hatalar ve Çözümleri

Template kullanırken sıkça karşılaşılan bazı problemler var. Bunları bilmek zaman kazandırıyor.

Çakışan item key’leri: Bir host’a birden fazla template atadığınızda aynı key’i kullanan item’lar varsa problem çıkıyor. Zabbix bunu hata olarak işaretliyor. Kendi template’lerinizde key’lere prefix koyma alışkanlığı edinin. myapp. veya custom. gibi bir prefix, standart key’lerle çakışmayı önlüyor.

Template güncellemesi host’a yansımıyor: Template’i güncellediniz ama host’ta eski değerler göründü. Bu genellikle host seviyesinde item override olduğunda yaşanıyor. Configuration > Hosts > [host] > Items içinde template’den gelen item’lara override uygulanmış olabilir. Kontrol edin.

Makro öncelik karmaşası: Zabbix’te makrolar üç seviyede tanımlanabilir: global, template ve host. Öncelik sırası host > template > global şeklinde. Host’ta tanımladığınız makro her zaman template’dekini ezer. Bu istenen bir davranış ama bazen beklenmedik sonuçlar doğuruyor. Makro değerlerinin nerede tanımlandığını her zaman kontrol edin.

Discovery item’larının silinmemesi: LLD ile oluşturulan item’lar için “Keep lost resources period” ayarı önemli. Varsayılan 30 gündür. Bir partition kaldırıldığında Zabbix 30 gün boyunca o item’ı silmiyor. Ortamınıza göre bu değeri ayarlayın.

Sonuç

Zabbix template’leri, izleme altyapınızın yönetilebilirliğini doğrudan etkiliyor. Template kullanmadan büyüyen bir Zabbix kurulumunu bir süre sonra yönetmek neredeyse imkânsız hale geliyor. Her host için ayrı ayrı item tanımlamak, bir trigger güncellemesi gerektiğinde yüzlerce host’ta tek tek değişiklik yapmak anlamına geliyor.

İyi bir template stratejisi için şunları öneririm: Önce temel OS template’lerinizi oluşturun ve standarize edin. Tüm ekibin bu template’lere uymasını sağlayın. Uygulama özelindeki izlemeler için bu temel template’leri link eden daha spesifik template’ler yazın. Tüm template’leri YAML olarak Git’te tutun ve değişikliklerini takip edin. Makroları agresif kullanın, hardcoded değerler sizi bir gün başınızı ağrıtır. Community template’lerinden yararlanın ama körü körüne import etmeyin, ne toplandığını anlayın.

Template’ler ilk başta biraz fazla karmaşık görünebiliyor. Ama bir kez iyi bir template seti oluşturduktan sonra yeni sunucu eklemenin bir dakikadan az sürdüğünü görünce, bu yatırımın ne kadar değerli olduğunu anlıyorsunuz.

Bir yanıt yazın

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