Zabbix ile altyapı izleme: kurulum, şablon ve uyarı rehberi

Zabbix ile izleme neyi çözer?

Zabbix, sunucu, ağ cihazı, veritabanı ve uygulama gibi altyapı bileşenlerinin durumunu sürekli toplayıp değerlendiren açık kaynaklı bir izleme platformudur. Bir disk dolmaya başladığında, bir servis yanıt vermediğinde ya da bir ağ bağlantısı kesildiğinde sistem yöneticisinin kullanıcıdan şikâyet gelmeden haberdar olması hedeflenir. İzleme, yalnızca "çalışıyor mu" sorusuna değil, "nasıl gidiyor" sorusuna da yanıt verir: eğilim grafikleri, kapasite planlaması ve olay sonrası inceleme için tarihsel veri sunar.

Zabbix'i değerli kılan, tek bir araçla farklı veri toplama yöntemlerini birleştirebilmesidir. Aynı arayüzden bir Linux sunucunun işlemci yükünü, bir anahtarın port durumunu ve bir web uygulamasının yanıt süresini izlemek mümkündür. Bu yüzden kurumsal altyapı ekiplerinde merkezî izleme katmanı olarak sıkça tercih edilir.

Mimari: hangi parçalar nasıl çalışır?

Resmî dokümantasyonda Zabbix mimarisi şu parçalardan oluşur: sunucu (server), veritabanı deposu, web arayüzü, isteğe bağlı proxy ve izlenen makinelere kurulan ajanlar (Zabbix agent ve daha yeni nesil Zabbix agent 2). Sunucu, veriyi toplayan, tetikleyicileri değerlendiren ve kullanıcılara bildirim gönderen merkezî süreçtir. Veritabanı yapılandırmayı ve toplanan veriyi saklar. Web arayüzü ise yönetim ve görselleştirme ekranıdır.

Proxy, uzak lokasyonlardaki ya da ayrı ağ segmentindeki cihazların verisini sunucu adına toplayıp iletir; yükü dağıtır ve ağ kısıtlarını aşmayı kolaylaştırır. Ajan, izlenen makinede çalışır ve yerel metrikleri (işlemci, bellek, disk, servis durumu) sunucuya taşır. Ajan kurulamayan cihazlarda (ağ ekipmanı, bazı donanım yönetim arayüzleri) standart protokoller üzerinden ajansız izleme yapılabilir.

Kurulum yaklaşımı ve ilk izleme

Kurulum, kurumun işletim sistemi ve veritabanı tercihine göre değişir; dokümantasyondaki paket ve veritabanı uyumluluk tabloları kontrol edilerek ilerlenmelidir. Önce sürüm seçilir: Zabbix, uzun süreli destek (LTS) sürümleri ile daha kısa ömürlü standart sürümler yayımlar. Üretim ortamında genellikle LTS sürümü tercih edilir, çünkü güncelleme ve güvenlik düzeltmesi takvimi daha uzun ve öngörülebilirdir. Hangi sürümün tam, hangisinin sınırlı destekte olduğu resmî yaşam döngüsü sayfasından kontrol edilmeli, sunucu, proxy ve ajan sürümlerinin birbiriyle uyumu da bu aşamada planlanmalıdır. Genel akış şöyledir:

• Sunucu bileşeni için veritabanı hazırlanır ve şeması içe aktarılır
• Sunucu servisi yapılandırılıp başlatılır, web arayüzü kurulur
• İzlenecek makinelere ajan kurulur ve sunucu adresi tanımlanır
• Web arayüzünde host oluşturulur, bir şablon (template) bağlanır
• Veri akışı doğrulanır, ilk panolar incelenir

Zabbix'te temel mantık şudur: önce host tanımlanır, host üzerinde item (toplanacak metrik) oluşturulur, item'a bağlı koşul olarak trigger yazılır ve trigger tetiklendiğinde action ile bildirim gönderilir. Bu zinciri anlamak, kurulumun geri kalanını kolaylaştırır. İlk hedef küçük tutulur: birkaç sunucuyu izlemeye almak ve çalışan bir uyarı üretmek, büyük bir mimariye geçmeden önce doğru temeli verir.

Host, item ve şablonlar: veri toplamayı ölçeklemek

Zabbix'te her izlenen cihaz bir host'tur ve host'lar gruplara ayrılarak yetki ve raporlama kolaylaştırılır. Host üzerinde item'lar çeşitli yöntemlerle veri toplar: ajan sorguları, SNMP, IPMI, JMX ve web istekleri gibi. Aynı türden onlarca sunucu için item'ları tek tek tanımlamak yerine şablon (template) kullanılır: şablon bir kez hazırlanır, ilgili host'lara bağlanır ve değişiklik tüm bağlı host'lara yansır.

Şablon tasarımında dikkat edilecek ilke şudur: şablon rol bazlı ve katmanlı kurulmalıdır. Örneğin tüm Linux sunucular için temel işletim sistemi şablonu, veritabanı sunucuları için ek bir şablon, belirli bir uygulama için ayrı bir şablon bağlanır. Makro (macro) değişkenleri ile eşik değerleri host bazında özelleştirilir.

Düşük seviye keşif (low-level discovery), disk bölümü, ağ arayüzü ya da veritabanı gibi sayısı makineden makineye değişen varlıkları otomatik bulur ve her biri için item oluşturur. Böylece yeni bir disk eklendiğinde izleme elle değiştirilmeden otomatik genişler.

Tetikleyici ve uyarı tasarımı

İzlemenin en zor kısmı veri toplamak değil, doğru uyarıyı üretmektir. Çok fazla uyarı, ekibin hepsini görmezden gelmesine yol açar. İyi uyarı tasarımı şu ilkelere dayanır:

• Uyarı eyleme dönüşmelidir: alıcının ne yapacağı net olmalı
• Eşikler anlık dalgalanmaya değil, belirli süre devam eden duruma bağlanmalı
• Önem düzeyleri ayrışmalı: bilgi, uyarı, kritik
• Bağımlılıklar tanımlanmalı: ağ geçidi çöktüğünde arkasındaki tüm cihazlar için ayrı ayrı alarm gelmemeli
• Bakım pencereleri tanımlanmalı ki planlı çalışmalar sahte alarm üretmesin

Action tarafında uyarının kime, hangi kanaldan ve ne kadar süre yanıtlanmazsa kime yükseltileceği (eskalasyon) kurgulanır. E-posta, mesajlaşma uygulaması ya da çağrı yönetim aracı entegrasyonu gibi kanallar medya türleri üzerinden tanımlanır. Uyarı metni kısa, anlaşılır ve gerekli bağlamı (hangi host, hangi metrik, hangi eşik) içermelidir.

Ağ, veritabanı, uygulama izleme ve dağıtık mimari

Ağ izlemede SNMP ile anahtar ve yönlendirici portlarının durumu, trafik hacmi ve hata sayaçları toplanır. Bir hat doluluğa yaklaştığında kapasite planlaması için erken sinyal alınır. Veritabanı izlemede bağlantı sayısı, sorgu gecikmesi, replikasyon durumu ve disk kullanımı gibi göstergeler takip edilir. Uygulama tarafında web senaryoları ile bir sayfanın erişilebilirliği ve yanıt süresi ölçülür; Java uygulamaları için JMX üzerinden ilgili metrikler çekilir.

Örneğin bir e-ticaret altyapısında ön uç sunucuları, veritabanı ve ödeme servisine bağlanan ağ geçidi aynı panoda toplanabilir. Sipariş ekranı yavaşladığında ekip, işlemci yükü, veritabanı gecikmesi ve ağ hatalarını yan yana görerek sorunun hangi katmanda olduğunu hızla daraltır.

Çok lokasyonlu yapılarda her lokasyona bir proxy konularak merkezî sunucunun yükü ve ağ trafiği azaltılır. Merkezî sunucuda ise yüksek erişilebilirlik ve veritabanı performansı planlanmalıdır, çünkü büyüyen veri hacmi depolama ve temizleme (housekeeping) politikalarını gündeme getirir.

Görselleştirmede panolar, hizmet bazlı görünümler ve haritalar yönetim ve operasyon ekibinin ihtiyacına göre kurulur. Operasyon ekranı anlık durumu, yönetim raporu ise erişilebilirlik ve kapasite eğilimini gösterir. İzleme sistemi de bakım ister: şablonlar gözden geçirilir, kullanılmayan uyarılar kaldırılır, sistemin kendisi de izlenir.

Sık yapılan hatalar

• Her metriği izlemeye alıp hangisinin neden gerekli olduğunu tanımlamamak
• Şablonları kopyalayıp host bazında dağıtmak ve güncellemeyi imkânsız hale getirmek
• Uyarıları eşik hassasiyetini ayarlamadan açmak
• Bağımlılıkları tanımlamamak ve olay sırasında alarm yağmuruna maruz kalmak
• Proxy ve veritabanı kapasitesini büyümeden önce planlamamak
• Yetkileri host grubu bazında ayırmayıp herkese tam erişim vermek

Yeni başlayanlar için en etkili yaklaşım, küçük bir ortamda çalışan bir izleme kurup uyarıları gerçek olaylarla ayarlamak, sonra şablonlaştırıp yaygınlaştırmaktır.

Mindset programlarında bu beceriyi nerede çalışırsınız?

Zabbix ile Kurumsal Altyapı İzleme programı; Zabbix mimarisi ve kurulum, host yönetimi ve veri toplama yöntemleri, şablon tasarımı ve düşük seviye keşif, tetikleyici, uyarı ve eskalasyon, ağ, veritabanı ve uygulama izleme, dağıtık mimari ile görselleştirme ve proje başlıklarını kapsar.