Netdata ile Alarm Yapılandırması: Eşik Değer Tabanlı Uyarı Sistemi

Sunucunuz gece 3’te çökmeye başlıyor, disk dolmak üzere ya da bellek tüketimi tavan yapıyor. Siz ise sabah işe geldiğinizde durumu fark ediyorsunuz. Bu klasik senaryo, her sysadmin’in bir kez yaşadığı ve bir daha yaşamak istemediği o acı tablodur. İşte tam bu noktada Netdata’nın alarm sistemi devreye giriyor. Doğru yapılandırılmış eşik değerleri ve uyarı mekanizmaları, sizi gece 3’te uyandırmak yerine problemi siz henüz uyurken tespit edip sabahın ilk saatlerinde aksiyon almanızı sağlıyor.

Netdata Alarm Sistemi Nasıl Çalışır

Netdata, izlediği her metrik için alarm kuralları tanımlamanıza izin verir. Bu kurallar belirli dosyalarda saklanır ve Netdata servisi bu dosyaları okuyarak hangi durumda hangi uyarının tetikleneceğini belirler.

Alarm sistemi temelde üç kavram üzerine kuruludur:

• WARNING (Uyarı): İzlenen değer tehlike sınırına yaklaşıyor, dikkat edilmeli
• CRITICAL (Kritik): Değer kritik eşiği geçti, acil müdahale gerekiyor
• CLEAR: Değer normale döndü, alarm durumu kalktı

Netdata her alarm değişikliğinde tanımladığınız notification metodunu (e-posta, Slack, PagerDuty vb.) kullanarak sizi haberdar eder. Alarm kuralları /etc/netdata/health.d/ dizininde .conf uzantılı dosyalarda tutulur.

Varsayılan olarak Netdata birçok hazır alarm kuralıyla gelir. Bunları /usr/lib/netdata/conf.d/health.d/ dizininde bulabilirsiniz. Ancak bu dosyaları doğrudan düzenlemeyin; bunun yerine /etc/netdata/health.d/ dizininde kendi dosyalarınızı oluşturun ya da orijinal dosyaları oraya kopyalayıp üzerinde çalışın.

Alarm Kural Dosyası Yapısı

Bir alarm kuralının temel anatomisini anlamak, her şeyin başlangıç noktasıdır. Aşağıda en temel alarm kural şablonunu görebilirsiniz:

# /etc/netdata/health.d/custom-alarms.conf

alarm: yuksek_cpu_kullanimi
    on: system.cpu
    lookup: average -3m unaligned of user,system,softirq,irq,iowait
    units: %
    every: 1m
    warn: $this > 75
    crit: $this > 90
    info: Son 3 dakikadaki ortalama CPU kullanimi yuksek
    delay: up 1m down 5m multiplier 1.5 max 1h
    to: sysadmin

Bu kural yapısındaki parametreleri açıklayalım:

• alarm: Alarm için benzersiz isim, boşluk olmadan yazılır
• on: Hangi Netdata metriğinin izleneceği
• lookup: Değeri nasıl hesaplayacağı (zaman penceresi, fonksiyon, hangi boyutlar)
• units: Birimi, genellikle görsel gösterim için
• every: Alarm kontrolünün ne sıklıkta yapılacağı
• warn: WARNING eşiği tetikleyecek koşul
• crit: CRITICAL eşiği tetikleyecek koşul
• info: Alarm hakkında açıklama metni
• delay: Alarm durumunun ne zaman değişeceğine dair gecikme ayarları
• to: Uyarının kime gönderileceği (role bazlı)

Disk Kullanımı Alarm Kurulumu

Disk doluluk alarmları, en kritik ve en sık karşılaşılan senaryo türüdür. Disk tamamen dolduğunda servisler çökebilir, log dosyaları yazmayı durdurabilir, veritabanları corrupt olabilir.

# /etc/netdata/health.d/disk-alarms.conf

alarm: disk_doluluk_uyarisi
    on: disk.space
    lookup: average -5m unaligned of used
    units: %
    every: 1m
    warn: $this > 80
    crit: $this > 90
    info: Disk doluluk orani kritik seviyeye ulasti. Gereksiz dosyalari temizleyin.
    delay: up 2m down 10m multiplier 1.5 max 2h
    to: sysadmin

alarm: disk_inodes_uyarisi
    on: disk.inodes
    lookup: average -5m unaligned of used
    units: %
    every: 1m
    warn: $this > 80
    crit: $this > 90
    info: Inode kullanimi yuksek, cok sayida kucuk dosya olusabilir
    delay: up 2m down 10m multiplier 1.5 max 2h
    to: sysadmin

Burada iki farklı alarm dikkat çekiyor. Disk doluluk alarmının yanı sıra inode alarmı da kritik önem taşır. Binlerce küçük dosya (özellikle log dosyaları veya temp dosyaları) disk alanı olmasa bile inode’ları tüketebilir ve sisteminiz yeni dosya oluşturamaz hale gelebilir.

Bellek Kullanımı İçin Gelişmiş Alarmlar

RAM alarmları biraz daha karmaşıktır çünkü Linux bellek yönetimi, swap, cache ve buffer kavramlarını içerir. Gerçek bellek baskısını ölçmek için sadece “used” değerine bakmak yanıltıcı olabilir.

# /etc/netdata/health.d/memory-alarms.conf

alarm: ram_kullanimi_yuksek
    on: system.ram
    lookup: average -1m unaligned of used
    units: %
    every: 30s
    warn: $this > 80
    crit: $this > 95
    info: Sistem RAM kullanimi kritik seviyede
    delay: up 2m down 5m multiplier 1.5 max 1h
    to: sysadmin

alarm: swap_kullanimi_basladi
    on: system.swap
    lookup: average -1m unaligned of used
    units: %
    every: 1m
    warn: $this > 20
    crit: $this > 60
    info: Swap kullanimi artmaya basladi, RAM yetersiz kalabilir
    delay: up 3m down 15m multiplier 1.5 max 2h
    to: sysadmin

alarm: oom_killer_aktif
    on: mem.oom_kill
    lookup: sum -10m unaligned
    units: kills
    every: 1m
    warn: $this > 0
    info: Son 10 dakikada OOM Killer devreye girdi, islem olduruldu
    delay: up 0 down 10m
    to: sysadmin

OOM Killer alarmı özellikle değerli. OOM (Out of Memory) Killer devreye girdiğinde Linux, bazı süreçleri zorla sonlandırır. Bu alarm tetiklendiğinde doğrudan müdahale gerektirir.

CPU Yük Alarmları ve Gerçek Dünya Senaryosu

Bir e-ticaret sitesi işlettiğinizi düşünün. Kampanya günlerinde CPU yükü normalin 3-4 katına çıkabilir. Bu tamamen normal bir durum. Ama gecenin yarısı kimse alışveriş yapmıyorken CPU %90’a çıkıyorsa, muhtemelen bir sorun var.

# /etc/netdata/health.d/cpu-alarms.conf

alarm: cpu_yuk_uyarisi
    on: system.load
    lookup: average -5m unaligned of load1
    units: load
    every: 1m
    warn: $this > (($system_cores) * 1.5)
    crit: $this > (($system_cores) * 3)
    info: Sistem yuk ortalamasi cekirdek sayisinin usterinde
    delay: up 3m down 10m multiplier 1.5 max 2h
    to: sysadmin

alarm: cpu_steal_yuksek
    on: system.cpu
    lookup: average -5m unaligned of steal
    units: %
    every: 1m
    warn: $this > 10
    crit: $this > 25
    info: CPU steal yuksek, sanal sunucu altyapisi overloaded olabilir
    delay: up 2m down 5m multiplier 1.5 max 1h
    to: sysadmin

CPU steal alarmı, sanal makinelerde (VPS, AWS EC2 vb.) çalışıyorsanız çok önemlidir. Yüksek steal değeri, fiziksel sunucunuzdaki diğer sanal makinelerin CPU kaynaklarını tükettiğini gösterir. Bu değer sürekli yüksekse hosting firmanızla veya bulut sağlayıcınızla konuşmanın zamanı gelmiştir.

Network Trafik Alarmları

Bir web sunucusu yönetiyorsanız, ağ trafiği alarmları DDoS saldırılarını veya anormal trafik paternlerini erken tespit etmenize yardımcı olur.

# /etc/netdata/health.d/network-alarms.conf

alarm: network_giris_trafigi_yuksek
    on: net.eth0
    lookup: average -5m unaligned of received
    units: kilobits/s
    every: 1m
    warn: $this > 50000
    crit: $this > 100000
    info: eth0 giris trafigi anormal sekilde yuksek
    delay: up 1m down 5m multiplier 1.5 max 1h
    to: sysadmin

alarm: network_paket_kaybi
    on: net_drops.eth0
    lookup: average -5m unaligned of ingress
    units: drops/s
    every: 1m
    warn: $this > 50
    crit: $this > 200
    info: Network paket kaybi tespit edildi, donanim veya agizleme sorunu olabilir
    delay: up 2m down 10m multiplier 1.5 max 2h
    to: sysadmin

Network arayüzünüzün adını (eth0, ens3, enp0s3) sisteminize göre düzenlemeyi unutmayın. ip addr komutuyla mevcut arayüzleri listeleyebilirsiniz.

Delay Parametresini Doğru Kullanmak

Alarm sistemlerindeki en büyük hatalardan biri “alarm yorgunluğu” dur. Eşik değeri her geçildiğinde bildirim gelirse, bir süre sonra alarmları görmezden gelmeye başlarsınız. delay parametresi bu sorunu çözer.

# Gecikme parametresi ornegi ve aciklamasi

alarm: gecikme_ornegi
    on: system.cpu
    lookup: average -1m unaligned of user,system
    units: %
    every: 30s
    warn: $this > 80
    crit: $this > 95
    delay: up 2m down 10m multiplier 1.5 max 1h
    to: sysadmin

delay parametresinin parçaları:

• up 2m: Eşik aşıldıktan 2 dakika sonra alarm tetiklenir. Geçici spike’lar için alarm gelmesini önler
• down 10m: Değer normale döndükten 10 dakika sonra CLEAR bildirimini gönderir. Titreşen değerlerde sürekli açık/kapı bildirimi önler
• multiplier 1.5: Her yeni alarm durumu değişikliğinde gecikmeyi 1.5 ile çarpar. Tekrarlayan durumlar için bekleme süresini artırır
• max 1h: Gecikmenin maksimum 1 saate kadar uzayabileceğini belirtir

Bu ayarlar gerçek dünyada çok fark yaratır. Örneğin bir web sunucusunda cron job çalıştığında CPU kısa süre yükselebilir. up 2m ayarıyla bu tür kısa spike’lar için gereksiz alarm almaktan kurtulursunuz.

Bildirim Sistemi Yapılandırması

Alarmları tanımladınız ama kimseye ulaşmıyorsa ne işe yarar? Netdata’nın bildirim sistemi /etc/netdata/health_alarm_notify.conf dosyasından yapılandırılır.

# /etc/netdata/health_alarm_notify.conf icin e-posta yapilandirmasi

# E-posta bildirimleri
SEND_EMAIL="YES"
DEFAULT_RECIPIENT_EMAIL="[email protected]"
EMAIL_SENDER="[email protected]"

# Role bazli bildirim
role_recipients_email[sysadmin]="[email protected] [email protected]"
role_recipients_email[webmaster]="[email protected]"
role_recipients_email[dba]="[email protected]"

# Sadece critical alarmlari baska bir adrese gonder
role_recipients_email[critical]="[email protected] [email protected]"

Slack entegrasyonu için yapılandırma çok daha hızlı bildirim sağlar:

# Slack bildirimi icin yapilandirma

SEND_SLACK="YES"
SLACK_WEBHOOK_URL="https://hooks.slack.com/services/TXXXXXXXX/BXXXXXXXX/XXXXXXXXXX"
DEFAULT_RECIPIENT_SLACK="#alerts"

# Role bazli Slack kanallari
role_recipients_slack[sysadmin]="#sysadmin-alerts"
role_recipients_slack[dba]="#dba-alerts"
role_recipients_slack[critical]="#critical-alerts @oncall-engineer"

Bildirimlerin çalışıp çalışmadığını test etmek için:

# Bildirim testi
sudo -u netdata /usr/libexec/netdata/plugins.d/alarm-notify.sh test sysadmin

# Belirli bir kanal testi
sudo -u netdata /usr/libexec/netdata/plugins.d/alarm-notify.sh test email

Mevcut Alarmları Özelleştirmek

Netdata’nın varsayılan alarmlarını tamamen devre dışı bırakmak yerine, sadece eşik değerlerini değiştirmek isteyebilirsiniz. Bunun için alarm_template_overrides veya doğrudan dosya kopyalama yöntemini kullanabilirsiniz.

# Ornegin varsayilan cpu alarm dosyasini kopyalayip ozellestirelim
sudo cp /usr/lib/netdata/conf.d/health.d/cpu.conf /etc/netdata/health.d/cpu.conf

# Dosyayi duzenle
sudo nano /etc/netdata/health.d/cpu.conf

Bir alarmı geçici olarak devre dışı bırakmak için:

# Belirli bir alarmi devre disi birak
# Alarm kural dosyasinda ilgili satirlari degistir:

alarm: cpu_yuk_uyarisi
    on: system.cpu
    lookup: average -3m unaligned of user,system
    units: %
    every: 1m
    warn: $this > 75
    crit: $this > 90
    # Gecici olarak devre disi birak:
    # enabled: no
    to: sysadmin

Daha pratik bir yöntem olarak Netdata API üzerinden alarm durumunu kontrol edebilirsiniz:

# Aktif alarmlari listele
curl -s "http://localhost:19999/api/v1/alarms?all" | python3 -m json.tool | grep '"name"'

# Belirli bir alarmin durumunu kontrol et
curl -s "http://localhost:19999/api/v1/alarm_log?last=25" | python3 -m json.tool

Uygulama Bazlı Alarm Senaryoları

Gerçek dünyada sadece sistem metriklerini izlemekle kalmazsınız. Nginx, MySQL, Redis gibi uygulamalar için de özel alarmlar tanımlamak gerekir.

# /etc/netdata/health.d/nginx-alarms.conf

alarm: nginx_aktif_baglanti_yuksek
    on: nginx.connections_state
    lookup: average -5m unaligned of active
    units: connections
    every: 1m
    warn: $this > 500
    crit: $this > 1000
    info: Nginx aktif baglanti sayisi yuksek, kapasite sinirlanabilir
    delay: up 2m down 5m multiplier 1.5 max 1h
    to: sysadmin

alarm: nginx_istek_hata_orani
    on: nginx.requests_total
    lookup: average -5m unaligned of requests
    units: requests/s
    every: 1m
    warn: $this > 1000
    crit: $this > 5000
    info: Nginx saniyedeki istek sayisi anormal, olaganusta trafik veya DDoS olamabilir
    delay: up 1m down 5m multiplier 1.5 max 1h
    to: sysadmin

MySQL için kritik bir alarm senaryosu:

# /etc/netdata/health.d/mysql-alarms.conf

alarm: mysql_yavaş_sorgular
    on: mysql.queries
    lookup: average -5m unaligned of slow_queries
    units: queries/s
    every: 1m
    warn: $this > 5
    crit: $this > 20
    info: MySQL yavas sorgu sayisi artiyor, sorgu optimizasyonu gerekebilir
    delay: up 3m down 10m multiplier 1.5 max 2h
    to: dba

alarm: mysql_baglanti_doluyor
    on: mysql.connections_active
    lookup: average -5m unaligned of active
    units: connections
    every: 1m
    warn: $this > 80
    crit: $this > 95
    info: MySQL maksimum baglanti sayisina yaklasiliyor
    delay: up 2m down 5m multiplier 1.5 max 1h
    to: dba

Değişiklikleri Uygulama ve Test Etme

Alarm dosyalarında değişiklik yaptıktan sonra yapılandırmanın geçerli olması için Netdata’yı yeniden başlatmanız gerekir.

# Netdata yapilandirmasini dogrula
sudo netdatacli reload-health

# Ya da servisi yeniden baslat
sudo systemctl reload netdata

# Alarm dosyasinda syntax hatasi var mi kontrol et
sudo netdata -t

# Aktif alarm sayisini goster
curl -s "http://localhost:19999/api/v1/alarms" | python3 -c "import sys,json; data=json.load(sys.stdin); print(f'Toplam alarm: {len(data["alarms"])}')"

Bir alarmı manuel olarak test etmek, yapılandırmanızın doğru çalışıp çalışmadığını doğrulamanın en iyi yoludur. Bunun için geçici olarak eşik değerini çok düşük bir değere çekip alarm tetiklenmesini bekleyebilirsiniz. Test sonrası orijinal değere döndürmeyi unutmayın.

Alarm Susturma (Silencing) Yönetimi

Bakım penceresi sırasında veya planlı bir yüksek yük durumunda alarmları geçici olarak susturmak isteyebilirsiniz.

# Netdata CLI ile alarm susturma (Netdata Cloud veya Agent API ile)

# Belirli bir alami 2 saat sustur
curl -s "http://localhost:19999/api/v1/manage/health?cmd=SILENCE_ALL&duration=7200" 
  -H "X-Auth-Token: BURAYA_AUTH_TOKEN_YAZIN"

# Sadece belirli host ve alarm icin
curl -s "http://localhost:19999/api/v1/manage/health?cmd=SILENCE&alarm=disk_doluluk_uyarisi&duration=3600" 
  -H "X-Auth-Token: BURAYA_AUTH_TOKEN_YAZIN"

# Auth token olusturma
grep "api authorization tokens" /etc/netdata/netdata.conf
# Yoksa netdata.conf icine ekle:
# [web]
#     allow management from = localhost

Bakım penceresi için daha pratik bir yaklaşım, cron job ile alarm geçici devre dışı bırakma scriptleri yazmaktır:

#!/bin/bash
# /usr/local/bin/maintenance-mode.sh

ACTION=${1:-start}
DURATION=${2:-3600}  # Saniye cinsinden, varsayilan 1 saat

if [ "$ACTION" == "start" ]; then
    echo "Bakim modu baslatiliyor, $DURATION saniye boyunca alarmlar susturulacak"
    curl -s -X POST "http://localhost:19999/api/v1/manage/health?cmd=SILENCE_ALL&duration=$DURATION" 
         -H "X-Auth-Token: $(cat /etc/netdata/auth_token)"
    echo "Bakim modu aktif"
elif [ "$ACTION" == "stop" ]; then
    echo "Bakim modu sonlandiriliyor, alarmlar tekrar aktif"
    curl -s -X POST "http://localhost:19999/api/v1/manage/health?cmd=RESET" 
         -H "X-Auth-Token: $(cat /etc/netdata/auth_token)"
    echo "Alarmlar tekrar aktif"
fi

Sık Yapılan Hatalar ve Çözümleri

Alarm yapılandırmasında karşılaşılan en yaygın sorunlara değinmek gerekiyor:

Çok düşük eşik değerleri: Eşiği çok hassas tutmak alarm yorgunluğuna yol açar. Önce birkaç gün sisteminizi izleyin, normal çalışma değerlerini öğrenin, sonra eşiği %20-30 üstüne ayarlayın.

Delay parametresini atlama: Özellikle CPU ve RAM için delay up parametresi olmadan her anlık spike bildirim gönderir. Minimum 2-3 dakika up değeri kullanın.

Inode takibini unutmak: Disk doluluk alarmı varken inode alarmını atlamak yaygın bir hatadır. Her ikisi de kritiktir.

Test etmeden production’a almak: Alarm kuralını yazdıktan sonra mutlaka notification testini yapın. Bildirim ulaşmıyorsa alarm kuralının bir önemi yoktur.

Çok fazla alarm kanalı: Hem e-posta hem Slack hem de SMS aynı anda geliyorsa, önem sırasına göre filter oluşturun. Kritik alarmlar SMS, warning’ler Slack, tüm loglar e-posta gibi bir hiyerarşi kurun.

Sonuç

Netdata alarm sistemi, doğru yapılandırıldığında gerçek anlamda proaktif bir izleme altyapısı oluşturmanızı sağlar. Disk dolmadan, bellek tükenmeden veya servisler çökmeden önce haberdar olmak, ciddi kesinti sürelerini minimize eder.

Başlangıç için öncelikle disk, CPU ve RAM alarmlarını kurun. Sonra uygulamaya özel alarmları ekleyin. Her alarmı kurarken kendinize şu soruyu sorun: “Bu alarm geldiğinde ne yapacağım?” Cevabı olmayan bir alarm, sadece gürültü yaratır.

Eşik değerlerini kopyala yapıştır olarak almayın. Her sistemin profili farklıdır. Önce birkaç hafta boyunca sisteminizi izleyin, warn eşiğini normalin yaklaşık %20 üstüne, crit eşiğini ise %40-50 üstüne koyun. Alarm yorgunluğundan kaçının: Az ama doğru alarm, çok ama gürültülü alarmdan çok daha değerlidir.

Son olarak, alarm sisteminizi canlı tutun. Üretim ortamı zamanla değişir, yeni servisler eklenir, yük profili değişir. Alarm eşik değerlerinizi ayda bir gözden geçirin ve sisteminizin gerçek davranışını yansıttığından emin olun.