Zabbix’te Hazır Template ile Apache İzleme

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

Apache’yi Zabbix’te izlemek kulağa basit gelir, değil mi? Birkaç tıkla template seçersin, host’a eklersin, biter. Ama üretim ortamında bu kadar kolay gitmiyor. Template konfigürasyonunu eksik bırakırsan veri gelmez, mod_status açık değilse metrikler boş kalır, trigger eşikleri varsayılan haliyle kalırsa gecenin ikisinde gereksiz alarm alırsın. Bu yazıda sıfırdan başlayıp Apache izlemeyi Zabbix’te düzgün çalışır hale getireceğiz. Hem Linux tarafında ne yapılması gerektiğini, hem de Zabbix konfigürasyonunu adım adım geçeceğiz.

Temel Mimariyi Anlamak

Zabbix’in Apache template’i veri toplamak için iki farklı yönteme başvurur. Birincisi zabbix_agent2 üzerinden çalışan HTTP check’ler, ikincisi ise doğrudan mod_status çıktısını parse eden mekanizma. Hangisinin kullanıldığını anlamadan konfigürasyon yapmaya kalkarsan kafan karışır.

Apache Template for Zabbix Agent 2 (resmi ismiyle Apache by Zabbix agent 2) daha modern ve tercih edilen yöntem. Bu template ile Zabbix Agent 2, Apache’nin mod_status endpoint’ine HTTP isteği atıyor, gelen yanıtı parse ediyor ve metrikleri Zabbix server’a iletiyor. Klasik Zabbix Agent kullananlar için ise Apache by HTTP template mevcut, bu senaryo daha çok external check veya simple check mantığıyla çalışıyor.

Biz bu yazıda ağırlıklı olarak Zabbix Agent 2 senaryosunu işleyeceğiz çünkü 2024 itibarıyla artık agent 2’ye geçmemiş bir üretim ortamı görmek oldukça nadir.

Apache Tarafı: mod_status Kurulumu

Hiçbir şey yapmadan önce Apache’de mod_status‘un aktif olduğundan emin olmak gerekiyor. Pek çok dağıtımda modül yüklü geliyor ama endpoint kapalı oluyor.

Ubuntu/Debian Sistemlerde

# mod_status'un yüklü olup olmadığını kontrol et
apache2ctl -M | grep status

# Değilse etkinleştir
sudo a2enmod status

# Apache'yi yeniden başlat
sudo systemctl restart apache2

RHEL/CentOS/Rocky Linux Sistemlerde

# mod_status RHEL tabanlı sistemlerde genellikle zaten yüklü gelir
httpd -M | grep status_module

# Durum: status_module (shared) çıkmazsa
sudo dnf install mod_status   # veya yum install

Şimdi asıl konfigürasyon kısmına gelelim. mod_status endpoint’ini sadece localhost’tan erişilebilir şekilde ayarlamak hem güvenlik hem de Zabbix Agent 2’nin düzgün çalışması için şart.

mod_status Konfigürasyonu

Ubuntu/Debian’da /etc/apache2/mods-enabled/status.conf dosyasını düzenliyoruz. RHEL tabanlı sistemlerde /etc/httpd/conf.d/status.conf dosyası kullanılıyor.

<Location /server-status>
    SetHandler server-status
    Require local
    Require ip 127.0.0.1
    Require ip ::1
</Location>

# ExtendedStatus açık olmazsa çoğu metrik gelmiyor
ExtendedStatus On

Bu konfigürasyonu kaydedip Apache’yi yeniden başlattıktan sonra şunu test edebilirsin:

curl -s http://127.0.0.1/server-status?auto

Çıktı şuna benziyorsa her şey yolunda demektir:

Total Accesses: 1247
Total kBytes: 892
CPULoad: .00421
Uptime: 86400
ReqPerSec: .0144
BytesPerSec: 10.5
BytesPerReq: 729
BusyWorkers: 3
IdleWorkers: 22

Eğer 403 alıyorsan Require direktifini gözden geçir. ?auto parametresi Zabbix’in parse edebileceği düz metin formatında veri vermesi için kritik.

Zabbix Agent 2 Konfigürasyonu

Agent 2 kurulu olduğunu varsayıyorum. Değilse:

# Ubuntu/Debian
sudo apt install zabbix-agent2

# RHEL/CentOS/Rocky
sudo dnf install zabbix-agent2

Agent 2’nin Apache plugin’i için özel bir konfigürasyon parametresi gerekiyor. /etc/zabbix/zabbix_agent2.conf dosyasına veya /etc/zabbix/zabbix_agent2.d/ dizinine yeni bir dosya oluşturarak şunları ekliyoruz:

# /etc/zabbix/zabbix_agent2.d/apache.conf
Plugins.Apache.Sessions.Session.default.Url=http://127.0.0.1/server-status?auto
Plugins.Apache.Sessions.Session.default.User=
Plugins.Apache.Sessions.Session.default.Password=

Eğer Apache farklı bir portta çalışıyorsa (örneğin 8080):

Plugins.Apache.Sessions.Session.default.Url=http://127.0.0.1:8080/server-status?auto

Sonra agent’ı yeniden başlatıyoruz:

sudo systemctl restart zabbix-agent2
sudo systemctl status zabbix-agent2

Agent logunu takip etmek, sorun çıkarsa neyin yanlış gittiğini anlamana yardımcı olur:

tail -f /var/log/zabbix/zabbix_agent2.log

Zabbix Frontend: Template Ekleme

Şimdi Zabbix arayüzüne geçiyoruz.

Host Konfigürasyonu

Configuration > Hosts yolunu izle ve Apache çalışan sunucunu seç. Templates sekmesine geç. Arama kutusuna Apache yaz. Karşına birkaç seçenek çıkacak:

  • Apache by Zabbix agent 2: Önerilen, modern yaklaşım
  • Apache by HTTP: Agent 2 yoksa veya harici izleme istiyorsan
  • Apache by Zabbix agent: Eski agent kullanıyorsan

Biz Apache by Zabbix agent 2‘yi seçiyoruz. Update düğmesine basıp kaydediyoruz.

Makro Konfigürasyonu

Template’i ekledikten sonra host’un Macros sekmesine geçiyoruz. Default makrolar çoğu zaman yeterli, ama bazı durumlarda özelleştirmen gerekiyor:

  • {$APACHE.STATUS.HOST}: Varsayılan 127.0.0.1, farklı IP/hostname için değiştir
  • {$APACHE.STATUS.PORT}: Varsayılan 80, Apache farklı porttaysa güncelle
  • {$APACHE.STATUS.PATH}: Varsayılan server-status?auto
  • {$APACHE.RESPONSE_TIME.MAX.WARN}: Response time uyarı eşiği (saniye)
  • {$APACHE.PROCESS_NAME}: Process adı, genellikle apache2 veya httpd

RHEL tabanlı sistemlerde process adı httpd oluyor. Bunu makroda güncellemeyi unutursan process izleme item’ları veri göndermez.

# Sistemindeki Apache process adını kontrol et
ps aux | grep -E "apache2|httpd" | grep -v grep | head -1 | awk '{print $11}'

Veri Gelişini Doğrulama

Template ekledikten sonra hemen veri bekleme. Zabbix’in ilk veri toplaması biraz zaman alıyor. Şunu dene:

# Agent 2 üzerinden doğrudan test
zabbix_agent2 -t apache.status[default]

Çıktıda JSON formatında metrikler geliyorsa agent-Apache bağlantısı çalışıyor demektir. Eğer hata alıyorsan:

# Bağlantıyı manuel test et
curl -v http://127.0.0.1/server-status?auto

# Apache erişim logunda isteğin görünüp görünmediğini kontrol et
tail -f /var/log/apache2/access.log   # veya /var/log/httpd/access_log

Zabbix frontend’inde Monitoring > Latest data bölümüne git, host’u filtrele ve apache ile başlayan item’ları ara. İlk 10-15 dakika içinde veri dolmaya başlamalı.

Template’in İzlediği Temel Metrikler

Zabbix’in Apache template’i oldukça kapsamlı metrikler topluyor. Öne çıkanları şöyle sıralayabilirim:

  • Apache: Uptime: Servisin ne zamandır ayakta olduğu
  • Apache: Total requests per second: Saniyedeki istek sayısı, trafik trendi için kritik
  • Apache: Bytes per second: Saniyede transfer edilen veri
  • Apache: Workers busy: Aktif worker sayısı, kapasite planlaması için önemli
  • Apache: Workers idle: Boştaki worker sayısı, anlık durum tespiti için
  • Apache: Connections total: Toplam bağlantı sayısı
  • Apache: CPU load: Apache’nin CPU kullanımı (ExtendedStatus On gerektiriyor)
  • Apache: Version: Apache sürüm bilgisi
  • Apache: Service response time: HTTP endpoint yanıt süresi
  • Apache: Service status: Servisin up/down durumu
  • Apache: Process: Number of running processes: Çalışan process sayısı

Bu metrikler içinde Workers busy ve Workers idle ikilisi operasyonel açıdan en değerlileri. İdeal bir ortamda Workers idle her zaman sıfırın üstünde olmalı. Sıfıra yaklaşırsa Apache yeni bağlantıları kuyruğa almaya başlar, bu da kullanıcılar için yavaşlama anlamına gelir.

Trigger’ları Özelleştirme

Default trigger’lar iyi bir başlangıç noktası ama üretimde doğrudan kullanmak çoğu zaman sorun çıkarıyor. Özellikle düşük trafikli gecelerde bile “Workers busy” trigger’ı ateşlenebiliyor.

Configuration > Hosts > [Host Adı] > Triggers yolunu izleyip template’den gelen trigger’ları görebilirsin. Bunları doğrudan değiştirmek yerine host seviyesinde override oluşturmak daha temiz bir yaklaşım.

En sık özelleştirilen trigger’lar:

Apache: Service is down
- Varsayılan: Hemen tetiklenir
- Öneri: 3 kez üst üste başarısız olursa tetikle (flapping önlemi)

Apache: Workers busy is too high
- Varsayılan: %80 üstünde uyarı
- Öneri: Sunucunun MaxRequestWorkers değerine göre ayarla

Custom Trigger Örneği

Apache’de MaxRequestWorkers değeri 150 olarak ayarlanmış bir sunucu için:

Expression: min(/[Host Adı]/apache.workers[busy],5m) > 120
Name: Apache: Worker saturation yüksek (5 dakika sürdü)
Severity: High

Buradaki mantık şu: Ani bir spike’ta alarm almak istemiyoruz. 5 dakika boyunca sustained şekilde yüksek kalan worker sayısı gerçek bir sorunun işareti.

Gerçek Dünya Senaryosu: Worker Tükenmesi Tespiti

Geçen yıl yaşadığım bir durumu paylaşayım. E-ticaret sitesi, kampanya günü öğleden sonra yavaşlamaya başladı. Zabbix dashboard’una bakınca Workers busy grafiği son 30 dakikada neredeyse düz çizgi halinde 148 seviyesinde seyrediyordu (MaxRequestWorkers: 150). Workers idle sıfıra inmişti.

Şunu çalıştırdım:

# Anlık worker durumunu detaylı görmek için
curl -s http://127.0.0.1/server-status | grep -E "^(Busy|Idle|Scoreboard)"

# Hangi URL'lerin işlendiğini görmek için
curl -s http://127.0.0.1/server-status | grep "GET|POST|PUT"

Çıktıda onlarca istek aynı yavaş çalışan API endpoint’ini bekliyordu. Sorun Apache’de değil, backend servisin yavaş yanıt vermesindeydi. Apache worker’ları yanıt beklerken bloklanıyordu.

Zabbix olmasaydı bunu anlık tespit etmek çok daha uzun sürerdi. Template’in verdiği görünürlük sayesinde sorunu 5 dakika içinde teşhis ettik.

MPM Moduna Göre Dikkat Edilmesi Gerekenler

Apache’nin hangi MPM (Multi-Processing Module) ile çalıştığı izleme stratejisini etkiliyor.

# Aktif MPM'yi kontrol et
apache2ctl -V | grep MPM
# veya
httpd -V | grep MPM

Prefork MPM kullanıyorsan her worker ayrı bir process. BusyWorkers ve IdleWorkers değerleri doğrudan process sayısını yansıtıyor.

Worker veya Event MPM kullanıyorsan thread tabanlı mimari devrede. Bu durumda Workers busy daha az kritik, bağlantı bazlı metrikler daha önemli hale geliyor.

Event MPM kullanan sistemlerde şu ek konfigürasyon mod_status çıktısını zenginleştiriyor:

# /etc/apache2/conf-enabled/status.conf veya /etc/httpd/conf.d/status.conf
<Location /server-status>
    SetHandler server-status
    Require local
</Location>

ExtendedStatus On
<IfModule mod_status.c>
    <IfModule mpm_event_module>
        # Event MPM için ek bilgi
    </IfModule>
</IfModule>

Güvenlik: server-status Endpoint’ini Koruma

mod_status endpoint’i sunucu hakkında ciddi bilgi veriyor. Yanlışlıkla dış dünyaya açılırsa sorun çıkar. Bunu düzenli kontrol etmek iyi bir alışkanlık:

# Dışarıdan erişilip erişilemediğini test et
# Başka bir makineden veya curl üzerinden harici IP ile dene
curl -I http://[SUNUCU_IP]/server-status

# 403 Forbidden alman gerekiyor
# 200 alıyorsan konfigürasyonu gözden geçir

Eğer Zabbix server ile izlenen host farklı makinelerdeyse ve Zabbix server’ın IP’sini Require ip direktifine eklemen gerekiyorsa, bunu güvenlik duvarı kurallarıyla da desteklemeyi düşün:

# Sadece Zabbix server'dan erişime izin ver (iptables örneği)
sudo iptables -A INPUT -p tcp --dport 80 -s [ZABBIX_SERVER_IP] -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 80 -s 127.0.0.1 -j ACCEPT

Dashboard Kurulumu

Veri toplandıktan sonra anlamlı bir dashboard oluşturmak izlemenin görsel katmanını tamamlıyor.

Monitoring > Dashboards üzerinden yeni bir dashboard oluştur. Apache için önerdiğim widget düzeni:

  • Graph widget: Workers busy vs idle (son 1 saat)
  • Graph widget: Requests per second (son 24 saat, trafik trendi)
  • Graph widget: Response time (son 1 saat)
  • Problems widget: Apache ile ilgili aktif problem’lar
  • Item value widget: Current uptime

Workers busy ve Workers idle grafiğini yan yana koyduğunda kapasite durumu tek bakışta anlaşılıyor.

Sık Karşılaşılan Sorunlar ve Çözümleri

Sorun: Item’lar “Not supported” durumunda

# Agent 2'nin Apache plugin'ini tanıyıp tanımadığını kontrol et
zabbix_agent2 -t apache.status[default] 2>&1

# Konfigürasyon dosyasının doğru okunduğunu doğrula
zabbix_agent2 -T 2>&1 | grep -i apache

Sorun: Metrikler geliyor ama bazıları eksik

ExtendedStatus On satırının Apache konfigürasyonunda aktif olduğunu ve Apache yeniden başlatıldığını doğrula. CPU load gibi bazı metrikler extended status olmadan toplanamıyor.

# ExtendedStatus durumunu kontrol et
curl -s http://127.0.0.1/server-status?auto | grep -i cpu
# Çıktı boşsa ExtendedStatus kapalı demektir

Sorun: Response time item’ı sürekli yüksek görünüyor

# Agent üzerinden response time'ı manuel test et
time curl -s http://127.0.0.1/server-status?auto > /dev/null

100ms üstünde çıkıyorsa Apache’nin lokal performansında sorun var olabilir. Ama çoğu zaman bu, test ortamlarında Apache’nin az yük altında olduğu için connection overhead’ının ölçüme yansımasından kaynaklanıyor.

Log İzlemeyi Entegre Etmek

Template’in verdiği metrik izleme yetmez, log izlemeyi de entegre etmek tam resmi gösteriyor. Zabbix’in log monitoring özelliğiyle Apache error log’unu da takibe alabiliriz:

# zabbix_agent2.conf veya ayrı bir conf dosyasına ekle
UserParameter=apache.error.log.count,grep -c "$(date +'%a %b %d')" /var/log/apache2/error.log 2>/dev/null || echo 0

Daha sofistike bir yaklaşım için Zabbix’in log[] item type’ını kullanmak mümkün:

Type: Zabbix agent (active)
Key: log[/var/log/apache2/error.log,"error|crit|emerg",,,skip]

Bu item, error log’unda kritik seviye mesajlar görününce tetiklenecek trigger’larla birleştirilebilir.

Kapasite Planlaması için Tarihsel Veri

Zabbix’in gerçek gücü anlık izlemede değil, tarihsel veri analizinde ortaya çıkıyor. Workers busy‘nin son 30 günlük ortalamasına bakarak maksimum kapasitenin ne kadar dolu olduğunu görebilirsin.

Reports > Action log veya direkt Monitoring > Latest data üzerinden item’ı seçip “Graph” görünümüne geç. “Fixed period” olarak son 30 günü seç.

Eğer gündüz saatlerinde Workers busy tutarlı şekilde MaxRequestWorkers‘ın %70 üstünde seyrediyorsa, kapasite artırımı için somut veriye sahipsin demektir. Bu tür verileri üst yönetime sunarken “sezgimize göre sunucu yavaş” yerine “30 günlük veri gösteriyor ki iş saatlerinde worker doluluk oranı ortalama %73” demek çok daha ikna edici oluyor.

Sonuç

Zabbix’te Apache izlemeyi doğru kurgulamak üç katmanlı bir iş. Birinci katman Apache’nin kendisi: mod_status açık, ExtendedStatus aktif, endpoint sadece localhost’a açık. İkinci katman Zabbix Agent 2: plugin konfigürasyonu eksiksiz, doğru URL ve port ayarlı. Üçüncü katman Zabbix frontend: template makroları sunucuya özgü (özellikle RHEL’de process adı httpd), trigger eşikleri gerçekçi değerlere çekilmiş.

Bu üç katmanın hepsi düzgün çalışınca Apache’nin durumu hakkında gerçek zamanlı ve tarihsel görünürlük elde ediyorsun. Worker tükenmeleri, response time artışları ve servis kesintileri artık sürpriz olmaktan çıkıyor. Kampanya dönemlerinde kapasite planlaması yapabilir, gece yarısı alarm aldığında Zabbix’in verdiği bağlam sayesinde çok daha hızlı müdahale edebilirsin.

Template’i kurup bırakmak yerine ilk birkaç hafta içinde trigger’ları kendi ortamına göre kalibre etmeye zaman ayır. Varsayılan eşikler genel amaçlı hazırlanmış, senin üretim ortamının davranışını yansıtmıyor. O kalibrasyonu yaptıktan sonra Zabbix sana gerçekten işe yarar sinyal verir, gürültü değil.

Bir yanıt yazın

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