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.
