Netdata ile CPU ve Bellek İzleme: Gerçek Zamanlı Performans Takibi

Sunucularınızda bir şeyler ters giderken “acaba ne oluyor?” diye terminal’e bakıp top çalıştırmak herkesin bildiği klasik bir refleks. Ama Netdata kurulduktan sonra bu alışkanlık tamamen değişiyor. Saniyede bir güncellenen grafikler, sıfır konfigürasyon ile çalışan alarm sistemi ve tarayıcıdan erişilebilen arayüzü ile Netdata, özellikle CPU ve bellek izleme konusunda rakipsiz bir araç haline geliyor. Bu yazıda Netdata’yı nasıl kuracağınızı, CPU ve bellek metriklerini nasıl yorumlayacağınızı ve gerçek dünya senaryolarında nasıl kullanacağınızı ele alacağız.

Netdata Nedir ve Neden Kullanmalısınız

Netdata, açık kaynaklı, gerçek zamanlı bir sistem izleme aracı. Prometheus + Grafana kombinasyonuna kıyasla kurulumu dakikalar alıyor ve kutudan çıkar çıkmaz yüzlerce metriği otomatik olarak toplamaya başlıyor. En büyük avantajı 1 saniyelik çözünürlük – yani 60 saniyelik ortalamalar yerine gerçekten ne olduğunu görüyorsunuz.

Özellikle şu senaryolarda Netdata hayat kurtarır:

  • CPU spike’larının tam olarak ne zaman ve hangi process’ten kaynaklandığını bulmak
  • Bellek sızıntısı olan bir uygulamayı tespit etmek
  • Gece 3’te gelen “sunucu yavaşladı” şikayetini ertesi sabah geçmişe bakarak analiz etmek
  • Kapasite planlaması için uzun vadeli trend analizi

Kurulum

Netdata kurulumu inanılmaz derecede basit. Tek satırlık kurulum scripti ile başlayalım:

wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh
sh /tmp/netdata-kickstart.sh --stable-channel --disable-telemetry

Eğer scripti çalıştırmadan önce içeriğini incelemek istiyorsanız (ki production ortamında bunu yapmanızı öneririm):

# Scripti indirip incele
wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh
less /tmp/netdata-kickstart.sh

# Onayladıktan sonra çalıştır
bash /tmp/netdata-kickstart.sh --stable-channel --disable-telemetry --dont-start-it

Ubuntu/Debian üzerinde paket yöneticisi ile de kurabilirsiniz:

# Repo ekle
curl -fsSL https://packagecloud.io/netdata/netdata/gpgkey | gpg --dearmor -o /usr/share/keyrings/netdata-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/netdata-archive-keyring.gpg] https://packagecloud.io/netdata/netdata/ubuntu/ $(lsb_release -cs) main" | tee /etc/apt/sources.list.d/netdata.list

apt update && apt install netdata -y

# Servisi başlat ve enable et
systemctl enable --now netdata

Kurulum tamamlandıktan sonra http://sunucu-ip:19999 adresine giderek arayüze erişebilirsiniz. Varsayılan olarak herhangi bir kullanıcı adı/şifre istemiyor, bu yüzden production’da mutlaka firewall ile kısıtlayın:

# Sadece belirli IP'den erişime izin ver
ufw allow from 192.168.1.0/24 to any port 19999
ufw deny 19999

Netdata Konfigürasyonu

Ana konfigürasyon dosyası /etc/netdata/netdata.conf altında bulunuyor. Netdata bu dosyayı minimal tutuyor, değiştirmek istediğiniz parametreleri açıkça yazmanız gerekiyor:

# Mevcut konfigürasyonu görüntüle
netdatacli dumpconfig

# Ya da varsayılan konfigürasyonu oluştur
cd /etc/netdata
netdata -W dump-config > netdata.conf

Temel bir netdata.conf yapılandırması:

[global]
    # Veriyi kaç saniye sakla (saniye cinsinden, 3600 = 1 saat)
    history = 3600
    
    # Update sıklığı (saniye)
    update every = 1
    
    # Web arayüzü için bind adresi
    bind to = 0.0.0.0:19999
    
    # Bellek modu (ram, save, map, dbengine)
    memory mode = dbengine

[web]
    # Web sunucusu thread sayısı
    web server threads = 4
    
    # Maksimum bağlantı
    web server max connections = 1024

[plugins]
    # Python plugin'leri aktif et
    python.d = yes
    
    # Node.js plugin'leri
    node.d = yes

CPU İzleme: Detaylar ve Yorumlama

Netdata arayüzünde CPU bölümü açıldığında onlarca farklı grafik ile karşılaşıyorsunuz. Kafanızı karıştırmasın, hangisinin ne anlama geldiğini bilmek yeterli.

CPU Kullanım Modları

Netdata, CPU zamanını farklı kategorilere bölerek gösteriyor:

  • user: Kullanıcı alanındaki uygulamaların CPU kullanımı (web server, database vb.)
  • system: Kernel’in CPU kullanımı, sistem çağrıları ve interrupt handling
  • iowait: CPU’nun I/O işlemlerini beklerken geçirdiği zaman (yüksekse disk veya network darboğazı var)
  • steal: Sanallaştırma ortamlarında hypervisor’ın CPU çaldığı zaman (VPS kullanıyorsanız önemli)
  • softirq / irq: Network kartı, disk gibi donanımların interrupt’ları için harcanan zaman
  • nice: Düşük öncelikli process’lerin kullanımı

iowait Yüksekliği Senaryosu

Production’da en sık karşılaşılan sorunlardan biri iowait yüksekliği. CPU kullanımı düşük görünmesine rağmen sistem yavaş, uygulamalar yanıt vermekte gecikiyor. Netdata’da CPU grafiğinde iowait oranı yüksek görünüyorsa şu komutlarla derinlemesine analiz yapabilirsiniz:

# iowait kaynağını bul
iostat -x 1 5

# Hangi process I/O yapıyor
iotop -oa --sort TOTAL

# Disk latency kontrolü
iostat -d -h 1 10 | awk '/^Device/{p=1} p'

steal değerinin yüksek olması ise başka bir hikaye. Eğer VPS kullanıyorsanız ve steal sürekli %10’un üzerindeyse, hosting sağlayıcınız o fiziksel sunucuyu fazla satmış demektir, destek açmanızın zamanı gelmiş demek.

CPU Throttling ve Frekans İzleme

Netdata, CPU frekansını ve throttling durumunu da izleyebiliyor. Özellikle fiziksel sunucularda termal throttling sorunu yaşandığında bunu görmek çok değerli:

# CPU frekans bilgisi
cat /proc/cpuinfo | grep "cpu MHz"

# Throttling istatistikleri
cat /sys/devices/system/cpu/cpu0/thermal_throttle/core_throttle_count

# Netdata'nın topladığı frekans metriklerini kontrol et
ls /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq

Per-Core CPU Analizi

Netdata’da her core için ayrı grafik görebiliyorsunuz. Bu özellikle şu durumlarda işe yarıyor:

Diyelim ki bir uygulama single-threaded çalışıyor ve CPU toplamda %20 görünüyor ama aslında tek bir core %100’de patlıyor. Genel CPU grafiği sizi yanıltabilir ama per-core grafiği gerçeği gösterir. Bu durumda uygulamanızın multi-threading desteğini veya taskset ile core affinity ayarını gözden geçirmeniz gerekir:

# Process'i belirli core'lara kilitle
taskset -cp 0,1,2,3 <PID>

# Yeni process'i belirli core'larda başlat
taskset -c 0-3 python3 myapp.py

# NUMA topology kontrolü (çok socket'li sunucularda)
numactl --hardware

Bellek İzleme: RAM ve Swap Detayları

Bellek yönetimi, CPU’dan daha karmaşık bir konu çünkü Linux belleği oldukça agresif kullanıyor. free -h çıktısında “used” yüksek görünce paniklemek yerine Netdata’nın detaylı görünümüne bakmanız gerekiyor.

Linux Bellek Kategorileri

Netdata’da bellek grafiğinde şu kategorileri göreceksiniz:

  • used: Gerçekten kullanılan bellek
  • cached: Dosya sistemi cache’i (boşaltılabilir)
  • buffers: I/O buffer’ları (boşaltılabilir)
  • free: Tamamen boş bellek
  • shared: Shared memory (tmpfs, IPC)
  • swap: Kullanılan swap alanı

Linux’ta “available” değeri daha anlamlıdır çünkü cache boşaltılarak kullanılabilecek belleği de içeriyor:

# Gerçek available belleği gör
free -h

# Detaylı bellek bilgisi
cat /proc/meminfo

# Process bazlı bellek kullanımı (RSS = gerçek kullanım)
ps aux --sort=-%mem | head -20

# smem ile daha detaylı analiz
smem -ra --sort=rss | head -20

Bellek Sızıntısı Tespiti

Gerçek dünya senaryosu: Bir Java uygulaması her gün birkaç GB bellek tüketiyor ve haftalık restart atmak zorunda kalıyorsunuz. Netdata’da bunu nasıl tespit edersiniz?

Arayüzde System Overview > RAM bölümüne gidin ve zaman aralığını 7 gün yapın. Eğer kullanılan bellek sürekli artıp hiç düşmüyorsa bellek sızıntısı var demektir. Crash veya restart sonrası grafik düşüyor, sonra tekrar çıkmaya başlıyorsa kesin teşhis.

Bu tespiti komut satırından da yapabilirsiniz:

# Belirli bir process'in bellek kullanımını zaman içinde izle
while true; do
    DATE=$(date '+%Y-%m-%d %H:%M:%S')
    MEM=$(ps -p <PID> -o rss= | awk '{print $1/1024 " MB"}')
    echo "$DATE - Memory: $MEM"
    sleep 60
done

# Daha detaylı: smaps ile process bellek haritası
cat /proc/<PID>/smaps | grep -E "^(Rss|Pss|Shared|Private)" | 
    awk '{sum[$1]+=$2} END {for(k in sum) print k": "sum[k]/1024" MB"}'

OOM Killer Analizi

Sunucunuz OOM (Out of Memory) nedeniyle process’leri öldürüyorsa Netdata alarm verecektir. OOM sonrası analiz için:

# OOM killer loglarını kontrol et
dmesg | grep -i "oom|killed process|out of memory"

# journalctl ile daha detaylı
journalctl -k | grep -i "oom|killed"

# OOM'dan önceki bellek durumunu gör
journalctl -k | grep -B5 "oom-kill"

OOM’ı önlemek için kritik process’lere OOM koruma uygulayabilirsiniz:

# Process'i OOM killer'dan koru (-1000 = tamamen koru)
echo -1000 > /proc/<PID>/oom_score_adj

# Systemd servisinde OOM koruma
# /etc/systemd/system/myapp.service içine:
# [Service]
# OOMScoreAdjust=-500

# Swap'ı optimize et (swappiness azalt)
echo 10 > /proc/sys/vm/swappiness

# Kalıcı yapmak için
echo "vm.swappiness=10" >> /etc/sysctl.conf
sysctl -p

Alarm Konfigürasyonu

Netdata’nın alarm sistemi /etc/netdata/health.d/ dizinindeki .conf dosyaları ile yönetiliyor. CPU ve bellek için özel alarmlar tanımlayalım:

# CPU alarm dosyası oluştur
cat > /etc/netdata/health.d/cpu-custom.conf << 'EOF'
# CPU kullanımı 5 dakika boyunca %80 üzerinde ise warning
alarm: cpu_usage_high
     on: system.cpu
     os: linux
 lookup: average -5m unaligned of user,system
  units: %
  every: 1m
   warn: $this > 80
   crit: $this > 95
  delay: down 15m multiplier 1.5 max 1h
   info: CPU kullanimi yuksek
     to: sysadmin

# iowait alarm
alarm: cpu_iowait_high
     on: system.cpu
 lookup: average -10m unaligned of iowait
  units: %
  every: 2m
   warn: $this > 20
   crit: $this > 40
  delay: down 30m multiplier 1.5 max 2h
   info: CPU iowait yuksek, disk I/O darbogazı olabilir
     to: sysadmin
EOF

Bellek alarmları için:

cat > /etc/netdata/health.d/memory-custom.conf << 'EOF'
# RAM kullanımı %90 üzerine çıkınca uyar
alarm: ram_usage_critical
     on: system.ram
 lookup: average -5m unaligned of used
  units: %
  every: 1m
   warn: $this > 80
   crit: $this > 90
  delay: down 15m multiplier 1.5 max 1h
   info: RAM kullanimi kritik seviyede
     to: sysadmin

# Swap kullanımı başlayınca uyar
alarm: swap_usage
     on: system.swap
 lookup: average -5m unaligned of used
  units: %
  every: 2m
   warn: $this > 20
   crit: $this > 60
  delay: down 1h multiplier 2 max 2h
   info: Swap kullanimi basladı, RAM yetersiz olabilir
     to: sysadmin
EOF

# Servisi yeniden başlat
systemctl restart netdata

Email ve Slack Bildirimleri

Alarmları Slack’e göndermek için:

# Notification konfigürasyonu
nano /etc/netdata/health_alarm_notify.conf

# Slack webhook ekle
SLACK_WEBHOOK_URL="https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK"
DEFAULT_RECIPIENT_SLACK="#alarms"

# Email için
sendmail="yes"
EMAIL_SENDER="[email protected]"
DEFAULT_RECIPIENT_EMAIL="[email protected]"

Netdata API ile Otomasyon

Netdata’nın REST API’si sayesinde metrikleri script’lerinizde kullanabilirsiniz. Bu özellikle kapasiye planlaması veya custom dashboard için çok işe yarıyor:

# Son 1 saatlik CPU ortalamasını çek
curl -s "http://localhost:19999/api/v1/data?chart=system.cpu&after=-3600&points=1&group=average" | 
    python3 -c "import sys,json; d=json.load(sys.stdin); print('CPU Avg:', d['data'][0][1], '%')"

# Bellek kullanımını JSON olarak al
curl -s "http://localhost:19999/api/v1/data?chart=system.ram&after=-300&points=1&group=average" | 
    python3 -c "
import sys, json
data = json.load(sys.stdin)
labels = data['labels']
values = data['data'][0]
for i, label in enumerate(labels[1:], 1):
    print(f'{label}: {values[i]:.0f} MB')
"

# Alarm durumlarını kontrol et
curl -s "http://localhost:19999/api/v1/alarms?active" | 
    python3 -m json.tool | grep -E '"name"|"status"|"value"'

Gerçek Dünya Senaryosu: Web Sunucusu Performans Analizi

Diyelim ki bir e-ticaret sitesi yönetiyorsunuz. Sabah 10-11 arası yoğun saatlerde kullanıcılar yavaşlama şikayeti bildiriyor. Netdata ile bunu nasıl analiz edersiniz?

1. Zaman aralığını sabah 9:30 – 11:30 yapın

Netdata arayüzünde üst sağdaki zaman seçicisinden bu aralığı seçin.

2. CPU grafiğine bakın

system CPU kullanımı yüksekse kernel düzeyinde bir sorun var. user yüksekse uygulama katmanında. iowait yüksekse veritabanı veya dosya sistemi sorunu.

3. Korelasyon analizi yapın

Netdata’nın güzel özelliği birden fazla metriği aynı zaman ekseninde gösterebilmesi. CPU spike’ı ile network giriş/çıkışını, disk I/O’yu ve bellek kullanımını aynı anda görerek korelasyon bulabilirsiniz.

4. Process bazlı analiz

# O saatlerde ne olduğunu öğren (atop kayıt varsa)
# Önce atop kurulumu ve kayıt başlatma
apt install atop -y
systemctl enable --now atop

# Geçmiş kayıtları oku
atop -r /var/log/atop/atop_$(date +%Y%m%d) -b 10:00 -e 11:00

# Sadece CPU ve bellek
atop -r /var/log/atop/atop_$(date +%Y%m%d) -b 10:00 -M -C

Çoklu Sunucu İzleme

Birden fazla sunucu yönetiyorsanız Netdata’nın “Parents” özelliği ile merkezi bir izleme yapısı kurabilirsiniz:

# Ana sunucuda (parent) streaming aktif et
cat >> /etc/netdata/stream.conf << 'EOF'
[11111111-2222-3333-4444-555555555555]
    enabled = yes
    history = 3600
    default memory mode = dbengine
    health enabled by default = auto
EOF

# Agent sunucularda (child) parent'a gönder
cat >> /etc/netdata/stream.conf << 'EOF'
[stream]
    enabled = yes
    destination = parent-server-ip:19999
    api key = 11111111-2222-3333-4444-555555555555
EOF

# Servisleri yeniden başlat
systemctl restart netdata

Bu yapı ile tüm sunucularınızı tek bir Netdata arayüzünden izleyebilirsiniz. Parent sunucusu hem kendi metriklerini hem de child’lardan gelen metrikleri depolar.

Performans Optimizasyonu: Netdata’nın Kendi Ayak İzi

Netdata çok iyi bir iş çıkarıyor ama yoğun sistemlerde kendisi de kaynak tüketiyor. Bunu minimize etmek için:

# Gereksiz plugin'leri kapat
cat >> /etc/netdata/netdata.conf << 'EOF'
[plugins]
    # Kullanmadığınız plugin'leri kapat
    fping = no
    nfacct = no
    xenstat = no
    ioping = no
    
[plugin:proc]
    # Çok detaylı proc metrikleri kapat
    /proc/net/dev/bytes = yes
    /proc/net/dev/packets = no  # Paket sayısına ihtiyacınız yoksa
    /proc/net/dev/errors = yes

[db]
    # Daha az veri tut
    retention = 3600  # 1 saat
    update every = 2  # 1 yerine 2 saniyede bir güncelle
EOF

systemctl restart netdata

Sonuç

Netdata, sistem yöneticilerinin toolbox’ında olması gereken araçların başında geliyor. CPU ve bellek izleme söz konusu olduğunda 1 saniyelik çözünürlük, otomatik alarm sistemi ve sıfır konfigürasyon gerektiren kurulumu ile rakiplerine karşı ciddi bir avantaj sağlıyor. Özellikle iowait, steal gibi CPU modlarını gerçek zamanlı izlemek ve bellek sızıntılarını trend analizi ile tespit etmek için Netdata’nın sunduğu görselleştirme çok değerli.

Başlangıç için şu adımları takip etmenizi öneririm: Önce kurulumu yapın ve birkaç gün normal çalışma halinde sisteminizi izleyin. Baseline’ı öğrenin, normal CPU ve bellek trendlerini kafanıza yerleştirin. Sonra alarm eşiklerini bu baseline’a göre ayarlayın. Son olarak atop ile tarihsel kayıt mekanizmasını da devreye alın ki Netdata’nın göremediği noktalarda da geçmişe bakabilin.

Sunucu izleme reaktif değil proaktif bir iş olmalı. Kullanıcı şikayet etmeden önce siz fark etmeli ve müdahale etmelisiniz. Netdata tam da bu felsefe üzerine kurulu.

Benzer Konular

Bir yanıt yazın

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