Prometheus ile Zabbix: Bulut Yerel Metrikler mi, Kurumsal Altyapı İzleme mi?

İki aracın çıkış noktası neden farklı?

Prometheus ve Zabbix ikisi de açık kaynak izleme araçlarıdır, ikisi de metrik toplar, saklar ve eşik aşıldığında alarm üretir. Ama farklı dünyalar için tasarlanmışlardır. Prometheus, SoundCloud'da geliştirilmeye başlanan ve bugün Cloud Native Computing Foundation çatısı altında bağımsız olarak sürdürülen bir sistem izleme ve alarm araç takımıdır; sürekli doğan ve ölen konteynerlerin, mikroservislerin bulunduğu dinamik ortamlar için kurgulanmıştır. Zabbix ise sunucuları, ağ cihazlarını, sanal makineleri, veritabanlarını ve uygulamaları izleyen kurumsal sınıf, dağıtık bir izleme çözümüdür; kalıcı varlıkların uzun süreli izlenmesinde güçlüdür.

Bu çıkış farkı, iki aracın veri modeline, veri toplama yöntemine ve işletim biçimine doğrudan yansır. Seçimi belirleyen soru, izlediğiniz şeyin daha çok bir sunucu filosu mu yoksa bir servis ağı mı olduğudur.

Ölçüt ölçüt karşılaştırma

• Veri modeli: Prometheus metrikleri, metrik adı ve anahtar değer çiftlerinden oluşan etiketlerle tanımlanan zaman serileri olarak saklar; aynı metriği servis, ortam, bölge gibi boyutlarla dilimlemek doğaldır. / Zabbix'te veri, host üzerindeki öğelere (item) bağlıdır; tetikleyiciler bu öğelerin değerleri üzerinde tanımlanır.
• Veri toplama: Prometheus hedeflerden HTTP üzerinden veri çeker (pull); kısa ömürlü işler için ara bir ağ geçidi üzerinden push desteklenir. / Zabbix ajanı pasif kontrolde sunucunun sorusunu yanıtlar, aktif kontrolde veriyi kendisi gönderir; SNMP, IPMI ve HTTP gibi ajansız yöntemler de vardır.
• Hedeflerin bulunması: Prometheus hedefleri servis keşfiyle ya da statik yapılandırmayla bulur; Kubernetes gibi ortamlarda yeni podlar kendiliğinden izlenmeye başlar. / Zabbix'te hostlar şablonlara bağlanır; düşük seviyeli keşif host içindeki dosya sistemi ve arayüz gibi varlıkları bulur, ağ keşfi de yeni cihazları ekleyebilir.
• Sorgu dili: Prometheus'un PromQL dili, etiketli veride toplama, oran ve karşılaştırma işlemlerini esnekçe yapar. / Zabbix'te hesaplamalar tetikleyici ifadeleri ve hesaplanmış öğelerle yapılır; analiz derinliği PromQL kadar esnek değildir.
• Alarm: Prometheus'ta alarm kuralları sunucuda değerlendirilir, bildirimler ayrı bir bileşen olan Alertmanager tarafından gruplanır ve yönlendirilir. / Zabbix'te tetikleyici, eylem ve eskalasyon kurgusu tek platform içindedir.
• Görselleştirme ve yapılandırma: Prometheus'un kendi arayüzü sorgu odaklıdır; panolar için yaygın olarak Grafana kullanılır, yapılandırma dosyalarla yapılır. / Zabbix panoları, grafikleri ve tüm yapılandırmayı web arayüzünde sunar.
• Depolama: Prometheus sunucuları dağıtık depolamaya bağımlı olmadan, veriyi yerelde tutarak özerk çalışır; uzun süreli saklama için ek çözümler gerekir. / Zabbix veriyi ilişkisel bir veritabanında saklar; geçmiş ve eğilim verisi kapasite planlamasında doğrudan kullanılır.

Küçük bir PromQL örneğiyle fark

Prometheus'un gücü, etiketli veriyi sorgu anında birleştirebilmesidir. Örneğin node exporter ile toplanan bellek metriklerinden kullanılabilir bellek oranını hesaplamak için şu ifade yeterlidir:

node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes

Bu sorgu, izlenen her makine için ayrı bir sonuç döner ve aynı etiketlerle filtrelenip gruplanabilir. Aynı oranı Zabbix'te görmek için genellikle hazır bir şablon öğesi kullanılır ya da hesaplanmış bir öğe tanımlanır. Fark şuradadır: Prometheus'ta yeni bir soru sormak yeni bir sorgu yazmak demektir; Zabbix'te ise genellikle yeni bir öğe ya da tetikleyici yapılandırmak gerekir.

Bu esneklik bir bedel de taşır. Etiket değerlerine kullanıcı kimliği ya da istek kimliği gibi sınırsız çeşitlilikteki değerler koymak, zaman serisi sayısını patlatır ve Prometheus'un performansını hızla düşürür. Etiket tasarımı Prometheus projelerinin en sık hata yapılan noktasıdır.

Hangi ortamda hangisi daha uygun?

Prometheus'un öne çıktığı durumlar: • Kubernetes ve konteyner tabanlı, hedeflerin sürekli değiştiği ortamlar • Uygulamaların kendi metriklerini bir HTTP uç noktasından yayımladığı mikroservis mimarileri • SRE ekiplerinin hizmet seviyesi göstergelerini esnek sorgularla hesaplamak istediği durumlar • Panoların ve alarm kurallarının kod olarak sürüm kontrolünde tutulması istendiğinde

Zabbix'in öne çıktığı durumlar: • Fiziksel ve sanal sunucular, depolama, ağ cihazları ve klasik kurumsal uygulamalardan oluşan altyapılar • SNMP ile anahtar, yönlendirici ve yazıcı gibi cihazların izlenmesi • Uzak şube ve lokasyonların proxy ile merkezi izlenmesi • İzleme ekibinin kod yerine web arayüzünden, şablonlarla çalışmayı tercih ettiği durumlar

Prometheus'un kendi belgeleri de bir sınırı açıkça belirtir: istek başına faturalama gibi tam doğruluk gerektiren işlerde Prometheus uygun bir seçim değildir; bu tür veri için ayrı bir sistem kullanılmalı, Prometheus izleme için kalmalıdır.

İki araçta da sık yapılan hatalar benzerdir: • Her metrik için alarm tanımlamak ve ekibi alarm yorgunluğuna sokmak; alarm yalnızca aksiyon gerektiren duruma bağlanmalıdır • Kısa süreli dalgalanmada alarm üretmek; Prometheus kurallarında bekleme süresi, Zabbix tetikleyicilerinde ise belirli bir aralıktaki değerlere bakan fonksiyonlar bu gürültüyü azaltır • Saklama süresini ve depolama kapasitesini baştan planlamamak • İzleme sisteminin kendisini izlememek; izleme durduğunda bunu fark edecek ayrı bir kontrol kurulmalıdır

Birlikte kullanım: tek panoda iki dünya

Karma altyapılı kurumlarda iki araç sıkça yan yana çalışır: altyapı ekibi sunucu ve ağ katmanını Zabbix ile, platform ve uygulama ekipleri Kubernetes iş yüklerini Prometheus ile izler. Bu durumda Grafana gibi bir görselleştirme katmanı, iki kaynaktan gelen veriyi aynı panoda gösterebilir.

Zabbix tarafında Prometheus biçimindeki metrikleri okumanın da yolu vardır: bir HTTP öğesi /metrics uç noktasından veriyi çeker, bağımlı öğeler ise Prometheus pattern ön işleme adımıyla ihtiyaç duyulan metriği ayıklar. Bu yöntem, Prometheus exporter'ı olan bir uygulamayı Zabbix'in alarm ve eskalasyon düzenine bağlamak için kullanışlıdır.

Birlikte kullanımda dikkat edilmesi gereken nokta, aynı olay için iki sistemden alarm gelmesini önlemektir. Hangi katmanın alarmının hangi araçtan, hangi ekibe gideceği baştan netleştirilmelidir.

Bu araçları Mindset programlarında nerede çalışırsınız?

Prometheus ve Grafana ile İzleme eğitimi, Prometheus mimarisi, PromQL sorgulama dili, exporter ve entegrasyonlar, Grafana dashboard tasarımı ile Alertmanager ve alarm yönetimi başlıklarıyla DevOps, SRE ve platform ekiplerine yöneliktir. Zabbix ile Kurumsal Altyapı İzleme eğitimi ise şablon tasarımı, düşük seviye keşif, tetikleyici ve eskalasyon ile ağ, veritabanı ve uygulama izleme başlıklarıyla sistem ve ağ operasyon ekipleri için kurgulanmıştır.

İzlemeyi metrikten öteye, log ve iz takibiyle bütünleşik bir gözlemlenebilirlik yaklaşımına taşımak isteyen ekipler için Gözlemlenebilirlik: Loglama, Metrik ve İz Takibi eğitimi, panolar, uyarılar ve nöbet ile kök neden analizi gibi konularla iki aracın yerini daha geniş bir mimari içinde değerlendirmeye yardımcı olur.