Zabbix'te şablon tasarlamak ve düşük seviyeli keşif kuralı yazmak

Şablon neden izleme işinin omurgasıdır?

Zabbix'te bir sunucuyu izlemeye başlamak kolaydır: host eklenir, birkaç öğe tanımlanır, ilk grafikler gelir. Sorun, aynı işin yüzlerce makine için tekrarlanması gerektiğinde çıkar. Elle tanımlanmış öğeler zamanla birbirinden ayrışır; bir sunucuda eşik değeri sıkı, diğerinde gevşek kalır, bir tetikleyici yalnızca bazı makinelerde bulunur. Şablon bu dağınıklığı tek bir yerde toplamak için vardır.

Zabbix belgelerinin tarifiyle şablon, birden çok host'a uygulanabilen bir varlık kümesidir. İçinde öğeler, tetikleyiciler, grafikler, panolar, düşük seviyeli keşif kuralları ve web senaryoları bulunabilir. Şablon bir host grubuna değil, doğrudan her host'a bağlanır. Şablonda yapılan bir değişiklik bağlı bütün host'lara yayılır. Yani bir disk eşiğini değiştirmek için yüzlerce makineyi tek tek açmanız gerekmez.

İyi tasarlanmış bir şablon seti, izleme ekibinin iş bölümünü de belirler: şablonu yazan kişi izlenecek şeyin ne olduğunu ve neyin alarm sayılacağını tanımlar, host'u ekleyen kişi yalnızca doğru şablonu bağlar. Bu ayrım, yeni bir sunucu devreye girdiğinde izlemenin kendiliğinden başlamasını sağlar.

İyi bir şablonun anatomisi

Şablon yazarken ilk karar kapsamdır. Her hizmet için ayrı ve küçük şablonlar, tek devasa şablondan daha sürdürülebilirdir. Örneğin işletim sistemi temel metrikleri için bir şablon, web sunucusu için bir şablon, veritabanı için bir şablon yazılır; host'a hizmetlerine göre birkaçı birlikte bağlanır. Şablonlar birbirine bağlanabildiği için ortak kısımlar üst şablonda tutulabilir, ancak bu zincir uzadıkça hata ayıklamak zorlaşır. Zincirleri kısa tutmak iyi bir alışkanlıktır.

Şablonda şu parçalara dikkat edilir:

• Öğeler: Neyin, hangi yöntemle (Zabbix ajanı, SNMP, betik, bağımlı öğe) ve hangi sıklıkla toplanacağı. Toplama sıklığı her öğede ayrı ayrı kodlanmak yerine mümkünse kullanıcı makrosuyla verilir.
• Tetikleyiciler: Eşiği sabit sayı olarak yazmak yerine kullanıcı makrosuna (örneğin disk doluluk eşiği için bir makro) bağlayın. Böylece bir host ya da host grubu şablona dokunulmadan kendi eşiğini geçersiz kılabilir.
• Etiketler (tags): Tetikleyici ve öğeleri hizmet, katman ya da sorumlu ekip gibi etiketlerle işaretlemek, uyarı yönlendirmeyi ve filtrelemeyi sonradan kolaylaştırır.
• Açıklamalar: Her tetikleyicinin açıklama alanına neyin bozulduğunu ve ilk bakılacak yeri yazın; gece nöbetçisi için bu fark yaratır.

Son olarak şablonlar şablon gruplarında düzenlenir. Grup adlandırmasını işletim sistemi, ağ, veritabanı, uygulama gibi tutarlı bir ağaçta yapmak, şablon sayısı arttığında aradığınızı bulmayı sağlar.

Düşük seviyeli keşif nedir, ne zaman gerekir?

Bazı varlıklar host'tan host'a değişir: bir sunucuda yalnızca kök dosya sistemi, diğerinde çok sayıda ayrı disk; bir anahtarda onlarca arayüz, bir diğerinde yüzlerce. Her biri için öğe, tetikleyici ve grafik elle açmak hem uzun sürer hem de sürekli eskir, çünkü disk eklenir, arayüz kaldırılır. Düşük seviyeli keşif (low-level discovery, LLD) bu varlıkları kendi kendine bulur ve her biri için öğe, tetikleyici ve grafik üretir.

Mantık birkaç parçadan oluşur. Birincisi keşif kuralıdır: bir anahtarı, güncelleme aralığı ve zaman aşımı olan, aslında bir öğedir. Zabbix ajanında dosya sistemleri için vfs.fs.discovery, ağ arayüzleri için net.if.discovery gibi hazır anahtarlar bulunur. İkincisi LLD makrolarıdır: {#FSNAME} ya da {#IFNAME} gibi süslü parantez ve diyez ile yazılan değişkenler; keşfedilen her varlık için ayrı bir değer alırlar. Üçüncüsü prototiplerdir: öğe, tetikleyici, grafik ve host prototipleri, makroları kullanarak her varlık için gerçek nesneler üretilir.

Bir şeyi keşfe bağlamak için ölçüt basittir: izlenecek nesnelerin sayısı host'a göre değişiyor ya da zaman içinde değişiyorsa LLD kullanın. Sayı sabitse (örneğin her sunucuda tek bir servis) normal öğe yeterlidir.

Örnek: dosya sistemi keşfini adım adım kurmak

Zabbix arayüzünde Data collection menüsünden Templates sayfasına gidin, şablonunuzu açın ve Discovery sekmesinden yeni bir keşif kuralı oluşturun. Anahtar olarak vfs.fs.discovery, güncelleme aralığı olarak disk eklemenin sık olmadığı bir süre seçin; keşfi her dakika çalıştırmak çoğu zaman gereksizdir.

Kural, Zabbix'in beklediği biçimde bir JSON dizisi döndürür: her eleman bir nesnedir ve anahtarları LLD makrolarıdır. Örneğin:

[ {"{#FSNAME}": "/", "{#FSTYPE}": "ext4"}, {"{#FSNAME}": "/var", "{#FSTYPE}": "xfs"} ]

Sonra kuralın altındaki Item prototypes bölümüne geçin. Prototip adı "Boş alan yüzdesi: {#FSNAME}" olabilir; anahtarı vfs.fs.size[{#FSNAME},pfree] biçiminde yazılır. Yukarıdaki keşif sonucunda her dosya sistemi için ayrı bir öğe oluşur. Ardından Trigger prototypes bölümünde, güncel sürümlerde şu biçimde bir ifade yazarsınız:

last(/Şablon Disk/vfs.fs.size[{#FSNAME},pfree])<{$FS.FREE.MIN}

Eşiğin sabit bir sayı değil, {$FS.FREE.MIN} adlı kullanıcı makrosu olduğuna dikkat edin. Şablon düzeyinde makroya makul bir varsayılan verilir; kritik bir veritabanı sunucusunda host düzeyinde daha yüksek bir değerle geçersiz kılınır. Son olarak bir grafik prototipi ekleyin. Kuralı kaydedip host üzerinde ilk keşif turu bittiğinde öğelerin ve tetikleyicilerin oluştuğunu Latest data sayfasında görürsünüz.

Filtre, geçersiz kılma ve kayıp kaynak ayarları

Her keşfedilen varlığı izlemek istemezsiniz. Dosya sistemi örneğinde sanal ya da geçici dosya sistemleri gürültü üretir. Keşif kuralındaki filtre, makro değerine düzenli ifade uygulayarak yalnızca eşleşenleri tutar; örneğin {#FSTYPE} değerinin belirli türlerle eşleşmesini ya da bazılarını dışlamasını isteyebilirsiniz. Filtreyi deneme aşamasında geniş tutup ilk sonuçları inceledikten sonra daraltmak daha güvenlidir.

Bazen tek bir varlık için istisna gerekir: kök dosya sistemi için eşik farklı, yedek diski için tetikleyici kapalı olmalıdır. Bunun için kural düzeyinde geçersiz kılma (override) tanımlanır; belirli bir koşulu sağlayan keşfedilmiş varlıkta belirli prototipler değiştirilir, kapatılır ya da etiketlenir. Böylece şablonu bölmeye gerek kalmaz.

En önemli ayar kayıp kaynaklarla ilgilidir. Bir varlık artık keşfedilmediğinde "Not discovered anymore" durumuna geçer. Disable lost resources ayarı onu hemen, hiç ya da belirli bir süre sonra devre dışı bırakır; Delete lost resources ayarı silmeyi aynı seçeneklerle yönetir ve silme süresi devre dışı bırakma süresinden büyük olmalıdır. Belgeler, silmede "hemen" seçeneğine karşı uyarır: filtrede yapılacak yanlış bir düzenleme, bir varlığı geçmiş verisiyle birlikte silebilir. Bir süre tanımak, geçici bir ağ kesintisinin tarihçeyi yok etmesini önler.

Kendi keşif kuralınızı yazmak

Hazır anahtarlar dosya sistemi, arayüz, işlemci gibi yaygın varlıkları kapsar. Kuruma özel nesneleri (bir uygulamanın kuyrukları, bir yedekleme sisteminin işleri, bir veritabanının şemaları) izlemek için kendi keşfinizi yazarsınız. Yöntem sade: bir betik çalıştırır, çıktıyı yukarıdaki JSON dizisi biçiminde verirsiniz.

Ajan tarafında bunu bir UserParameter ile yaparsınız. Ajan yapılandırma dosyasına şuna benzer bir satır eklenir:

UserParameter=uygulama.kuyruk.kesif,/usr/local/bin/kuyruk_listele.sh

Betik her kuyruk için {"{#KUYRUK}": "ad"} nesnesi içeren bir dizi basar. Keşif kuralının anahtarı uygulama.kuyruk.kesif olur; prototip öğesi de uygulama.kuyruk.uzunluk[{#KUYRUK}] gibi parametre alan bir anahtar kullanır ve ayrı bir UserParameter bu parametreyi karşılar.

Çıktı Zabbix'in beklediği biçimde değilse ya da beklenen makro anahtarı yoksa, LLD makrolarını sekmesinde özel makro tanımlayıp bir JSONPath ifadesiyle JSON alanına eşleyebilirsiniz. Keşif verisi ön işleme adımlarından da geçirilebilir; tüm ön işleme Zabbix sunucusunda çalışır. Her işte tek bir betik çağrısıyla hem keşfi hem verileri toplayıp bağımlı öğelerle dağıtmak, büyük ortamlarda host üzerindeki yükü azaltır.

Sık yapılan hatalar ve kontrol listesi

Şablon ve LLD tasarımında tekrar eden hatalar şunlardır:

• Sabit eşikler: Tetikleyiciye doğrudan sayı yazmak, ilk istisnada şablonu çoğaltmaya götürür. Makro kullanın.
• Devasa tek şablon: Her şeyi içeren şablon, bir host'ta gereksiz yüzlerce öğe çalıştırır. Hizmete göre bölün.
• Çok sık keşif: Keşif kuralı da bir öğedir ve yük üretir; nesneler nadiren değişiyorsa aralığı uzun tutun.
• Makro adı uyuşmazlığı: Prototiplerde yazılan makro adı keşif çıktısındaki adla birebir aynı olmalıdır; büyük küçük harf ve ayraç hatası öğelerin hiç oluşmamasına neden olur.
• Aynı anahtardan çakışma: Birden çok prototip aynı anahtarı üretirse sonrakiler oluşturulamaz. Anahtara makroyu eklemeyi unutmayın.
• Silmede acele: Kaybolan varlıkları hemen silmek, geçici bir kesintide tarihçeyi götürür.

Yayına almadan önce küçük bir kontrol listesi işe yarar: şablon bir test host'una bağlanıp ilk keşif turu izlendi mi, filtre beklenmeyen varlıkları dışarıda bırakıyor mu, eşikler makroyla verildi mi, her tetikleyicinin açıklaması dolu mu, kayıp kaynak süreleri mantıklı mı? Şablonu üretime yaymadan önce bir farklı işletim sistemi ve bir uç durum host'unda denemek, sonradan gelen alarm fırtınalarını büyük ölçüde önler.

Bu beceriyi Mindset programında nerede çalışırsınız?

Mindset kataloğundaki Zabbix ile Kurumsal Altyapı İzleme eğitiminin müfredatında Şablon Tasarımı ve Düşük Seviye Keşif başlıklı ayrı bir modül yer alır. Eğitim; Zabbix mimarisi ve kurulumundan host yönetimine, tetikleyici ve eskalasyondan dağıtık mimariye uzanan bir akış izler. Bu nedenle şablon ve keşif çalışması, tek başına bir araç bilgisi olarak değil, izleme ortamının nasıl ölçeklendiği sorusunun parçası olarak ele alınır.

Eğitim, sistem yöneticileri, ağ ve altyapı mühendisleri ve sorumlu olduğu sunucu sayısı büyüyen operasyon ekipleri için uygundur. Kurumsal ekipler için pratik fayda şudur: izleme standardı kişilerin elindeki betiklerden çıkıp ortak şablonlara taşındığında, yeni gelen bir ekip arkadaşı da aynı eşikleri ve aynı uyarı mantığını devralır.