Zabbix ile Web Sitesi ve URL İzleme

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

Üretim ortamındaki bir web sitesi beklenmedik bir anda yanıt vermeyi bıraktığında, bunu ilk öğrenen kişinin müşteri olmaması için elimizden geleni yaparız. Zabbix’in web izleme modülü tam da bu noktada devreye giriyor: sadece sunucunun ayakta olup olmadığını değil, gerçek kullanıcı deneyimini simüle ederek uçtan uca bir görünürlük sağlıyor.

Bu yazıda Zabbix ile URL ve web sitesi izlemeyi sıfırdan kuruyoruz. Basit HTTP check’lerden çok adımlı senaryo testlerine, response time eşik değerlerinden özel alert kurallarına kadar tüm süreci gerçek üretim senaryolarıyla ele alacağım.

Zabbix Web İzlemenin Temel Mantığı

Zabbix’te web izleme iki farklı katmanda çalışıyor. Birincisi basit HTTP/HTTPS check’leri, yani bir URL’ye istek atıp 200 döndürüyor mu diye bakmak. İkincisi ise “web scenarios” olarak adlandırılan, birden fazla adımdan oluşan senaryo tabanlı testler. Bu ikisi çok farklı kullanım alanlarına hitap ediyor ve ikisini de doğru yerde kullanmak önemli.

Basit URL check için Zabbix’in web.test.rspcode[] gibi built-in item’larını kullanabilirsiniz. Ama eğer bir kullanıcının siteye girip login olmasını, sepete ürün eklemesini ve ödeme sayfasına geçmesini test etmek istiyorsanız, senaryolara ihtiyaç duyarsınız.

Zabbix web izlemenin avantajları:

  • Harici bir araç gerektirmez, Zabbix agent’a bile gerek kalmaz (agentless çalışır)
  • HTTP, HTTPS, ve authentication destekler
  • Response time, status code ve içerik doğrulama aynı anda yapılabilir
  • Zabbix’in alarm altyapısıyla doğrudan entegre olur

İlk Adım: Basit HTTP İzleme Kurulumu

Zabbix arayüzünden Configuration > Hosts yolunu izleyin ve izlemek istediğiniz host’u açın. Eğer web sitesi için ayrı bir host yoksa, “Create host” ile yeni bir host oluşturmanızı öneririm. Host’un IP veya DNS adresini ilgili interface’e ekleyebilirsiniz ama web testleri için bu zorunlu değil.

Host sayfasında Web sekmesine gidin ve Create web scenario butonuna basın.

Temel bir senaryo şöyle görünüyor:

# Zabbix API üzerinden web scenario oluşturmak isterseniz:
curl -s -X POST http://zabbix.sirketiniz.com/api_jsonrpc.php 
  -H "Content-Type: application/json" 
  -d '{
    "jsonrpc": "2.0",
    "method": "httptest.create",
    "params": {
      "name": "Ana Sayfa Kontrolu",
      "hostid": "10084",
      "steps": [
        {
          "name": "Ana Sayfa Acilis",
          "url": "https://www.sirketiniz.com",
          "status_codes": "200",
          "no": "1"
        }
      ]
    },
    "auth": "API_TOKEN_BURAYA",
    "id": 1
  }'

Bu API çağrısı işe yarıyor ama çoğu zaman arayüzden yapmak daha hızlı. Asıl güç, adım adım senaryolarda gizli.

Çok Adımlı Senaryo: Login Akışı Testi

E-ticaret sitelerinde en kritik akış login ve checkout sürecidir. Bunu Zabbix ile nasıl test edeceğimizi görelim:

# Web scenario için curl benzeri mantık:
# Adım 1: Ana sayfayı aç, CSRF token'ı yakala
# Adım 2: Login formunu gönder
# Adım 3: Dashboard'a yönlendirildiğini doğrula

# Zabbix API ile çok adımlı senaryo:
curl -s -X POST http://zabbix.sirketiniz.com/api_jsonrpc.php 
  -H "Content-Type: application/json" 
  -d '{
    "jsonrpc": "2.0",
    "method": "httptest.create",
    "params": {
      "name": "Login Akisi Testi",
      "hostid": "10084",
      "delay": "120",
      "retries": "2",
      "steps": [
        {
          "name": "Login Sayfasi",
          "url": "https://www.sirketiniz.com/login",
          "status_codes": "200",
          "required": "Kullanici Adi",
          "no": "1"
        },
        {
          "name": "Login Islemi",
          "url": "https://www.sirketiniz.com/login",
          "posts": "username=test_user&password=test_pass&_token={test.csrf}",
          "status_codes": "200,302",
          "no": "2"
        },
        {
          "name": "Dashboard Dogrulama",
          "url": "https://www.sirketiniz.com/dashboard",
          "status_codes": "200",
          "required": "Hosgeldiniz",
          "no": "3"
        }
      ]
    },
    "auth": "API_TOKEN_BURAYA",
    "id": 1
  }'

Burada dikkat edilmesi gereken nokta required alanı. Bu alan, sayfanın döndürdüğü HTML içinde belirtilen metnin var olup olmadığını kontrol ediyor. HTTP 200 dönse bile içerikte “Hosgeldiniz” yoksa test başarısız sayılıyor. Bu özellik sayesinde sahte 200 yanıtlarını yakalayabiliyorsunuz.

Response Time İzleme ve Eşik Değerleri

Bir site ayakta olabilir ama 8 saniyede yükleniyorsa kullanıcılar çoktan gitmiş olur. Zabbix web senaryoları otomatik olarak şu metrikleri toplar:

web.test.time[senaryo_adi,adim_adi,resp] – Belirli bir adımın yanıt süresi web.test.time[senaryo_adi,,total] – Toplam senaryo süresi web.test.rspcode[senaryo_adi,adim_adi] – HTTP durum kodu web.test.error[senaryo_adi] – Son hata mesajı web.test.fail[senaryo_adi] – Başarısız adım numarası (0 = başarılı)

Bu metrikleri trigger’lara bağlamak için şöyle bir yaklaşım işe yarıyor:

# Zabbix trigger expression örnekleri
# (Bu ifadeleri Trigger configuration ekranına yazabilirsiniz)

# 3 saniyeden uzun süren response time için alert:
{www.sirketiniz.com:web.test.time[Login Akisi Testi,,total].last()}>3

# 5 dakika içinde 2 kez başarısız olursa:
{www.sirketiniz.com:web.test.fail[Login Akisi Testi].min(5m)}>0

# HTTP 200 dışında bir kod gelirse:
{www.sirketiniz.com:web.test.rspcode[Login Akisi Testi,Ana Sayfa Acilis].last()}<>200

HTTPS Sertifika İzleme

SSL sertifikası sona erince mail sunucularından tutun bankacılık uygulamalarına kadar her şey çöküyor. Zabbix 5.0 ve üzerinde built-in sertifika kontrolü geldi ama daha esnek bir yaklaşım için şu yöntemi kullanıyorum:

#!/bin/bash
# /etc/zabbix/scripts/ssl_check.sh
# Bu scripti Zabbix external check olarak kullanabilirsiniz

DOMAIN=$1
PORT=${2:-443}

SSL_INFO=$(echo | openssl s_client -servername $DOMAIN 
  -connect $DOMAIN:$PORT 2>/dev/null | 
  openssl x509 -noout -dates 2>/dev/null)

if [ $? -ne 0 ]; then
  echo "-1"
  exit 0
fi

EXPIRY_DATE=$(echo "$SSL_INFO" | grep "notAfter" | cut -d'=' -f2)
EXPIRY_EPOCH=$(date -d "$EXPIRY_DATE" +%s 2>/dev/null)
NOW_EPOCH=$(date +%s)

DAYS_LEFT=$(( ($EXPIRY_EPOCH - $NOW_EPOCH) / 86400 ))
echo $DAYS_LEFT

Bu scripti Zabbix’e entegre etmek için:

# /etc/zabbix/zabbix_agentd.conf veya userparameter dosyasına ekleyin:
UserParameter=ssl.cert.days[*],/etc/zabbix/scripts/ssl_check.sh $1 $2

# Script'in çalıştırılabilir olduğundan emin olun:
chmod +x /etc/zabbix/scripts/ssl_check.sh
chown zabbix:zabbix /etc/zabbix/scripts/ssl_check.sh

# Agent'ı yeniden başlatın:
systemctl restart zabbix-agent

Trigger olaraksa şunu kullanıyorum: Sertifika 30 günden az kalmışsa Warning, 7 günden az kalmışsa High severity. Bu şekilde sürprizlerden kaçınılıyor.

Proxy Üzerinden İzleme

Türkiye’deki bazı müşterilerimin siteleri CDN arkasında çalışıyor. Bu durumda Zabbix server’ın yaptığı testler gerçek kullanıcı deneyimini yansıtmıyor. Çözüm: Zabbix Proxy’yi kullanıcıların bulunduğu ağ segmentine veya coğrafi bölgeye kurmak.

Örneğin İstanbul’daki ofis ağından, Ankara veri merkezinden ve yurt dışı bir cloud instance’dan aynı senaryoyu çalıştırabilirsiniz:

# Zabbix Proxy kurulumu (Debian/Ubuntu)
apt-get install zabbix-proxy-mysql

# /etc/zabbix/zabbix_proxy.conf temel ayarları:
Server=zabbix.sirketiniz.com
Hostname=proxy-istanbul-01
DBHost=localhost
DBName=zabbix_proxy
DBUser=zabbix
DBPassword=guclu_sifre_buraya

# Web scenario'yu proxy üzerinden çalıştırmak için
# host configuration'da proxy seçeneğini belirleyin

Bu yapıyla farklı lokasyonlardan response time karşılaştırması yapabilir, CDN’in düzgün çalışıp çalışmadığını anlayabilirsiniz.

Kimlik Doğrulama Gerektiren Endpoint’ler

REST API izleme konusu genellikle gözden kaçıyor. Microservice mimarisine geçen ekiplerde her servisin sağlık durumunu izlemek kritik. JWT veya Basic Auth gerektiren endpoint’ler için şu yaklaşımı kullanıyorum:

# Zabbix web scenario adımı - Bearer token ile API kontrolü
# Senaryo adı: "Payment Service Health Check"
# Adım 1: Token Al

URL: https://auth.sirketiniz.com/token
Method: POST
Post type: Raw data
Raw post: {"username":"monitor_user","password":"monitor_pass"}
Headers: Content-Type: application/json
Required string: "access_token"

# Adım 2: Token ile API Çağrısı
URL: https://api.sirketiniz.com/v1/health
Headers: Authorization: Bearer {token_buraya}
Status codes: 200
Required: "status":"ok"

Gerçek dünyada token’ı bir adımdan diğerine aktarmak için Zabbix’in variable extraction özelliğini kullanıyorsunuz. {token_ismi} şeklinde değişken tanımlayıp regex ile response’dan çekiyorsunuz.

Toplu URL İzleme: Template Yaklaşımı

Onlarca URL’yi tek tek eklemek yerine template oluşturup host’lara bağlamak çok daha temiz bir yöntem. Özellikle benzer yapıdaki siteleri yönetiyorsanız:

# Zabbix API ile template'e web scenario eklemek:
curl -s -X POST http://zabbix.sirketiniz.com/api_jsonrpc.php 
  -H "Content-Type: application/json" 
  -d '{
    "jsonrpc": "2.0",
    "method": "httptest.create",
    "params": {
      "name": "Standart Web Kontrolu",
      "hostid": "TEMPLATE_ID_BURAYA",
      "delay": "60",
      "retries": "3",
      "headers": [
        {
          "name": "User-Agent",
          "value": "Zabbix Web Monitor 1.0"
        }
      ],
      "steps": [
        {
          "name": "Ana Sayfa",
          "url": "{$SITE_URL}",
          "timeout": "15",
          "status_codes": "200",
          "required": "{$REQUIRED_TEXT}",
          "no": "1"
        }
      ]
    },
    "auth": "API_TOKEN_BURAYA",
    "id": 1
  }'

Burada {$SITE_URL} ve {$REQUIRED_TEXT} host macro’larıdır. Her host için bu değerleri farklı ayarlarsınız. Template bir kez oluşturursunuz, yüzlerce siteye uygularsınız.

Alert Yorgunluğunu Önleme: Akıllı Trigger Tasarımı

Yanlış konfigüre edilmiş web izleme, gece 3’te “ana sayfa 201ms geç yüklendi” diye alarm verir. Bu durumu yaşayan herkes ne demek istediğimi anlar. Alert yorgunluğu gerçek sorunların gözden kaçmasına yol açar.

Akıllı trigger tasarımı için birkaç pratiğimi paylaşayım:

Zaman tabanlı filtre kullanın. Bakım saatleri için maintenance period tanımlayın. Zabbix’te Configuration > Maintenance bölümünden belirli saat aralıklarını alarm dışı bırakabilirsiniz.

Severity seviyeleri doğru belirleyin:

  • Ana sayfanın 5 saniye üzerinde yüklenmesi: Warning
  • Ana sayfanın 15 saniye üzerinde yüklenmesi: High
  • Ana sayfa hiç açılmıyor: Disaster
  • Sertifika 30 gün: Information
  • Sertifika 7 gün: High

Flapping önleme için min() fonksiyonu kullanın. Tek bir başarısız check’te alarm vermek yerine, son 5 dakikada 3 kez başarısız olduysa alarm verin.

# Daha güvenilir trigger ifadesi:
# Son 5 dakikada toplam sürenin ortalaması 5 saniyeyi geçtiyse:
{www.sirketiniz.com:web.test.time[Login Akisi Testi,,total].avg(5m)}>5

# Son 3 check'te hep başarısız olduysa:
{www.sirketiniz.com:web.test.fail[Login Akisi Testi].min(#3)}>0

Dashboard’da Web İzleme Metrikleri

Zabbix 6.x ile gelen yeni dashboard widget’ları, web izleme metriklerini görselleştirmek için oldukça kullanışlı. Özellikle “Graph” ve “Data overview” widget’larını kullanarak şunu yapıyorum:

Tüm kritik servislerin response time’larını tek bir grafikte gösteriyorum. Bir e-ticaret projesinde ödeme sayfasının response time’ı ani bir spike yaptığında, aynı grafikteki diğer servislerle karşılaştırarak sorunun CDN kaynaklı mı yoksa uygulama katmanı kaynaklı mı olduğunu anlıyorum.

# Grafana entegrasyonu isteyenler için Zabbix datasource sorgu örneği:
# Zabbix plugin'i Grafana'ya eklendikten sonra şu query çalışır:
# Application: Web scenarios
# Item: web.test.time[Login Akisi Testi,,total]
# Host: www.sirketiniz.com

# Alternatif olarak doğrudan Zabbix API'den veri çekmek:
curl -s -X POST http://zabbix.sirketiniz.com/api_jsonrpc.php 
  -H "Content-Type: application/json" 
  -d '{
    "jsonrpc": "2.0",
    "method": "history.get",
    "params": {
      "output": "extend",
      "itemids": "ITEM_ID_BURAYA",
      "sortfield": "clock",
      "sortorder": "DESC",
      "limit": 100
    },
    "auth": "API_TOKEN_BURAYA",
    "id": 1
  }'

Gerçek Dünya Senaryosu: E-Ticaret Sitesi İzleme Planı

Bir e-ticaret projesinde kurduğum izleme yapısını paylaşayım. Site, AWS üzerinde çalışıyor, CloudFront CDN kullanıyor ve her ay Kara Cuma döneminde yük artışı yaşıyor.

İzleme planı şöyle:

Her 60 saniyede bir kontrol edilen endpoint’ler:

  • Ana sayfa (/) – 200 status, “Kampanyalar” metni içerip içermediği
  • Kategori sayfası (/elektronik) – 200 status, response time < 2s
  • Ürün detay sayfası (/urun/12345) – 200 status
  • Arama fonksiyonu (/arama?q=telefon) – 200 status, sonuç listesi var mı

Her 5 dakikada bir kontrol edilen akışlar:

  • Login akışı (3 adım)
  • Sepete ürün ekleme (2 adım)
  • Checkout sayfasına geçiş (müşteri verisine dokunmadan)

Her 30 dakikada bir kontrol edilenler:

  • SSL sertifikası geçerlilik süresi
  • Robots.txt erişilebilirliği
  • Sitemap.xml boyutu (anormal değişim var mı)

Bu yapı sayesinde Kara Cuma’da ödeme sayfasının yavaşlamasını, müşteri şikayeti gelmeden 4 dakika önce tespit ettik. Alert üzerine ölçeklendirme yapıldı ve kullanıcılar sorunu hiç fark etmedi.

Sonuç

Zabbix’in web izleme modülü, çoğu ekibin düşündüğünden çok daha güçlü. Basit uptime check’lerden başlayıp gerçek kullanıcı akışlarını simüle eden senaryolara, SSL sertifika yönetiminden API sağlık kontrollerine kadar geniş bir kapsam sunuyor.

Başlarken aşırı karmaşık senaryolar kurmaya çalışmayın. İlk hafta en kritik 5-10 URL’yi izleyin, trigger eşik değerlerini gerçek trafiğe bakarak kalibre edin. İkinci haftadan itibaren login akışları ve kritik API endpoint’lerini ekleyin. Birkaç hafta sonra neyin normal neyin anormal olduğunu anlamaya başlarsınız.

Alert yorgunluğunu ciddiye alın. Bir ekip gece 3’te gereksiz alarmdan uyandırıldığında, gerçek bir alarm geldiğinde tepki verme refleksi körelebiliyor. Severity seviyeleri ve trigger mantığı en az izleme konfigürasyonu kadar önemli.

Son olarak: web izlemeyi izole bir araç olarak değil, genel observability stratejinizin bir parçası olarak düşünün. Zabbix’teki web senaryosu başarısız olduğunda aynı anda application log’larına ve APM metriklerine bakabilmek, sorunun kaynağına çok daha hızlı ulaşmanızı sağlar.

Bir yanıt yazın

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