Netdata Veri Saklama: Bellek ve Disk Yapılandırması

Bykomut

Netdata kurduğunuzda ilk etapta her şey harika görünür: gerçek zamanlı metrikler akıyor, grafikler güzel çiziliyor, sunucunuzun nabzını tutuyorsunuz. Ama birkaç gün sonra fark ediyorsunuz ki Netdata varsayılan ayarlarla belleği oldukça agresif kullanıyor ve disk üzerindeki veri saklama süresi beklediğinizden çok daha kısa. İşte bu noktada “veri saklama yapılandırması” konusu hayatınıza giriyor.

Bu yazıda Netdata’nın veri saklama mimarisini, bellek ve disk yapılandırmasını, DBENGINE ayarlarını ve gerçek dünya senaryolarında nasıl optimize edeceğinizi detaylıca ele alacağız.

Netdata’nın Veri Saklama Mimarisi

Netdata iki farklı storage backend kullanır: RAM-only (alloc/ram) ve DBENGINE. Versiyon 1.23 ve sonrasında varsayılan olarak DBENGINE gelir, bu da hem bellek hem disk üzerinde veri saklamak anlamına gelir.

DBENGINE Nasıl Çalışır?

DBENGINE, Netdata’nın kendi geliştirdiği bir zaman serisi veritabanı motorudur. Verileri önce bellekte tutar (hot data), sonra belirli bir eşiğe ulaşınca disk üzerine yazar (cold data). Bu hibrit yapı sayesinde hem hızlı okuma hem de uzun süreli saklama mümkün olur.

Veri akışı şu şekilde işler:

  • Metrikler önce RAM’deki page cache’e yazılır
  • Page cache dolduğunda veya belirli zaman aralıklarında veriler disk üzerine flush edilir
  • Disk üzerindeki veriler tier sistemiyle farklı çözünürlüklerde saklanır
  • Okuma işlemlerinde önce cache kontrol edilir, cache miss durumunda diskten okunur

Tier Sistemi

Netdata 1.35+ sürümüyle birlikte çok katmanlı (multi-tier) veri saklama geldi. Bu sistemde:

  • Tier 0: Ham veri, saniye bazında çözünürlük, kısa süreli saklama
  • Tier 1: Düşürülmüş çözünürlük (dakika bazında), orta vadeli saklama
  • Tier 2: Daha da düşürülmüş çözünürlük (saat bazında), uzun vadeli saklama

Bu yapı sayesinde 1 yıllık trend verisi saklarken disk alanını makul tutabilirsiniz.

Mevcut Yapılandırmayı Anlamak

Yapılandırmaya geçmeden önce mevcut durumu anlamalısınız. Netdata’nın ana yapılandırma dosyası /etc/netdata/netdata.conf dosyasıdır.

# Mevcut yapılandırmayı görüntüle
cat /etc/netdata/netdata.conf

# Netdata'nın aktif olarak kullandığı yapılandırmayı görmek için
sudo /etc/netdata/edit-config netdata.conf

# Netdata'nın bellek kullanımını kontrol et
ps aux | grep netdata
sudo cat /proc/$(pgrep -f 'netdata -D')/status | grep -i vm

Netdata’nın kendi durum sayfasını da kullanabilirsiniz. Tarayıcıdan http://sunucu-ip:19999/api/v1/info adresine giderek mevcut yapılandırma bilgilerini JSON formatında görebilirsiniz.

# API üzerinden bilgi almak
curl -s http://localhost:19999/api/v1/info | python3 -m json.tool | grep -A5 "memory"

# Disk kullanımını kontrol et
du -sh /var/cache/netdata/
du -sh /var/lib/netdata/

netdata.conf İçinde Bellek Ayarları

Ana yapılandırma dosyasının [global] bölümünde bellek ile ilgili temel ayarlar bulunur.

sudo nano /etc/netdata/netdata.conf
[global]
    # DBENGINE page cache boyutu (MB cinsinden)
    # Bu değer ne kadar büyükse o kadar fazla veri RAM'de tutulur
    dbengine page cache size = 32

    # Disk alanı miktarı (MB cinsinden) - her tier için ayrı ayarlanır
    dbengine multihost disk space = 256

    # Storage tipi: dbengine, ram, alloc, none
    memory mode = dbengine

    # RAM-only modda tutulacak boyut (memory mode = ram/alloc ise geçerli)
    # history = 3600

dbengine page cache size: Bu değer RAM’de tutulacak veri miktarını belirler. 32MB küçük sunucular için yeterli olabilir, ama yüksek kardinaliteli (çok sayıda metrik toplayan) sunucularda 256MB veya daha fazla gerekebilir.

dbengine multihost disk space: Disk üzerinde kullanılacak toplam alan. Bu değeri artırdıkça daha uzun geçmişe erişebilirsiniz.

DBENGINE Tier Yapılandırması

Çok katmanlı saklama için [db] bölümünü kullanıyoruz. Bu yapılandırma hem performansı hem de saklama süresini doğrudan etkiler.

sudo nano /etc/netdata/netdata.conf
[db]
    # Storage modu
    mode = dbengine

    # Tier 0: Ham veri (saniye bazında)
    # Page cache boyutu
    dbengine tier 0 page cache size = 32

    # Tier 0 disk alanı (MB)
    dbengine tier 0 disk space = 1024

    # Tier 1: Dakika bazında veri
    dbengine tier 1 page cache size = 8

    # Tier 1 disk alanı (MB)
    dbengine tier 1 disk space = 512

    # Tier 2: Saat bazında veri
    dbengine tier 2 page cache size = 4

    # Tier 2 disk alanı (MB)
    dbengine tier 2 disk space = 256

Bu yapılandırmayla:

  • Tier 0’da yaklaşık 2-7 günlük saniye bazında veri saklarsınız
  • Tier 1’de yaklaşık 1-3 aylık dakika bazında veri saklarsınız
  • Tier 2’de yaklaşık 6-24 aylık saat bazında veri saklarsınız

Gerçek süreler metrik sayısına ve güncelleme sıklığına göre değişir.

Gerçek Dünya Senaryosu 1: Küçük VPS Optimizasyonu

Elimde 2GB RAM’li bir VPS var ve Netdata belleğin neredeyse %20’sini yiyor. Bu senaryo için minimalist bir yapılandırma oluşturalım.

# Önce mevcut bellek kullanımını belgeleyelim
free -h
ps aux --sort=-%mem | head -5

# Netdata'nın kaç metrik topladığını görelim
curl -s http://localhost:19999/api/v1/charts | python3 -c "import json,sys; d=json.load(sys.stdin); print(f'Toplam chart: {len(d["charts"])}')"

Küçük VPS için optimum yapılandırma:

[db]
    mode = dbengine
    dbengine tier 0 page cache size = 16
    dbengine tier 0 disk space = 256
    dbengine tier 1 page cache size = 4
    dbengine tier 1 disk space = 128
    dbengine tier 2 page cache size = 2
    dbengine tier 2 disk space = 64

[global]
    # Güncelleme sıklığını artır (daha az veri yazılır)
    update every = 2

    # Gereksiz plugin'leri kapat
    # plugins.d kısmında da ayarlanabilir

Güncelleme sıklığını 1’den 2’ye çıkarmak, üretilen veri miktarını yarıya indirir ve hem RAM hem disk kullanımını önemli ölçüde azaltır.

Gerçek Dünya Senaryosu 2: Üretim Ortamı için Uzun Süreli Saklama

Şirkette bir e-ticaret sunucusunu izliyorsunuz ve 6 aylık trend analizi yapmak istiyorsunuz. Sunucunuzda 16GB RAM ve ayrılmış 50GB disk alanı var.

# Mevcut disk yapısını kontrol et
df -h /var/cache/netdata/
ls -la /var/cache/netdata/

# Netdata data dizinini ayrı bir disk bölümüne taşıma
sudo systemctl stop netdata
sudo mv /var/cache/netdata /data/netdata-cache
sudo ln -s /data/netdata-cache /var/cache/netdata
sudo systemctl start netdata

Üretim ortamı için yapılandırma:

[db]
    mode = dbengine

    # Tier 0: 7 günlük saniye verisi için ~2GB alan
    dbengine tier 0 page cache size = 128
    dbengine tier 0 disk space = 2048

    # Tier 1: 90 günlük dakika verisi için ~5GB alan
    dbengine tier 1 page cache size = 32
    dbengine tier 1 disk space = 5120

    # Tier 2: 730 günlük saat verisi için ~8GB alan
    dbengine tier 2 page cache size = 16
    dbengine tier 2 disk space = 8192

[global]
    update every = 1
    # Bellek baskısı durumunda ne yapılacağı
    # dbengine pages per extent = 64

Veri Saklama Süresini Hesaplama

Kaç günlük veri saklayabileceğinizi hesaplamak için şu formülü kullanabilirsiniz:

Saklama Süresi (gün) = (Disk Alanı MB * 1024 * 1024) / (Metrik Sayısı * Saniye başına byte * 86400)

Bunu basit bir bash scriptiyle hesaplayalım:

#!/bin/bash
# retention_calculator.sh

DISK_MB=1024
METRIC_COUNT=$(curl -s http://localhost:19999/api/v1/charts | python3 -c "
import json, sys
d = json.load(sys.stdin)
total = sum(len(v.get('dimensions', {})) for v in d['charts'].values())
print(total)
")

BYTES_PER_METRIC_PER_SEC=2
RETENTION_DAYS=$(echo "scale=2; ($DISK_MB * 1024 * 1024) / ($METRIC_COUNT * $BYTES_PER_METRIC_PER_SEC * 86400)" | bc)

echo "Toplam boyutlu metrik sayisi: $METRIC_COUNT"
echo "Disk alani: ${DISK_MB}MB"
echo "Tahmini saklama suresi: ${RETENTION_DAYS} gun"
chmod +x retention_calculator.sh
./retention_calculator.sh

Gereksiz Metrikleri Filtrelemek

Bellek ve disk kullanımını azaltmanın en etkili yollarından biri gereksiz metrikleri toplamayı durdurmaktır.

# Hangi plugin'lerin aktif olduğunu gör
sudo ls /etc/netdata/
sudo cat /etc/netdata/netdata.conf | grep -A50 "[plugins]"

# Bir plugin'i devre dışı bırak
sudo nano /etc/netdata/netdata.conf
[plugins]
    # Kullanmadığınız plugin'leri kapat
    charts.d = no
    node.d = no
    python.d = no   # Python plugin'lerini kullanmıyorsanız
    nfacct = no
    xenstat = no
    ipvs = no

    # Temel plugin'ler - bunları kapatmayın
    proc = yes
    diskspace = yes
    cgroups = yes
    tc = yes

Belirli diskspace veya network interface metriklerini filtrelemek için:

# Diskspace filtreleme
sudo nano /etc/netdata/diskspace.conf
[plugin:proc:diskspace]
    # Sadece bu mount point'leri izle
    exclude space metrics on paths = /proc /sys /run /dev
    exclude space metrics on filesystems = tmpfs devtmpfs

Bellek Optimizasyonu: Sayfa Önbelleği Yönetimi

DBENGINE’in bellek kullanımı temel olarak iki bileşenden oluşur: page cache ve metadata overhead. Page cache boyutunu sisteminize göre ayarlamak kritik öneme sahiptir.

# Netdata'nın gerçek zamanlı bellek kullanımını izle
watch -n 2 'cat /proc/$(pgrep netdata | head -1)/status | grep -E "VmRSS|VmSwap|VmPeak"'

# Detaylı bellek haritası
cat /proc/$(pgrep netdata | head -1)/smaps | awk '/^[0-9a-f]/{header=$0} /Rss/{rss+=$2} END{print "Total RSS:", rss, "kB"}'

Eğer sisteminiz bellek baskısıyla karşılaşıyorsa, Netdata bunu otomatik olarak yönetebilir:

[global]
    # Bellek baskısı durumunda otomatik disk flush
    # Bu ayar DBENGINE'in agresif biçimde cache temizlemesini sağlar
    dbengine page cache size = 16

    # OOM killer'dan koruma - Netdata process'ine düşük OOM skoru ver
    # Bu netdata.conf'ta değil, systemd service dosyasında ayarlanır
# Netdata systemd service dosyasını düzenle
sudo systemctl edit netdata

# Açılan editöre şunu ekle:
[Service]
OOMScoreAdjust=-500

Yapılandırma Değişikliklerini Doğrulama

Yapılandırma değişikliklerini yaptıktan sonra bunları doğrulamak önemlidir.

# Netdata'yı yeniden başlat
sudo systemctl restart netdata

# Başlangıç loglarını kontrol et
sudo journalctl -u netdata -n 50 --no-pager

# Hata var mı diye bak
sudo journalctl -u netdata --since "5 minutes ago" | grep -iE "error|warn|critical"

# API üzerinden saklama bilgilerini kontrol et
curl -s "http://localhost:19999/api/v1/info" | python3 -m json.tool | grep -A3 "db"

# Mevcut veri boyutunu kontrol et
du -sh /var/cache/netdata/dbengine/
ls -lh /var/cache/netdata/dbengine/

Netdata’nın dashboard’unda da Netdata Monitoring bölümünden dbengine istatistiklerini görebilirsiniz. Özellikle “dbengine read calls” ve “dbengine cache hit ratio” metrikleri cache boyutunuzun yeterli olup olmadığını gösterir.

# Cache hit oranını API'den çek
curl -s "http://localhost:19999/api/v1/data?chart=netdata.dbengine_cache_efficiency&after=-300" | 
python3 -c "
import json, sys
d = json.load(sys.stdin)
print('Cache Hit Ratio verileri:')
for point in d['data'][-5:]:
    print(f'  {point}')
"

Cache hit oranı %70’in altına düşüyorsa page cache boyutunu artırmanız gerekir.

Eski Verileri Temizleme ve Bakım

Zaman zaman disk alanını geri kazanmak için eski verileri temizlemeniz gerekebilir. DBENGINE verilerini elle silmek risklidir, bunun yerine yapılandırma yoluyla kontrol edin.

# Netdata'yı durdur
sudo systemctl stop netdata

# DBENGINE veri dizinini temizle (TÜM VERİLER SİLİNİR!)
sudo rm -rf /var/cache/netdata/dbengine/*

# Netdata'yı yeniden başlat - yeni bir DB oluşturacak
sudo systemctl start netdata

# Boyut kontrolü
du -sh /var/cache/netdata/

Dikkat: Bu işlem tüm geçmiş verileri siler. Üretim ortamında yapmadan önce dikkatli düşünün.

Daha güvenli bir alternatif, disk alanını azaltarak Netdata’nın eski verileri otomatik silmesine izin vermektir:

# Mevcut alan kullanımını belgele
du -sh /var/cache/netdata/dbengine/

# Yapılandırmada disk alanını mevcut kullanımın altına çek
# Netdata yeniden başlatıldığında eski verileri otomatik temizler
sudo nano /etc/netdata/netdata.conf
# dbengine tier 0 disk space değerini azalt

sudo systemctl restart netdata

# Birkaç dakika sonra kontrol et
du -sh /var/cache/netdata/dbengine/

İzleme ve Alarm Kurulumu

Netdata’nın kendi bellek ve disk kullanımını izlemek için alarm kuralları ekleyebilirsiniz.

sudo nano /etc/netdata/health.d/netdata_storage.conf
# Netdata cache boyutu alarmı
alarm: netdata_dbengine_cache_pressure
    on: netdata.dbengine_compression_ratio
    lookup: average -10m
    warn: $this < 50
    crit: $this < 20
    info: DBENGINE cache hit orani dusuk, page cache boyutunu artirin

# Disk doluluk alarmı
alarm: netdata_cache_disk_usage
    on: disk.space
    hosts: localhost
    lookup: average -1m of used
    calc: ($used * 100) / ($avail + $used)
    warn: $this > 80
    crit: $this > 90
    info: Netdata cache disk dolulugu yuksek
# Alarm yapılandırmasını yeniden yükle
sudo kill -USR2 $(pgrep netdata)

Netdata Cloud ile Entegrasyon Durumunda Dikkat Edilecekler

Netdata Cloud kullanıyorsanız, yerel veri saklama yapılandırması hala önemlidir. Cloud sadece streaming ve metadata tutar, ham veriler yerel olarak saklanır.

# Cloud bağlantı durumunu kontrol et
curl -s http://localhost:19999/api/v1/info | python3 -m json.tool | grep -i cloud

# Streaming yapılandırması
sudo cat /etc/netdata/stream.conf

Cloud kullanımında update every = 1 tutmak faydalıdır çünkü cloud’a gönderilen veri çözünürlüğünü belirler. Ancak yerel disk alanını korumak istiyorsanız tier yapılandırmasını buna göre optimize edin.

Sonuç

Netdata veri saklama yapılandırması, sunucunuzun kaynaklarını ve izleme ihtiyaçlarınızı dengede tutmanın kritik bir parçasıdır. Özetleyecek olursak:

  • Küçük sunucular için page cache boyutunu 16-32MB’da tutun, disk alanını makul tutun ve update every = 2 yapın
  • Üretim sunucuları için tier yapılandırmasına yatırım yapın, Tier 1 ve Tier 2’ye yeterli disk alanı ayırın
  • Cache hit oranını düzenli kontrol edin, %70’in altına düşünce page cache boyutunu artırın
  • Gereksiz metrikleri plugin seviyesinde devre dışı bırakın, bu hem bellek hem disk tasarrufu sağlar
  • OOM koruması için systemd service dosyasına OOMScoreAdjust ekleyin

Yapılandırma değişikliklerini yaparken her zaman küçük adımlarla ilerleyin ve her adımdan sonra journalctl ile log kontrolü yapın. Netdata’nın kendi monitoring bölümü size cache verimliliği ve disk kullanımı hakkında gerçek zamanlı geri bildirim verecektir. Bu metrikleri düzenli takip etmek, sisteminiz için doğru dengeyi bulmanızı kolaylaştıracaktır.

Benzer Konular

Bir yanıt yazın

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