Netdata Dashboard: Metrikleri Okuma ve Yorumlama

Bykomut

Sunucunuzu ilk kez Netdata ile izlemeye başladığınızda karşınıza çıkan dashboard, onlarca grafik ve yüzlerce metrikle sizi biraz bunaltabilir. Hangi grafiğe bakacaksınız, hangi değer normal, hangisi alarm vermelidir? Bu soruların cevabını bulmak için Netdata’nın dashboard mantığını ve metriklerin ne anlama geldiğini iyi kavramanız gerekiyor. Bu yazıda dashboard’u baştan sona gezerek gerçek dünya senaryolarıyla metrikleri nasıl okuyup yorumlayacağınızı ele alacağız.

Netdata Dashboard’a İlk Bakış

Netdata kurulumunun ardından http://sunucu-ip:19999 adresine girdiğinizde sizi otomatik olarak keşfedilmiş tüm metrikleri listeleyen bir arayüz karşılıyor. Sol tarafta kategoriler halinde gruplanmış metrik ağacı, sağ tarafta ise gerçek zamanlı grafikleri görüyorsunuz.

Dashboard’un en üst kısmında bir araç çubuğu bulunuyor. Buradan zaman aralığını değiştirebilir, otomatik yenilemeyi kapatabilir veya grafikleri dondurabilirsiniz. Özellikle şu anki anlık sorunları araştırırken değil, geçmişte yaşanan olayları incelerken zaman aralığını değiştirme özelliğini çok kullanacaksınız.

# Netdata'nın hangi porttan çalıştığını kontrol etmek için
ss -tlnp | grep netdata

# Netdata servis durumu
systemctl status netdata

# Log dosyasını canlı takip etmek için
tail -f /var/log/netdata/error.log

Grafiklerin altında küçük bir bilgi alanı var. Fareyi grafiğin üzerine getirdiğinizde o ana ait kesin değerleri görebiliyorsunuz. Grafiği tıklayıp sürükleyerek zoom yapabilir, çift tıklayarak tekrar canlı izlemeye dönebilirsiniz. Bu basit ama çok işe yarayan özellik, spike anlarını incelemek için harika.

CPU Metriklerini Okumak

CPU bölümü genellikle dashboard’un en tepesinde yer alır ve en çok bakılan bölümdür. Ama dikkat: CPU kullanım yüzdesine bakmak tek başına yeterli değildir.

system.cpu Grafiği

Bu grafik CPU zamanının nasıl harcandığını gösterir. Renk renk alanlardan oluşan bu grafik aslında çok şey anlatıyor:

  • user: Kullanıcı alanında çalışan işlemlerin tükettiği CPU zamanı. Uygulamalarınız burada görünür.
  • system: Kernel’in harcadığı CPU zamanı. Yüksekse disk I/O veya network kesintileri söz konusu olabilir.
  • iowait: CPU’nun disk veya ağ I/O’sunu beklerken geçirdiği zaman. Bu değerin yüksek olması ciddi bir uyarıdır.
  • steal: Sanallaştırma ortamlarında hypervisor’ın sizden çaldığı CPU zamanı. VPS kullanıyorsanız bu değere dikkat edin.
  • softirq/irq: Donanım ve yazılım kesintileri. Ağ trafiği yoğun sunucularda artabilir.

iowait değeri sürekli %10’un üzerindeyse diskinizde bir sorun var demektir. Belki disk dolmak üzere, belki yazma işlemleri kuyrukta bekliyor.

# iowait sorununu araştırmak için
iostat -x 1 5

# Hangi işlem disk bekliyor, bulmak için
iotop -ao

# Disk queue derinliğini kontrol etmek için
cat /proc/diskstats

CPU Per Core Grafikleri

Netdata her çekirdek için ayrı grafik oluşturur. Burada ilginç bir durumla karşılaşabilirsiniz: Toplam CPU %30 gibi görünürken tek bir çekirdek %100’de çalışıyor olabilir. Bu, tek thread kullanan bir uygulamanın darboğaz oluşturduğuna işaret eder. MySQL’in bazı sorguları, Redis veya Node.js uygulamaları bu duruma sık sık yol açar.

Bellek Metriklerini Anlamak

Bellek grafikleri, sysadminlerin en çok yanlış yorumladığı bölümdür. “Bellek dolmuş” diye panikleyen ama aslında her şeyin yolunda olduğu durumlarla çok sık karşılaşıyorum.

system.ram Grafiği

  • free: Hiç kullanılmayan bellek. Linux’ta bu değerin düşük olması normal ve hatta iyidir.
  • used: Uygulamaların aktif olarak kullandığı bellek.
  • cached: Kernel’in disk önbelleği için kullandığı bellek. Gerektiğinde uygulamalara anında verilir.
  • buffers: I/O tampon belleği.

Gerçek “kullanılabilir” belleği görmek için free + cached + buffers değerlerini toplamanız gerekir. Netdata bunu zaten görsel olarak gösteriyor ama birçok kişi sadece “free” değerine bakıp panik yapıyor.

# Gerçek bellek kullanımını görmek için
free -h

# En çok bellek tüketen işlemler
ps aux --sort=-%mem | head -20

# Bellek detaylı bilgisi
cat /proc/meminfo | grep -E "MemTotal|MemFree|MemAvailable|Cached|SwapUsed"

Swap Kullanımı

Netdata’da system.swap grafiği swap kullanımını gösterir. Swap kullanımı sıfır olması ideal hedeftir ama ara sıra küçük miktarlarda kullanım normal kabul edilir. Asıl tehlike işareti swap kullanımının giderek artmasıdır. Bu bellek sızıntısına veya gerçek bellek yetersizliğine işaret edebilir.

Swap’in sürekli değişip durması, yani verinin RAM ve swap arasında gidip gelmesi thrashing olarak bilinir ve sunucu performansını yerle bir eder.

Disk I/O Metriklerini Yorumlamak

disk.io Grafiği

Bu grafik saniyede okunan ve yazılan veri miktarını gösterir. Burada neyin “normal” olduğu tamamen kullanım senaryonuza bağlıdır. Bir veritabanı sunucusu sürekli yüksek I/O gösterirken bir web sunucusu çok daha düşük değerler üretir.

# Disk I/O istatistiklerini detaylı görmek
iostat -xz 2 5

# Hangi dosyaya en çok yazılıyor
inotifywait -m -r /var/log --format '%w%f' -e modify 2>/dev/null | head -20

# Disk kullanım oranlarını kontrol et
df -h

# En büyük dizinleri bul
du -sh /* 2>/dev/null | sort -rh | head -10

disk.ops Grafiği

Bu grafik saniyedeki okuma/yazma işlemi sayısını gösterir, miktarı değil. Çok sayıda küçük işlem (yüksek IOPS) diskinizi farklı zorlar. HDD’lerde bu durum özellikle kritiktir çünkü her küçük arama hareketi zaman alır. SSD’lerde bu sorun çok daha azdır.

disk.util Grafiği

Disk kullanım yüzdesi bu grafikte yer alır. %80-90 üzerinde sürekli kalıyorsa diskiniz darboğaz haline gelmiştir. Bu durumda ya daha hızlı bir diske geçmeniz ya da okuma/yazma yükünü dağıtmanız gerekir.

Ağ Trafiği Metriklerini İzlemek

net.eth0 Grafiği

Her ağ arayüzü için ayrı grafik oluşturulur. Gelen (inbound) ve giden (outbound) trafik miktarını bit/saniye cinsinden gösterir.

# Gerçek zamanlı ağ trafiğini izlemek
iftop -i eth0

# Hangi bağlantılar en çok bant genişliği kullanıyor
nethogs eth0

# Aktif ağ bağlantıları ve durumları
ss -s

# TCP bağlantı sayısını duruma göre listele
ss -tan | awk '{print $1}' | sort | uniq -c | sort -rn

net.drops Grafiği

Düşürülen paket sayısını gösterir. Bu değerin sıfırdan büyük olması ve artış göstermesi ciddi bir ağ sorununa işaret edebilir. Nedenleri arasında ağ kartının kapasitesini aşma, kernel buffer dolması veya donanım sorunları sayılabilir.

net.errors Grafiği

Ağ hataları burada görünür. Sürekli artan bir değer varsa ağ kartı, kablo veya switch tarafında fiziksel bir sorun olabilir.

Gerçek Dünya Senaryosu: Sunucu Yavaşladı, Ne Bakıyoruz?

Diyelim ki müşterinizden gece 2’de mesaj geldi: “Site açılmıyor.” Netdata dashboard’unu açıp sistematik bir şekilde ilerlemeniz gerekiyor.

Adım 1: Zaman damgasını belirle

Sorunun başladığı zamanı dashboard’da bulun. Üst araç çubuğundan o zaman dilimine gidin.

Adım 2: CPU’ya bak

# O anki CPU durumu için
top -b -n 1 | head -30

# Geçmiş CPU verilerini görmek için sar komutu
sar -u 1 10

CPU grafikleri normal görünüyorsa sorun CPU’da değildir. iowait yüksekse diske geçin.

Adım 3: Bellek durumunu kontrol et

Bellek dolmuş mu? Swap kullanımı var mı? Bu sorulara cevap bulmak için system.ram ve system.swap grafiklerine bakın.

Adım 4: Disk I/O’yu incele

disk.util grafiği %100’e yakınsa sorun diskte. disk.ops grafiği normalse ve iowait yüksekse muhtemelen disk kapasitesi yetersiz.

Adım 5: Ağı kontrol et

net.eth0 grafiğinde ani bir trafik patlaması var mı? Bu bir DDoS saldırısına işaret edebilir. Aynı anda net.drops artmışsa ağ kartı kapasiteyi aşmış olabilir.

# Olası DDoS durumunda en çok bağlanan IP'leri bul
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

# Bağlantı sayısını kontrol et
ss -s | grep "TCP:"

Sistem Yükü ve Process Metrikleri

system.load Grafiği

Load average değerleri Netdata’da güzel bir şekilde görselleştirilir. 1 dakika, 5 dakika ve 15 dakikalık ortalamalar ayrı çizgilerle gösterilir.

Load average yorumu:

  • Çekirdek sayısına eşit veya daha düşükse sistem rahat çalışıyor
  • Çekirdek sayısının 2 katına yaklaşıyorsa dikkat et
  • Çekirdek sayısının 4 katı ve üzeriyse ciddi sorun var

Örneğin 4 çekirdekli bir sunucuda load average 4.0 normal, 8.0 yüklü ama idare eder, 16.0 ise sistem çöküyor demektir.

# Çekirdek sayısını öğren
nproc

# Detaylı load bilgisi
uptime

# Hangi işlemler load'u yüksek tutuyor
ps aux --sort=-pcpu | head -15

apps.cpu ve apps.mem Grafikleri

Netdata uygulama seviyesinde de metrik toplar. Hangi uygulamanın ne kadar CPU ve bellek tükettiğini bu grafiklerden görebilirsiniz. Bu özellik özellikle çok hizmetin çalıştığı sunucularda hayat kurtarıcı.

Web Server Metrikleri: Nginx ve Apache

Netdata Nginx ve Apache için otomatik plugin’ler içerir. Ama bunların çalışması için sunucuda stub_status (Nginx) veya mod_status (Apache) etkinleştirilmiş olmalı.

# Nginx stub_status kontrolü
curl -s http://localhost/stub_status

# Eğer etkin değilse Nginx config'e eklemek için
cat >> /etc/nginx/conf.d/stub_status.conf << 'EOF'
server {
    listen 127.0.0.1:80;
    location /stub_status {
        stub_status on;
        allow 127.0.0.1;
        deny all;
    }
}
EOF

nginx -t && systemctl reload nginx

Nginx metrikleri aktifleştirildikten sonra Netdata dashboard’unda şu değerleri görürsünüz:

  • nginx.connections: Aktif bağlantı sayısı
  • nginx.requests: Saniyedeki istek sayısı
  • nginx.connection_status: Bağlantıların durumları (active, reading, writing, waiting)

waiting değerinin çok yüksek olması keep-alive bağlantıların biriktiğine işaret eder. writing değeri yüksekse istemcilere yavaş yanıt veriliyor olabilir.

MySQL/MariaDB Metriklerini İzlemek

Veritabanı sunucularında Netdata’nın MySQL plugin’i son derece değerli bilgiler sağlar.

# Netdata'nın MySQL'e bağlanması için kullanıcı oluştur
mysql -u root -p << 'EOF'
CREATE USER 'netdata'@'localhost' IDENTIFIED BY '';
GRANT USAGE ON *.* TO 'netdata'@'localhost';
FLUSH PRIVILEGES;
EOF

# Netdata MySQL konfigürasyonunu kontrol et
cat /etc/netdata/python.d/mysql.conf

MySQL metriklerinde en çok dikkat etmeniz gerekenler:

  • mysql.queries: Saniyedeki sorgu sayısı. Ani artışlar yoğun trafik veya kötü bir döngüye girmiş sorgu anlamına gelebilir.
  • mysql.connections: Açık bağlantı sayısı. max_connections limitine yaklaşıyorsa yeni bağlantılar reddedilir.
  • mysql.innodb_io: InnoDB’nin I/O işlemleri. Yüksekse buffer pool boyutunu artırmayı düşünün.
  • mysql.threads: Çalışan thread sayısı. Bu değer sürekli yüksekse sorgular kuyrukta bekliyor demektir.

Alarm Sistemiyle Metrikleri Anlamlandırmak

Netdata’nın varsayılan alarm tanımlamaları, hangi değerlerin “normal” hangilerin “anormal” olduğunu anlamanıza da yardımcı olur. Bu tanımlamaları okumak başlı başına bir öğrenme deneyimidir.

# Mevcut alarm tanımlarını listele
ls /usr/lib/netdata/conf.d/health.d/

# CPU alarmlarını incele
cat /usr/lib/netdata/conf.d/health.d/cpu.conf

# Kendi alarm tanımını oluştur
cat > /etc/netdata/health.d/custom_disk.conf << 'EOF'
alarm: disk_space_critical
on: disk.space
lookup: average -5m percentage of used
units: %
every: 1m
warn: $this > 80
crit: $this > 90
info: Disk doluluk orani kritik seviyeye ulasti
EOF

systemctl restart netdata

Alarmların renk kodlamasını anlamak da önemli. Dashboard’da sarı renkli metrikler uyarı (warning) durumunda, kırmızı renkli metrikler ise kritik (critical) durumda.

Performans Karşılaştırması: Baseline Oluşturmak

Netdata’yı etkili kullanmanın püf noktası, sunucunuzun “normal” davranışını bilmektir. Buna baseline denir. İlk hafta boyunca grafikleri düzenli olarak izleyerek şu soruları yanıtlayın:

  • Hafta içi mesai saatlerinde CPU ortalama ne kadar?
  • Gece yarısı backup alınırken disk I/O ne kadar?
  • Peak trafik anında kaç bağlantı var?

Bu değerleri not edin. Sonradan bir sorun yaşadığınızda “bu normal mi, anormal mi?” sorusuna hemen cevap verebilirsiniz.

# Geçmiş verileri Netdata'nın kendi veritabanından sorgulamak için
curl -s "http://localhost:19999/api/v1/data?chart=system.cpu&after=-3600&before=0&points=60&format=json" | python3 -m json.tool | head -50

# Mevcut alarmların durumunu API üzerinden kontrol et
curl -s "http://localhost:19999/api/v1/alarms" | python3 -m json.tool

Netdata’yı Daha Verimli Kullanmak İçin İpuçları

Dashboard’u daha verimli kullanmak için bazı pratik öneriler:

  • Favorilere ekle: Sık baktığınız grafikleri tarayıcıda yer imlerine ekleyin. Doğrudan o chart’ın anchor linkini kullanabilirsiniz.
  • Grafikleri dondur: Bir anomali gördüğünüzde grafiği durdurun, sonra diğer grafiklere bakın. Tüm grafikler aynı zaman noktasını gösterir.
  • Bağlantılı grafiklere bak: Bir metrikte sorun görünce ilişkili metriklere bakın. CPU yüksekse bellek ve disk grafiklerine de bakın.
  • Gece bildirimleri: Netdata’nın alarm bildirimlerini email veya Slack üzerinden yapılandırın, sorunları siz görmeden önce haberdar olun.
# Slack bildirimi için temel konfigürasyon
cat /etc/netdata/health_alarm_notify.conf | grep -A5 "SLACK"

# Konfigürasyonu düzenle
nano /etc/netdata/health_alarm_notify.conf

# Test bildirimi gönder
/usr/lib/netdata/plugins.d/alarm-notify.sh test

Sonuç

Netdata dashboard’u ilk bakışta karmaşık görünse de sistematik bir yaklaşımla kısa sürede rahatça okumayı öğrenebilirsiniz. En önemli nokta şu: tek bir metriğe bakarak karar vermemek. CPU yüksekse neden yüksek, disk I/O artmışsa hangi işlem yaptırıyor, bellek doluysa bu normal mi, değil mi? Bu soruları grafikleri birlikte değerlendirerek yanıtlıyorsunuz.

İkinci önemli nokta baseline oluşturmak. Sunucunuzun normal davranışını bilmeden anormal durumu tespit edemezsiniz. İlk haftanız tamamen gözlem yapın, not alın, değerleri aklınıza yerleştirin.

Son olarak Netdata’nın alarm sistemini aktif kullanın. Dashboard’a sürekli bakmak yerine sistemin size haber vermesini sağlayın. Böylece hem zaman kazanırsınız hem de gece 3’te uyandığınızda tam olarak nereye bakmanız gerektiğini bilirsiniz.

Netdata sadece bir izleme aracı değil, zamanla deneyim kazandıkça sunucunuzu okumayı öğreten bir öğretmen gibi. Her anormallik, her spike, her yavaşlama size sistemin nasıl çalıştığını gösterir. Bu deneyimi biriktirdikçe sorun tespiti ve çözümü çok daha hızlı hale gelir.

Benzer Konular

Bir yanıt yazın

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