Netdata ile Anomali Tespiti ve Makine Öğrenmesi

Sunucularınız gece 3’te anormal davranmaya başlıyor, siz uyuyorsunuz ve sabah işe geldiğinizde bir felaket sizi bekliyor. Bu senaryo, klasik eşik tabanlı izleme sistemlerinin en büyük açmazını özetliyor: bir metrik belirlediğiniz eşiği geçmeden alarm çalmıyor, ama o eşiği geçtiğinde iş işten geçmiş olabiliyor. Netdata’nın makine öğrenmesi tabanlı anomali tespit motoru tam da bu boşluğu kapatmak için tasarlandı.

Netdata Anomali Tespiti Nedir?

Netdata 1.32 sürümüyle birlikte gelen ML tabanlı anomali skoru özelliği, her metrik için geçmiş verileri kullanarak “normal” davranış modelini öğreniyor. Sistem daha sonra gerçek zamanlı olarak gelen yeni verileri bu modelle karşılaştırıyor ve sapmaları puanlıyor.

Teknik olarak Netdata, her metrik için k-means kümeleme algoritması kullanıyor. Varsayılan ayarlarda son 4 saat ile 24 saat arasındaki veriyi eğitim verisi olarak kullanıyor ve her dakika modeli güncelliyor. Bu yaklaşım, hem ani spike’ları hem de yavaş yavaş kötüleşen durumları yakalamayı mümkün kılıyor.

Anomali skoru 0 ile 1 arasında bir değer alıyor:

• 0: Tamamen normal, beklenen davranış
• 1: Kesinlikle anomali, modelin hiç görmediği bir durum
• 0.5 üzeri: Dikkat edilmesi gereken bölge

Kurulum ve Ön Gereksinimler

Anomali tespiti için Netdata’nın en az 1.32 veya üzeri sürümünü kullanmanız gerekiyor. Güncel kurulum için:

# Mevcut Netdata sürümünü kontrol et
netdata --version

# Otomatik kurulum scripti ile güncel sürümü yükle
wget -O /tmp/netdata-kickstart.sh https://my-netdata.io/kickstart.sh
sudo sh /tmp/netdata-kickstart.sh --stable-channel

# Servis durumunu kontrol et
sudo systemctl status netdata

ML motorunun aktif olduğunu doğrulamak için:

# Netdata config dosyasını bul
sudo netdata -W dump-config | grep -A 20 "ml"

# Alternatif olarak config dosyasını doğrudan kontrol et
sudo cat /etc/netdata/netdata.conf | grep -A 10 "[ml]"

Eğer ML bölümü görünmüyorsa netdata.conf dosyasına manuel olarak eklemeniz gerekiyor:

sudo nano /etc/netdata/netdata.conf

Dosyaya şu bölümü ekleyin:

[ml]
    # ML motorunu aktif et
    enabled = yes
    
    # Eğitim için minimum veri noktası sayısı (varsayılan: 900)
    minimum num samples to train = 900
    
    # Maksimum eğitim verisi sayısı
    maximum num samples to train = 14400
    
    # Eğitim aralığı (saniye cinsinden, varsayılan: 3600 = 1 saat)
    train every = 3600
    
    # Anomali skoru eşiği (bu değerin üzerindekiler anomali sayılır)
    # 0.99 demek %99 güven aralığı dışında kalan
    maximum num k-means iterations = 1000

Değişiklikleri uygulamak için:

sudo systemctl restart netdata
# veya daha nazik bir yöntem:
sudo kill -HUP $(pidof netdata)

Anomali Skorlarını İzleme

Netdata, her metrik için anomali skorunu anomaly_detection namespace’i altında saklıyor. Bu skorları Netdata’nın kendi arayüzünden veya API üzerinden sorgulayabilirsiniz.

Web Arayüzü Üzerinden

Netdata’nın web arayüzüne bağlandığınızda (varsayılan port 19999), her grafiğin sağ üst köşesinde küçük bir beyin ikonu görürsünüz. Bu ikona tıkladığınızda ilgili metriğin anomali skorunu normal metrikle üst üste görebilirsiniz.

Ayrıca sol menüden Anomaly Advisor bölümüne giderek sistemdeki tüm anomalileri tek bir yerden görebilirsiniz. Bu bölüm özellikle bir sorun yaşandığında “neyin anormal olduğunu” hızlıca tespit etmek için son derece kullanışlı.

API Üzerinden Anomali Skorlarını Çekme

# Bir sunucunun anomali skorlarını API ile sorgula
curl -s "http://localhost:19999/api/v1/data?chart=anomaly_detection.anomaly_rates&after=-300&format=json" | python3 -m json.tool

# Belirli bir zaman aralığı için anomali verisi
# after ve before parametreleri Unix timestamp veya negatif saniye kabul eder
curl -s "http://localhost:19999/api/v1/data?chart=system.cpu&after=-3600&options=anomaly-bit" | python3 -m json.tool

Anomali bitmap verisi çekmek için daha detaylı bir sorgu:

# Son 1 saatin anomali verilerini JSON formatında çek ve kaydet
curl -s "http://localhost:19999/api/v1/data?
chart=system.cpu&
after=-3600&
before=0&
points=60&
group=average&
options=anomaly-bit%7Cjson2" 
-o /tmp/cpu_anomaly_last_hour.json

# Sonucu görüntüle
cat /tmp/cpu_anomaly_last_hour.json | python3 -c "
import json, sys
data = json.load(sys.stdin)
print('Toplam veri noktasi:', len(data.get('data', [])))
anomalies = [d for d in data.get('data', []) if d[1] > 0]
print('Anomali sayisi:', len(anomalies))
"

Özel Anomali Bildirimleri Kurma

Varsayılan anomali bildirimleri genellikle çok gürültülü veya çok sessiz oluyor. Kendi ihtiyaçlarınıza göre özelleştirmek için Netdata’nın alarm sistemiyle ML skorlarını birleştirmeniz gerekiyor.

health.d Altında Özel Anomali Alarmı

sudo nano /etc/netdata/health.d/ml-anomaly.conf

# CPU anomali alarmı - yüksek anomali skoru için uyar
alarm: cpu_anomaly_high
     on: anomaly_detection.anomaly_rates
     os: linux
  hosts: *
 lookup: average -5m unaligned of system.cpu
  every: 1m
   warn: $this > 0.5
   crit: $this > 0.8
  delay: up 2m down 5m multiplier 1.5 max 1h
   info: CPU metrikleri son 5 dakikada anormal davranış gösteriyor
     to: sysadmin

# Bellek anomali alarmı
alarm: memory_anomaly
     on: anomaly_detection.anomaly_rates
     os: linux
  hosts: *
 lookup: average -10m unaligned of system.ram
  every: 2m
   warn: $this > 0.6
   crit: $this > 0.85
  delay: up 5m down 10m multiplier 1.2 max 2h
   info: Bellek kullanımı beklenmedik bir anomali gösteriyor
     to: sysadmin

Alarmı test etmek için:

# Alarm konfigürasyonunu doğrula
sudo netdatacli reload-health

# Mevcut alarm durumlarını kontrol et
sudo netdatacli alarms-values

# Belirli bir alarm için detay
sudo netdatacli get-raw-stream 2>/dev/null | grep "ml-anomaly"

Gerçek Dünya Senaryosu: Yavaş Bir Memory Leak’i Yakalamak

Klasik bir senaryo: production sunucunuzda çalışan bir Java uygulaması günde birkaç MB bellek sızdırıyor. Eşik tabanlı alarmınız ancak bellek %90’a geldiğinde çalıyor, ama o noktada JVM zaten yaşlı nesil GC baskısı altında ve servis kalitesi ciddi şekilde düşmüş oluyor.

ML tabanlı yaklaşımda sistem şunu fark ediyor: her gün sabah bellek şu kadar, akşam şu kadar. Ama bu hafta sabah başlangıç değerleri her gün biraz daha yüksek. Bu monoton artış paterni, normal kullanım paterninden sapıyor ve anomali skoru yavaş yavaş yükseliyor.

Bu tür bir durumu tespit etmek için özel bir izleme scripti yazabilirsiniz:

#!/bin/bash
# /usr/local/bin/netdata-ml-monitor.sh
# Anomali skorlarını izle ve trend analizi yap

NETDATA_URL="http://localhost:19999"
THRESHOLD=0.4
LOG_FILE="/var/log/netdata-ml-monitor.log"
ALERT_EMAIL="[email protected]"

check_anomaly_trend() {
    local chart=$1
    local dimension=$2
    
    # Son 2 saatin verilerini çek
    local data=$(curl -s "${NETDATA_URL}/api/v1/data?
chart=${chart}&
after=-7200&
points=120&
group=average&
options=anomaly-bit" 2>/dev/null)
    
    if [ -z "$data" ]; then
        echo "$(date): HATA - $chart için veri alınamadı" >> "$LOG_FILE"
        return
    fi
    
    # Python ile trend analizi
    local trend=$(echo "$data" | python3 -c "
import json, sys

try:
    data = json.load(sys.stdin)
    points = [d[1] for d in data.get('data', []) if d[1] is not None]
    
    if len(points) < 10:
        print('insufficient_data')
        sys.exit(0)
    
    # Son 30 vs ilk 30 karşılaştır
    first_half = sum(points[:30]) / 30
    second_half = sum(points[-30:]) / 30
    
    if second_half > first_half * 1.5 and second_half > 0.3:
        print(f'INCREASING_TREND:{first_half:.3f}:{second_half:.3f}')
    elif second_half > 0.6:
        print(f'HIGH_ANOMALY:{second_half:.3f}')
    else:
        print(f'NORMAL:{second_half:.3f}')
except Exception as e:
    print(f'ERROR:{e}')
" 2>/dev/null)
    
    echo "$(date): $chart -> $trend" >> "$LOG_FILE"
    
    # Artan trend varsa uyar
    if echo "$trend" | grep -q "INCREASING_TREND|HIGH_ANOMALY"; then
        echo "UYARI: $chart anomali trendi tespit edildi: $trend" | 
            mail -s "[Netdata ML] Anomali Trendi: $chart" "$ALERT_EMAIL"
    fi
}

# İzlenecek metrikleri kontrol et
check_anomaly_trend "system.ram" "used"
check_anomaly_trend "system.cpu" "user"
check_anomaly_trend "system.io" "in"
check_anomaly_trend "system.net" "received"

echo "$(date): ML anomali kontrolü tamamlandı" >> "$LOG_FILE"

Script’i cron’a ekleyin:

chmod +x /usr/local/bin/netdata-ml-monitor.sh

# Her 15 dakikada bir çalıştır
echo "*/15 * * * * root /usr/local/bin/netdata-ml-monitor.sh" | 
    sudo tee /etc/cron.d/netdata-ml-monitor

# Log rotasyonu ekle
sudo tee /etc/logrotate.d/netdata-ml-monitor << 'EOF'
/var/log/netdata-ml-monitor.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
}
EOF

Çoklu Sunucu Ortamında Anomali Korelasyonu

Tek bir sunucudaki anomali bazen önemsiz olabilir, ama aynı anda birden fazla sunucuda anomali görülmesi ciddi bir sorunun işareti. Özellikle mikroservis mimarilerinde bu durum çok daha kritik.

Netdata Parent-Child mimarisini kullanarak tüm sunucuların anomali verilerini merkezi bir noktada toplayabilirsiniz:

# Parent sunucu konfigürasyonu (stream.conf)
sudo nano /etc/netdata/stream.conf

# Parent sunucuda - gelen bağlantıları kabul et
[stream]
    enabled = yes

# Her child için bir API key tanımla
[API_KEY_BURAYA]
    enabled = yes
    default history = 86400
    default memory mode = dbengine
    health enabled by default = auto
    allow from = *

Child sunucularda (izlenen sunucular):

# Child sunucu stream.conf
[stream]
    enabled = yes
    destination = parent-sunucu-ip:19999
    api key = API_KEY_BURAYA
    timeout seconds = 60
    buffer size bytes = 1048576
    reconnect delay seconds = 5
    initial clock resync iterations = 60

Bu yapıyı kurduktan sonra parent sunucuda tüm child’ların anomali skorlarını tek bir sorguyla çekebilirsiniz:

# Parent üzerinden tüm node'ların anomali özetini al
curl -s "http://parent-sunucu:19999/api/v1/info" | 
    python3 -c "
import json, sys
data = json.load(sys.stdin)
nodes = data.get('mirrored_hosts', [])
print(f'Toplam izlenen sunucu: {len(nodes)}')
for node in nodes:
    print(f'  - {node}')
"

ML Modelinin Kalibrasyonu ve İyileştirme

Makine öğrenmesi modelleri kutudan çıktığı gibi mükemmel çalışmaz. Özellikle ilk birkaç günde çok fazla false positive alabilirsiniz. Bunu minimize etmek için bazı pratik adımlar:

Planlı Bakım Dönemlerinde ML’yi Uyarma

Sunucunuza yüksek yük bindireceğiniz bir batch iş çalıştıracaksanız, ML motoruna bu durumu bildirmeniz gerekiyor. Aksi takdirde model bu yükü de “normal” olarak öğrenebilir ya da gereksiz alarmlar üretir:

# Bakım modu başlat - ML eğitimini geçici durdur
sudo netdatacli ml-training-start
# veya API üzerinden
curl -s -X POST "http://localhost:19999/api/v1/manage/health?cmd=SILENCE&context=anomaly_detection"

Belirli Metrikleri ML’den Hariç Tutma

Bazı metrikler doğası gereği çok değişken olabilir ve sürekli false positive üretir. Bu metrikleri ML’den hariç tutmak için:

sudo nano /etc/netdata/netdata.conf

[ml]
    enabled = yes
    
    # Bu pattern'lere uyan metrikleri ML'den hariç tut
    # Virgülle ayrılmış glob pattern'ler
    charts to skip from training = system.interrupts 
                                   system.softirqs 
                                   apps.cpu_*_percentage
    
    # Minimum veri kalitesi - bu değerin altında eğitim yapma
    # Çok değişken metriklere eğitim yapmamak için kullanılır
    minimum std dev = 0.01

Grafana ile Anomali Görselleştirmesi

Netdata’nın kendi arayüzü güzel ama ekibiniz Grafana kullanıyorsa anomali skorlarını oraya taşımak isteyebilirsiniz. Netdata’nın Prometheus exporter özelliğini kullanarak bunu yapabilirsiniz:

# Netdata'nın Prometheus endpoint'ini test et
curl -s "http://localhost:19999/api/v1/allmetrics?format=prometheus&help=yes" | 
    grep "anomaly" | head -20

Prometheus scrape konfigürasyonu:

# /etc/prometheus/prometheus.yml içine ekle
scrape_configs:
  - job_name: 'netdata-ml'
    metrics_path: '/api/v1/allmetrics'
    params:
      format: ['prometheus']
      # Sadece anomali metriklerini çek, bandwith tasarrufu için
      filter: ['anomaly_detection*']
    static_configs:
      - targets: 
          - 'sunucu1:19999'
          - 'sunucu2:19999'
          - 'sunucu3:19999'
    scrape_interval: 60s

Grafana’da anomali skorlarını göstermek için kullanabileceğiniz PromQL sorgusu:

# Tüm sunuculardaki yüksek anomali skorlarını göster
# Panel tipini "Heatmap" olarak ayarlayın
netdata_anomaly_detection_anomaly_rates_percentage{dimension=~"system.cpu|system.ram"} > 0.4

# Son 1 saatin maksimum anomali skorunu al
max_over_time(netdata_anomaly_detection_anomaly_rates_percentage[1h])

Anomali Tespitinin Sınırları ve Dikkat Edilmesi Gerekenler

ML tabanlı anomali tespiti güçlü bir araç ama sihirli bir değnek değil. Bazı önemli noktalar:

• Yeni kurulan sistemlerde dikkatli olun: Model en az 24-48 saatlik veriye ihtiyaç duyuyor. Bu süreçte çok fazla false positive göreceksiniz, buna hazırlıklı olun.
• Mevsimsel paternleri öğrenmesi zaman alır: Eğer sisteminizde haftalık döngüler varsa (hafta sonu düşük trafik gibi), modelin bunları öğrenmesi 1-2 hafta sürebilir.
• Anomali, sorun değildir: Yüksek anomali skoru bir şeylerin farklı gittiğini söyler, bunun iyi mi kötü mü olduğunu söylemez. Büyük bir kampanya sonucu artan trafik de anomali olarak görünebilir.
• Eşik değerlerini durumunuza göre ayarlayın: 0.5 eşiği bazı ortamlar için çok hassas, bazıları için çok toleranslı olabilir. İlk 2 haftayı gözlem yaparak geçirmenizi öneririm.
• Disk I/O ve network metrikleri genellikle gürültülü: Bu metriklerde anomali skorunun daha yüksek eşikte alarm üretmesi tercih edilebilir.

Sonuç

Netdata’nın ML tabanlı anomali tespiti, klasik eşik tabanlı izlemenin yerine geçmiyor, onun yanına ekleniyor. Eşik alarmlarınız “bir şey patlak” dediğinde çalıştırılıyor, ML alarmları ise “bir şeyler ters gitmeye başladı” dediğinde devreye giriyor. Bu iki katmanın birlikte çalışması, hem anlık krizleri hem de yavaş yavaş kötüleşen durumları yakalayabilen sağlam bir izleme altyapısı oluşturuyor.

Pratikte önerim şu: Önce 1-2 hafta boyunca sadece gözlem yapın, alarm üretmeyin. Bu sürede hangi metriklerin ne kadar değişken olduğunu, hangi pattern’lerin “normal” olduğunu anlayın. Sonra önce uyarı seviyesinde alarmları devreye alın, gerçek yangın alarmlarını ancak yeterli veri biriktikten sonra etkinleştirin. Bu yaklaşımla hem alarm yorgunluğunun önüne geçersiniz hem de gerçekten kritik durumlar için güvenilir bir erken uyarı sisteminiz olur.

Netdata bu özelliği açık kaynak ve ücretsiz sunuyor. 2500 euroya ticari anomali tespit araçları varken, iyi konfigüre edilmiş bir Netdata kurulumu production ortamlarında gayet tatmin edici sonuçlar veriyor. Denemek için hiçbir bahaneniz yok.