Zabbix 7.x ile Kubernetes Cluster Monitoring

Kubernetes ekosisteminde monitoring denildiğinde akla ilk gelen Prometheus-Grafana ikilisi olsa da, modern devops dünyasında zabbix 7.x sürümüyle kartları yeniden dağıtıyor. Bu yazımızda, legacy sistemlerden aşina olduğumuz bu devasa canavarın, kubernetes cluster’larındaki container metriklerini auto-discovery (LLD) yetenekleriyle nasıl saniyeler içinde yakaladığını, verileri nasıl işlediğini ve Grafana ile nasıl görselleştirdiğini ele alacağız. “Prometheus kurduk ama RAM tüketimi ocağımıza incir ağacı dikti” diyenlerdenseniz, kemerlerinizi bağlayın; Zabbix 7.x’in hafif ve güçlü Kubernetes entegrasyonuna dalıyoruz.

Neden Zabbix 7.x? (Eski Dostun Yeni Numaraları)

Yıllarca Zabbix’i sadece VM’lerin CPU ve disk doluluk oranlarını izlemek için kullandıysanız, kendinizi güncellemenin vakti geldi demektir. Zabbix 7.x, Kubernetes dünyasını yabancı bir gezegen gibi görmüyor. HTTP agent, out-of-the-box gelen gelişmiş Kubernetes template’leri ve JSONPath preprocessing yetenekleri sayesinde API Server üzerinden doğrudan cluster’ın kalbine inebiliyor.

Peki neden Prometheus yerine Zabbix? Cevap basit: Unified Monitoring ve Uzun Vadeli Veri Saklama (Long-term Retention). Eğer cluster dışında fiziksel switch’leriniz, legacy veritabanlarınız ve sanal makineleriniz varsa, hepsini tek bir panele toplamak ve bunu yaparken TSDB (Time Series Database) kaynaklı çılgın RAM maliyetlerinden kaçınmak istiyorsanız, Zabbix 7.x tam size göre.

Adım 1: Kubernetes Cluster Üzerinde Zabbix Helm Deployment

Zabbix’in cluster içindeki gözü kulağı olacak Zabbix Agent 2 ve Zabbix Proxy yapılandırmasını kurarak işe başlıyoruz. Kubernetes API’si ile güvenli bir şekilde konuşabilmek için service account ve rol tanımlamalarına ihtiyacımız var. Neyse ki resmi Helm chart bu işi bizim yerimize hallediyor.

İlk olarak Zabbix topluluk reposunu sistemimize ekleyelim:

helm repo add zabbix-community https://zabbix-community.github.io/helm-charts
helm repo update

Şimdi, cluster metriklerini toplamak için optimize edilmiş bir values.yaml dosyası hazırlayalım. Bu dosyada Zabbix Server adresimizi ve cluster adımızı belirtiyoruz. Aşağıdaki konfigürasyonu zabbix-values.yaml olarak kaydedebilirsiniz:

zabbixProxy:
  enabled: true
  resources:
    limits:
      cpu: 500m
      memory: 512Mi
    requests:
      cpu: 100m
      memory: 128Mi
  env:
    - name: ZBX_HOSTNAME
      value: "k8s-production-proxy"
    - name: ZBX_SERVER_HOST
      value: "zabbix-server.kertenkerem.local" # Zabbix Server IP veya FQDN'iniz

zabbixAgent:
  enabled: true
  resources:
    limits:
      cpu: 200m
      memory: 256Mi
    requests:
      cpu: 50m
      memory: 64Mi
  env:
    - name: ZBX_HOSTNAMEITEM
      value: "system.hostname"

Bu konfigürasyon ile cluster içinde bir DaemonSet olarak Zabbix Agent 2 ve cluster dışındaki ana sunucumuza verileri güvenli ve sıkıştırılmış şekilde iletecek bir Zabbix Proxy ayağa kaldırıyoruz. Kurulumu şu komutla tetikleyelim:

kubectl create namespace monitoring
helm install zabbix zabbix-community/zabbix-helm-ch --namespace monitoring -f zabbix-values.yaml

Adım 2: Auto-Discovery (LLD) ile Metrik Avcılığı

Kubernetes dinamik bir yapıya sahiptir; pod’lar saniyeler içinde ölür, yenileri doğar. Statik IP’ler veya host tanımlamaları burada sökmez. Zabbix 7.x, bu kaosu çözmek için Low-Level Discovery (LLD) mekanizmasını kullanır. Kubernetes API Server üzerinden pods, nodes, namespaces ve services discovery kurallarını çalıştırır.

Zabbix Web UI arayüzüne giriş yaptıktan sonra şu adımları izleyin:

1. API Token Oluşturma

Zabbix Server’ın cluster API’si ile konuşabilmesi için Helm kurulumu sırasında otomatik oluşturulan service account token’ını almamız gerekiyor:

kubectl get secret $(kubectl get serviceaccount zabbix-service-account -n monitoring -o jsonpath="{.secrets[0].name}") -n monitoring -o jsonpath="{.data.token}" | base64 --decode

Not: Kubernetes 1.24 ve üzeri kullanıyorsanız, secret manuel oluşturulmuş olabilir. Helm chart bunu sizin için halletmediyse, service account için bir `kubernetes.io/service-account-token` tipinde Secret oluşturup token’ı oradan okumalısınız.

2. Zabbix Üzerinde Host Tanımlama

• Configuration -> Hosts -> Create Host yolunu izleyin.
• Host Name alanına Kubernetes Cluster Production yazın.
• Templates kısmına “Kubernetes by HTTP” template’ini ekleyin. Bu template, Zabbix 7.0 ile gelen out-of-the-box harika bir canavardır.
• Macros sekmesine geçiş yapın ve aşağıdaki kritik değişkenleri tanımlayın:

{$KUBE.API.URL} -> https://<kubernetes-api-endpoint>:6443
{$KUBE.API.TOKEN} -> <Bir önceki adımda elde ettiğiniz token>

Bu tanımlamadan sonra Zabbix, HTTP agent yardımıyla cluster API’nize sorgu atmaya başlayacak. Birkaç dakika içinde “Discovery rules” altındaki kuralların tetiklendiğini ve cluster’ınızdaki tüm node’ların, pod’ların ve container’ların otomatik olarak sisteme “Graph” ve “Item” olarak eklendiğini göreceksiniz. İşte auto-discovery’nin gücü!

Adım 3: Grafana Entegrasyonu (Görsel Şölen)

Zabbix’in kendi arayüzündeki grafikler son yıllarda iyileşmiş olsa da, hiçbirimiz yöneticilerimize veya development ekiplerine o 90’lardan kalma görünümlü panelleri göstermek istemeyiz. Bize Grafana lazım.

Grafana üzerinde Zabbix veri kaynağını (datasource) aktifleştirmek için şu adımları izliyoruz:

grafana-cli plugins install alexanderzobnin-zabbix-app
systemctl restart grafana-server

Grafana arayüzüne gidip Connections -> Data Sources -> Add New Data Source dedikten sonra listeden Zabbix’i seçiyoruz. Konfigürasyon ayarlarında dikkat etmeniz gereken kritik noktalar şunlar:

• URL: http://zabbix-server-ip/zabbix/api_jsonrpc.php
• Access: Server (Default)
• Zabbix API Connection: Zabbix admin kullanıcı adı ve şifreniz.

Bağlantıyı test edip kaydettikten sonra, Kubernetes cluster metriklerimizi içeren dashboard’ları tasarlayabiliriz. Örneğin, her pod’un CPU tüketimini dinamik olarak çeken bir panel yazmak istersek, Grafana query alanına şu regex’i girebiliriz:

Group: Kubernetes
Host: /.*/
Application: CPU
Item: /Calculated CPU usage percent/

Bu sorgu sayesinde, cluster’a yeni bir mikroservis deploy edildiğinde hiçbir manuel müdahale yapmadan o servisin CPU grafiği saniyeler içinde Grafana panelinizde belirecektir.

Adım 4: Akıllı Alerting Kuralları

Gecenin saat 3’ünde “Pod restart attı” diye uyanmak istemiyorsanız, Zabbix’in esnek trigger yapısını doğru kurgulamanız gerekir. Klasik CPU doldu alert’leri yerine Kubernetes dünyasına uygun akıllı trigger’lar yazmalıyız.

Örnek 1: CrashLoopBackOff Durumu tespiti

Bir pod sürekli hata alıp kapanıyorsa ve restart sayısı artıyorsa, bu kritik bir durumdur. Zabbix template’i içinde gelen varsayılan kuralı özelleştirebiliriz:

last(/Kubernetes by HTTP/kube.pod.restart_rate[{#POD.NAME}]) > 3 and last(/Kubernetes by HTTP/kube.pod.status[{#POD.NAME}]) = 0

Bu trigger, pod’un son 5 dakika içindeki restart hızı 3’ten fazla ise ve pod “Ready” durumunda değilse alarm üretir. Geçici network kesintilerinde boşuna Slack kanallarınızı spam’lemez.

Örnek 2: Node Disk Basıncı (Disk Pressure)

Kubelet’in node üzerindeki pod’ları evict etmeye başlamadan (yani sistem dışına atmadan) önce diskin dolduğunu anlamamız gerekir:

last(/Kubernetes by HTTP/kube.node.status.disk_pressure[{#NODE.NAME}]) = 1

Bu alarm tetiklendiğinde, Zabbix’in Webhook entegrasyonu sayesinde Slack veya PagerDuty üzerinden anlık bildirim alabilir, hatta otomatik aksiyon (Remote Command) tanımlayarak ilgili node üzerindeki gereksiz docker imajlarını temizleyen bir script çalıştırabilirsiniz.

Zabbix 7.x Kubernetes Monitoring’in Avantaj ve Dezavantajları

Her sistemde olduğu gibi bu mimarinin de güçlü ve zayıf yanları var. Kararınızı vermeden önce bunları masaya yatıralım:

Avantajları	Dezavantajları
Düşük kaynak tüketimi (RAM/CPU dostu)	Kubernetes native olmaması (Prometheus operator kadar cluster içine entegre değil)
Merkezi yönetim ve güçlü LLD yetenekleri	Custom Metric API ile HPA (Horizontal Pod Autoscaler) entegrasyonu görece zor
Uzun vadeli verileri saklamada veritabanı esnekliği (PostgreSQL/TimescaleDB)	Grafana template kütüphanesinin Prometheus kadar zengin olmaması

Sonuç

Zabbix 7.x, Kubernetes cluster’larını izlemek için hantal ve “outdated” bir çözüm olmaktan çok uzak. Aksine, kaynak tüketimini minimize etmek isteyen ve tüm IT altyapısını (fiziksel, sanal, container) tek bir merkezi noktadan yönetmeyi hedefleyen kıdemli sistem ve devops mühendisleri için biçilmiş kaftan. Auto-discovery mekanizmasının gücü ve Grafana’nın görsel yetenekleri birleştiğinde, production ortamınızda uçtan uca izlenebilirlik (observability) sağlamak işten bile değil.

Siz de cluster’larınızda Zabbix kullanmayı denediniz mi? Yaşadığınız tecrübeleri veya takıldığınız yerleri yorumlarda bizimle paylaşın, debugging seansına beraber devam edelim!