Zabbix ile Disk I/O Performansı İzleme ve Darboğaz Tespiti

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

Disk I/O performansı, sistem yöneticilerinin en çok göz ardı ettiği ama en kritik darboğaz noktalarından biridir. CPU ve RAM metrikleri alarm verirken disk I/O sessizce sistem performansını yerle bir ediyor olabilir. Özellikle veritabanı sunucuları, dosya depolama sistemleri ve yüksek trafikli web uygulamalarında disk I/O darboğazları, kullanıcı deneyimini doğrudan etkiler. Zabbix ile bu metriği doğru şekilde izlemek, sorunları reaktif değil proaktif olarak ele almanızı sağlar.

Disk I/O Neden Bu Kadar Önemli?

Bir PostgreSQL sunucusunun neden yavaş sorgu döndürdüğünü araştırırken saatlerce harcadığınız oldu mu? Sorunu çoğunlukla CPU veya RAM’de aradık, ama asıl sorun diskti. Modern uygulamalar disk I/O’ya son derece bağımlıdır ve bu bağımlılık genellikle gözden kaçar.

Disk I/O darboğazının belirtileri şunlardır:

  • Yüksek load average değerleri ama düşük CPU kullanımı
  • Uygulamaların yavaş yanıt vermesi veya zaman aşımına uğraması
  • iostat çıktısında yüksek await değerleri
  • Veritabanı sorgularının normalden çok daha uzun sürmesi
  • Sistem loglarında I/O bekleme hataları

Zabbix Agent, Linux sistemlerde iostat benzeri metrikleri doğrudan kernel istatistiklerinden okur ve bu sayede ek araç kurmanıza gerek kalmaz.

Zabbix Agent Disk I/O Metrikleri

Zabbix’in built-in vfs.dev.* anahtar ailesi, disk I/O izleme için temel araçtır. Bu anahtarların ne döndürdüğünü ve nasıl yorumlandığını anlamak kritik önem taşır.

Temel vfs.dev Anahtarları

vfs.dev.read[device,type,mode]: Belirtilen cihazdan okuma istatistiklerini döndürür.

  • device: sda, nvme0n1, vda gibi cihaz adı
  • type: sectors, operations, bytes, sps, ops, bps
  • mode: avg1, avg5, avg15

vfs.dev.write[device,type,mode]: Yazma istatistiklerini döndürür, aynı parametreler geçerlidir.

vfs.dev.util[device]: Cihazın yüzde kaç zaman meşgul olduğunu gösterir. Bu değer %100’e yaklaşıyorsa ciddi bir darboğaz işaretidir.

vfs.dev.await[device]: Ortalama I/O bekleme süresi, milisaniye cinsinden.

vfs.dev.queue_size[device]: Cihaz kuyruğundaki ortalama istek sayısı.

Zabbix Agent üzerinde bu anahtarları test etmek için:

# Agent'ın disk I/O verisi döndürüp döndürmediğini test et
zabbix_agentd -t vfs.dev.util[sda]
zabbix_agentd -t vfs.dev.await[sda]
zabbix_agentd -t vfs.dev.read[sda,bps,avg1]
zabbix_agentd -t vfs.dev.write[sda,bps,avg1]

# NVMe disk için
zabbix_agentd -t vfs.dev.util[nvme0n1]

Eğer agent doğru yanıt vermiyorsa, kernel istatistiklerinin /proc/diskstats üzerinden okunabildiğini kontrol edin:

# Diskstat verilerini kontrol et
cat /proc/diskstats | grep sda

# iostat ile baseline oluştur
iostat -x 2 5

Zabbix’te Disk I/O Template Oluşturma

Zabbix’in hazır template’leri genellikle yeterli olmaz. Kendi ortamınıza özel bir template oluşturmak, hem anlamlı uyarılar almanızı hem de gereksiz gürültüden kaçınmanızı sağlar.

Item Discovery Rule ile Dinamik Disk İzleme

Sunucularda disk sayısı değişebilir. Bu nedenle Low-Level Discovery (LLD) kullanarak diskleri otomatik keşfetmek en doğru yaklaşımdır.

Zabbix API üzerinden template oluşturmak için aşağıdaki yapıyı kullanabilirsiniz:

# Zabbix API'ye bağlanarak token al
curl -s -X POST -H 'Content-Type: application/json' 
  -d '{
    "jsonrpc": "2.0",
    "method": "user.login",
    "params": {
      "user": "Admin",
      "password": "zabbix"
    },
    "id": 1
  }' 
  http://zabbix-server/zabbix/api_jsonrpc.php

Discovery rule için agent item anahtarı:

# Agent tarafında hangi disklerin keşfedildiğini kontrol et
zabbix_agentd -t vfs.dev.discovery

# Çıktı örneği:
# [{"NAME":"sda"},{"NAME":"sdb"},{"NAME":"nvme0n1"}]

Discovery rule item’ları için prototype şablonu:

Key: vfs.dev.util[{#DEVNAME}]
Name: Disk utilization for {#DEVNAME}
Update interval: 60s
History: 7d
Trends: 90d

Özel UserParameter ile Gelişmiş Metrik Toplama

Zabbix’in built-in anahtarları bazen yeterli gelmez. Özellikle IOPS, throughput ve latency gibi metrikleri daha ayrıntılı toplamak istiyorsanız UserParameter kullanın.

/etc/zabbix/zabbix_agentd.d/disk_io.conf dosyasını oluşturun:

# IOPS - saniyedeki okuma operasyonu sayısı
UserParameter=custom.disk.read_iops[*], 
  awk -v dev="$1" '$3==dev{print $4}' /proc/diskstats

# Ortalama istek boyutu (bytes)
UserParameter=custom.disk.avg_req_size[*], 
  iostat -dx "$1" 1 2 | awk 'NR>4 && /'"$1"'/{print $8}'

# I/O scheduler tipini öğren
UserParameter=custom.disk.scheduler[*], 
  cat /sys/block/"$1"/queue/scheduler 2>/dev/null | 
  grep -oP '[K[^]]*'

# Disk queue depth
UserParameter=custom.disk.queue_depth[*], 
  cat /sys/block/"$1"/queue/nr_requests 2>/dev/null

Değişiklikleri uygulamak için agent’ı yeniden başlatın:

systemctl restart zabbix-agent
# ya da zabbix-agent2 kullanıyorsanız
systemctl restart zabbix-agent2

# Yeni parametreleri test et
zabbix_agentd -t custom.disk.read_iops[sda]
zabbix_agentd -t custom.disk.scheduler[sda]

Trigger ve Alarm Yapılandırması

Disk I/O için anlamlı triggerlar oluşturmak, yanlış alarmları minimize etmenin anahtarıdır. Sabit eşik değerleri yerine dinamik baseline kullanmak çok daha etkilidir.

Kritik Trigger Örnekleri

Zabbix trigger expression’ları için pratikte kullandığım yapılar:

# Disk utilization 5 dakika boyunca %90 üzerinde
{Template Custom Disk IO:vfs.dev.util[{#DEVNAME}].min(5m)} > 90

# Await süresi 50ms'i geçerse
{Template Custom Disk IO:vfs.dev.await[{#DEVNAME}].avg(3m)} > 50

# Queue size sürekli yüksek (I/O saturation göstergesi)
{Template Custom Disk IO:vfs.dev.queue_size[{#DEVNAME}].avg(5m)} > 5

# Yazma throughput'u aniden düşerse (disk arızası erken uyarısı)
{Template Custom Disk IO:vfs.dev.write[{#DEVNAME},bps,avg1].change()} < -50000000

Recovery expression ile gereksiz bildirimleri azaltın:

# Utilization %75'in altına düşünce recovery
{Template Custom Disk IO:vfs.dev.util[{#DEVNAME}].max(3m)} < 75

Gerçek Dünya Senaryosu: MySQL Sunucusunda Darboğaz Tespiti

Geçen yıl bir e-ticaret müşterisinin MySQL sunucusunda yaşananlar bu konuyu çok güzel özetliyor. Gece yarısı sipariş sayfaları yavaşlamıştı. CPU %30, RAM yeterli, network temiz. Ama Zabbix dashboard’una bakınca disk I/O grafiklerinde ilginç bir tablo vardı.

Önce sunucuda manuel kontrol:

# I/O durumunu anlık izle
iostat -x 1 10

# Hangi process en fazla I/O yapıyor?
iotop -ao --only

# Disk istatistiklerini daha ayrıntılı gör
pidstat -d 1 5

iotop çıktısı MySQL’in saniyede 450MB yazma yaptığını gösterdi. Zabbix’teki tarihsel grafiği incelediğimizde bu durumun akşam 22:00’de başladığını ve gece 02:00’ye kadar sürdüğünü gördük. Tam da büyük bir raporlama sorgusu çalıştığı zamana denk geliyordu.

Problemi Çözmek İçin Zabbix Verilerini Kullanmak

Zabbix’teki trend verilerini incelemek için Monitoring > Latest Data bölümünü kullanın. Ama bazen verileri dışa aktarıp analiz etmek daha pratik olur:

# Zabbix MySQL veritabanından son 24 saatin I/O verilerini çek
mysql -u zabbix -p zabbix -e "
SELECT 
  FROM_UNIXTIME(clock) as time,
  value as util_percent
FROM history
WHERE itemid = (
  SELECT itemid FROM items 
  WHERE key_ = 'vfs.dev.util[sda]' 
  AND hostid = YOUR_HOST_ID
)
AND clock > UNIX_TIMESTAMP(NOW() - INTERVAL 24 HOUR)
ORDER BY clock DESC
LIMIT 100;" 2>/dev/null

Bu sorgu, son 24 saatin disk utilization değerlerini çeker ve darboğazın tam olarak ne zaman başladığını ve bittiğini gösterir.

I/O Scheduler Optimizasyonu ve Zabbix ile Doğrulama

Darboğazı tespit ettikten sonra I/O scheduler optimizasyonu yapabilirsiniz. Farklı workload’lar için farklı scheduler’lar uygundur.

# Mevcut scheduler'ı kontrol et
cat /sys/block/sda/queue/scheduler

# Veritabanı sunucuları için deadline scheduler önerilir
echo deadline > /sys/block/sda/queue/scheduler

# SSD ve NVMe için none veya mq-deadline
echo none > /sys/block/nvme0n1/queue/scheduler

# Değişikliği kalıcı hale getir (GRUB üzerinden)
# /etc/default/grub dosyasında GRUB_CMDLINE_LINUX'a ekle:
# elevator=deadline

# Grub'u güncelle
update-grub
# ya da RHEL/CentOS için
grub2-mkconfig -o /boot/grub2/grub.cfg

Scheduler değişikliğinin etkisini Zabbix’te izlemek için önceki ve sonraki await değerlerini karşılaştırın. İyi yapılandırılmış bir Zabbix dashboard’u bu farkı net şekilde görselleştirir.

Zabbix Dashboard’u Disk I/O İçin Yapılandırma

Disk I/O izleme için etkili bir dashboard oluşturmak, sorunları hızla tespit etmenizi sağlar. Dashboard widget yapılandırması için önerim:

  • Graph widget: vfs.dev.util tüm diskler için aynı grafikte, 24 saatlik görünüm
  • Graph widget: Read/Write IOPS ve throughput ayrı grafikler halinde
  • Top 10 hosts widget: En yüksek disk I/O yapan sunucular
  • Problem widget: Aktif disk I/O alarmları filtrelenmiş görünüm

Zabbix 6.x ile gelen Geomap ve Honeycomb widget’larını disk I/O için kullanmak pek anlamlı olmasa da, Item value widget’ı ile anlık utilization değerlerini büyük fontla göstermek operasyonel farkındalık için çok işe yarıyor.

Zabbix External Check ile Gelişmiş Analiz

Zabbix’in built-in anahtarları yetmediği durumlarda external script kullanabilirsiniz. /etc/zabbix/externalscripts/ dizinine aşağıdaki scripti ekleyin:

#!/bin/bash
# disk_latency_percentile.sh
# Kullanım: disk_latency_percentile.sh <device> <percentile>

DEVICE="${1:-sda}"
PERCENTILE="${2:-95}"
DURATION=60

# blktrace ile latency verisi topla (root yetkisi gerekli)
if ! command -v blktrace &> /dev/null; then
  echo "ERROR: blktrace not found"
  exit 1
fi

# Sudo ile çalıştır, zabbix user'a sudo yetkisi ver
LATENCIES=$(sudo blktrace -d /dev/"$DEVICE" -o - 2>/dev/null | 
  blkparse -i - -f "%D %dn" 2>/dev/null | 
  awk '{sum+=$2; count++} END {if(count>0) print sum/count; else print 0}')

echo "${LATENCIES:-0}"

Bu script için /etc/sudoers.d/zabbix dosyasına şu satırı ekleyin:

# Zabbix user'a blktrace için sudo yetkisi ver
zabbix ALL=(ALL) NOPASSWD: /usr/bin/blktrace

Proaktif Kapasite Planlaması

Disk I/O izlemenin en büyük değeri gerçek zamanlı alarmlar değil, tarihsel trend analizidir. Zabbix’in trend verileri ile gelecek 30-60 günün I/O ihtiyacını tahmin edebilirsiniz.

Zabbix API ile trend verilerini çekerek basit bir projeksiyon yapabilirsiniz:

#!/bin/bash
# io_trend_analysis.sh
# Son 30 günün disk utilization ortalamasını hesapla

ZABBIX_URL="http://localhost/zabbix"
API_TOKEN="your_api_token_here"
HOST_ID="your_host_id"
ITEM_KEY="vfs.dev.util[sda]"

# Son 30 günün trend verilerini al
RESPONSE=$(curl -s -X POST 
  -H "Content-Type: application/json" 
  -H "Authorization: Bearer ${API_TOKEN}" 
  -d "{
    "jsonrpc": "2.0",
    "method": "trend.get",
    "params": {
      "output": "extend",
      "itemids": ["ITEM_ID_HERE"],
      "time_from": $(date -d '30 days ago' +%s),
      "time_till": $(date +%s)
    },
    "id": 1
  }" 
  "${ZABBIX_URL}/api_jsonrpc.php")

echo "$RESPONSE" | python3 -c "
import sys, json
data = json.load(sys.stdin)
results = data.get('result', [])
if results:
    values = [float(r['value_avg']) for r in results]
    avg = sum(values) / len(values)
    max_val = max(values)
    print(f'30 Gun Ortalama Utilization: {avg:.1f}%')
    print(f'30 Gun Maksimum Utilization: {max_val:.1f}%')
    print(f'Trend: Kapasiteye ne kadar yakin: {avg:.0f}%')
"

Eğer 30 günlük ortalama utilization %70 üzerindeyse, donanım yükseltmesini planlama zamanı gelmiştir. Bu veriyi yöneticilere sunarken Zabbix’in PDF rapor özelliğini veya Grafana entegrasyonunu kullanabilirsiniz.

Sık Yapılan Hatalar

Disk I/O izlemede karşılaştığım yaygın hatalar:

  • Çok kısa polling interval: 10 saniyenin altında polling, Zabbix server’ına gereksiz yük bindirir. 60 saniye çoğu senaryo için yeterlidir.
  • Partition yerine device izlemek: sda1 yerine sda izleyin, yoksa partition’a ait istatistikler eksik olabilir.
  • Sabit threshold kullanmak: Her disk ve her workload için eşik değerleri farklıdır. Baseline alın, sonra threshold belirleyin.
  • Sadece utilization izlemek: Utilization %100 olmasa da yüksek latency sorun işareti olabilir. await değerini mutlaka izleyin.
  • RAID controller cache’ini göz ardı etmek: RAID cache’i aktifken Zabbix’te yazma hızları çok yüksek görünebilir, bu yanıltıcıdır.

Sonuç

Disk I/O izleme, sistem sağlığının en kritik bileşenlerinden biridir ve Zabbix ile bu izlemeyi son derece ayrıntılı şekilde yapabilirsiniz. Built-in vfs.dev.* anahtarlarıyla başlayın, UserParameter ile özelleştirin ve LLD ile dinamik keşfi devreye alın. Threshold’larınızı gerçek veriye dayandırın, sabit sayılara değil.

En önemli kural şudur: bir sistem yavaşladığında ilk baktığınız yer CPU ve RAM olmasın. Zabbix dashboard’unuzda disk I/O grafikleri her zaman görünür yerde olsun. Çoğu zaman cevap orada duruyor olacak.

Proaktif izleme yapısını kurduktan sonra, darboğazları kullanıcılar fark etmeden siz fark edersiniz. Zaten iyi bir sysadmin’i ortalama bir sysadmin’den ayıran da bu yaklaşımdır.

Bir yanıt yazın

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