E-posta ve Slack ile Netdata Bildirim Entegrasyonu

Bykomut

Sunucudan gelen bir alarm emailini sabah 3’te görmek ile o alarma anında müdahale edebilmek arasındaki fark, çoğu zaman iyi yapılandırılmış bir bildirim sistemidir. Netdata, kutudan çıktığı haliyle oldukça güçlü bir izleme aracı olsa da bildirim kanallarını doğru kurmazsanız kritik uyarılar sessizce geçip gidebilir. Bu yazıda Netdata’nın e-posta ve Slack entegrasyonlarını gerçek dünya senaryolarıyla adım adım ele alacağız.

Netdata Bildirim Sistemi Nasıl Çalışır?

Netdata’nın alarm motoru, /etc/netdata/health.d/ dizinindeki .conf dosyalarında tanımlı kurallara göre çalışır. Bir metrik eşik değerini aştığında veya belirli bir koşul gerçekleştiğinde Netdata, /etc/netdata/health_alarm_notify.conf dosyasında tanımlı bildirim kanallarını tetikler.

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

  • Netdata daemon metrik verilerini sürekli toplar
  • Health engine tanımlı kuralları her saniye değerlendirir
  • Bir alarm durumu WARNING veya CRITICAL seviyesine ulaştığında alarm-notify.sh scripti çalışır
  • Bu script, etkin bildirim kanallarına uyarıyı iletir
  • Alarm normale döndüğünde CLEAR bildirimi gönderilir

Şimdi bu yapıyı e-posta ve Slack için nasıl kuracağımıza bakalım.

E-posta Bildirimleri Kurulumu

Sistem Gereksinimlerini Kontrol Etme

E-posta bildirimleri için sunucuda bir MTA (Mail Transfer Agent) kurulu olması gerekir. En yaygın seçenekler sendmail, postfix veya msmtp‘dir. Önce mevcut durumu kontrol edelim:

which sendmail
which postfix
which msmtp

# Postfix servis durumunu kontrol et
systemctl status postfix

# Test maili gönder
echo "Test mesaji" | mail -s "Netdata Test" [email protected]

Eğer sunucunuzda tam bir mail sunucusu kurmak istemiyorsanız, harici SMTP relay kullanmak çok daha pratiktir. msmtp bu iş için mükemmeldir:

# Debian/Ubuntu
apt-get install msmtp msmtp-mta mailutils -y

# RHEL/CentOS/AlmaLinux
yum install msmtp mailutils -y

# msmtp konfigürasyonu
cat > /etc/msmtprc << 'EOF'
defaults
auth           on
tls            on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
logfile        /var/log/msmtp.log

account        default
host           smtp.gmail.com
port           587
from           [email protected]
user           [email protected]
password       UYGULAMA_SIFRENIZ_BURAYA
EOF

chmod 600 /etc/msmtprc

Gmail kullanıyorsanız normal şifre yerine Uygulama Şifresi (App Password) oluşturmanız gerekir. Google hesabınızda 2FA aktif olmalı ve “App Passwords” bölümünden özel bir şifre almanız lazım.

health_alarm_notify.conf Dosyasını Yapılandırma

Ana konfigürasyon dosyasına gelelim. Önce orijinali yedekleyelim:

cp /etc/netdata/health_alarm_notify.conf /etc/netdata/health_alarm_notify.conf.bak

# Dosyayı düzenle
nano /etc/netdata/health_alarm_notify.conf

E-posta bildirimleri için şu kısımları bulup düzenlemeniz gerekiyor:

# E-posta bildirimlerini etkinleştir
SEND_EMAIL="YES"

# Varsayilan alici (boş bırakılırsa sistem admini)
DEFAULT_RECIPIENT_EMAIL="[email protected]"

# Birden fazla alici icin bosluk ile ayir
# DEFAULT_RECIPIENT_EMAIL="[email protected] [email protected]"

# Sadece CRITICAL alarmlari belirli bir adrese gonder
# role_recipients_email[sysadmin]="[email protected]"

# Hem WARNING hem CRITICAL icin
# role_recipients_email[webmaster]="[email protected]"

Konfigürasyondaki önemli parametreler:

  • SEND_EMAIL: E-posta bildirimlerini açar/kapatır, YES veya NO değeri alır
  • DEFAULT_RECIPIENT_EMAIL: Hiçbir role tanımlı alıcı yoksa kullanılacak adres
  • EMAIL_SENDER: Gönderici adresi, boş bırakılırsa sistem hostname’i kullanılır
  • role_recipients_email[]: Role bazlı alıcı tanımlaması, farklı alarm tiplerini farklı ekiplere yönlendirmek için kullanılır

E-posta Bildirimini Test Etme

# Netdata'nin dahili test aracini kullan
/usr/libexec/netdata/plugins.d/alarm-notify.sh test email

# Veya netdatacli ile test et
netdatacli reload-health

# Alarm tetiklemek icin dummy bir test
su -s /bin/bash netdata -c "/usr/libexec/netdata/plugins.d/alarm-notify.sh test"

Test sonrasında /var/log/netdata/error.log dosyasını kontrol etmeyi unutmayın:

tail -f /var/log/netdata/error.log | grep -i "email|notify|alarm"

Slack Bildirimleri Kurulumu

Slack Incoming Webhook Oluşturma

Slack entegrasyonu için önce bir Incoming Webhook URL’i oluşturmanız gerekiyor:

  • Slack workspace’inizde sol menüden Apps bölümüne gidin
  • “Incoming WebHooks” uygulamasını arayın ve ekleyin
  • Hangi kanala mesaj gönderileceğini seçin (#ops-alerts, #monitoring gibi)
  • Webhook URL’ini kopyalayın, şuna benzer görünür: https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX

Bu URL’i güvenli bir yerde saklayın, bir daha göremezsiniz. Kaybederseniz yenisini oluşturmanız gerekir.

Slack Webhook Konfigürasyonu

nano /etc/netdata/health_alarm_notify.conf

Slack ile ilgili bölümü bulup düzenleyin:

# Slack bildirimlerini etkinlestir
SEND_SLACK="YES"

# Webhook URL
SLACK_WEBHOOK_URL="https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX"

# Varsayilan kanal (# olmadan yazin)
DEFAULT_RECIPIENT_SLACK="#ops-alerts"

# Farkli roller icin farkli kanallar
# role_recipients_slack[sysadmin]="#sysadmin-alerts"
# role_recipients_slack[dba]="#database-alerts"
# role_recipients_slack[webmaster]="#web-alerts"

Slack bildirimlerindeki önemli parametreler:

  • SEND_SLACK: Slack bildirimlerini açar/kapatır
  • SLACK_WEBHOOK_URL: Slack’ten aldığınız webhook adresi, hassas bilgi olduğu için dikkatli saklayın
  • DEFAULT_RECIPIENT_SLACK: Varsayılan hedef kanal, # ile başlamalı değil, sadece kanal adı
  • role_recipients_slack[]: Her Netdata rolü için ayrı kanal tanımlamanıza izin verir

Slack Bildirimini Test Etme

# Slack test bildirimi gonder
/usr/libexec/netdata/plugins.d/alarm-notify.sh test slack

# Ciktiyi izle
tail -50 /var/log/netdata/error.log

Eğer test başarısız olursa şu adımları kontrol edin:

# curl ile webhook'u manuel test et
curl -X POST -H 'Content-type: application/json' 
  --data '{"text":"Netdata test mesaji - webhook calisiyor!"}' 
  https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX

# Sunucunun Slack'e erisimi var mi?
curl -I https://hooks.slack.com

Gerçek Dünya Senaryoları

Senaryo 1: E-ticaret Sitesi için Katmanlı Bildirim

Diyelim ki bir e-ticaret platformu yönetiyorsunuz. Gece yarısı CPU spike’ları oluyor ama bunların bir kısmı normal trafik kaynaklı, bir kısmı ise gerçek sorun. Katmanlı bir bildirim yapısı kurabilirsiniz:

# /etc/netdata/health_alarm_notify.conf icinde
# WARNING'ler sadece Slack'e gitsin
# CRITICAL'lar hem Slack hem email gitsin

# Bu yapilandirma icin custom bir script kullaniriz
# Oncelikle role'leri ayarlayalim
role_recipients_email[sysadmin]="[email protected]"
role_recipients_slack[sysadmin]="#alerts-critical"

# webmaster rolu icin ayri kanallar
role_recipients_email[webmaster]="[email protected]"
role_recipients_slack[webmaster]="#alerts-web"

Şimdi bu role’lere özel alarm kuralları yazalım:

# /etc/netdata/health.d/eticaret_custom.conf

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

alarm: web_response_time
    on: web_log_nginx.response_time
lookup: average -3m unaligned
 units: ms
 every: 30s
  warn: $this > 500
  crit: $this > 2000
  info: Nginx yanit suresi kritik seviyede
    to: webmaster

Senaryo 2: Veritabanı Sunucusu için Özel Alarmlar

MySQL veya PostgreSQL sunucusu yönetiyorsanız disk dolmadan önce uyarı almak kritik önem taşır:

# /etc/netdata/health.d/disk_custom.conf

alarm: disk_doluluk_uyari
    on: disk.space
lookup: average -1m unaligned of used
 units: %
 every: 1m
  warn: $this > 75
  crit: $this > 90
 delay: up 1m down 5m
  info: /var/lib/mysql disk kullanimi kritik
    to: dba

# Inode uyarisi - cok atlanan ama onemli!
alarm: inode_uyari
    on: disk.inodes
lookup: average -1m unaligned of used
 units: %
 every: 5m
  warn: $this > 80
  crit: $this > 95
  info: Inode kullanimi kritik, kucuk dosya sorunu olabilir
    to: sysadmin

Ardından DBA rolü için bildirim kanallarını ayarlayın:

# health_alarm_notify.conf'a ekle
role_recipients_email[dba]="[email protected] [email protected]"
role_recipients_slack[dba]="#db-alerts"

Senaryo 3: Bildirim Filtreleme ile Gürültüyü Azaltma

Çok sayıda sunucu yönetiyorsanız alarm yorgunluğu gerçek bir problem haline gelir. Netdata’da SEND_MOBILE, SEND_EMAIL gibi flag’leri alarm başına kontrol etmek yerine, sadece belirli saatlerde bazı bildirimleri susturmak isteyebilirsiniz. Bunun için bir wrapper script yazabiliriz:

#!/bin/bash
# /usr/local/bin/netdata-notify-filter.sh
# Bu script alarm-notify.sh onunde bir filtre gorevi gorur

HOUR=$(date +%H)
ALARM_STATUS=$2  # WARNING veya CRITICAL

# Gece 23:00 - 07:00 arasi sadece CRITICAL gonder
if [ "$HOUR" -ge 23 ] || [ "$HOUR" -le 7 ]; then
    if [ "$ALARM_STATUS" = "WARNING" ]; then
        echo "Mesai disi saatte WARNING bildirimi susturuldu" >> /var/log/netdata/filter.log
        exit 0
    fi
fi

# Normal calistir
exec /usr/libexec/netdata/plugins.d/alarm-notify.sh "$@"
chmod +x /usr/local/bin/netdata-notify-filter.sh

Bu yaklaşım yerine Netdata’nın yerleşik SEND_NOTIFICATION_FILTERING özelliğini de kullanabilirsiniz, ama custom script daha fazla esneklik sağlar.

Bildirim İçeriğini Özelleştirme

Netdata’nın varsayılan bildirim şablonları /usr/lib/netdata/conf.d/health_alarm_notify.conf dosyasında tanımlıdır. Kendi şablonlarınızı oluşturmak için override dosyası kullanın:

# E-posta konusu sablonu
EMAIL_SUBJECT="${status} - ${host}: ${chart} - ${family}: ${alarm}"

# Slack mesaj icerigi icin custom format
# Bu degiskenleri kullanabilirsiniz:
# $host, $status, $alarm, $chart, $family, $value, $units
# $when, $duration, $roles, $info, $goto_url

Slack mesajlarını daha bilgilendirici hale getirmek için:

# health_alarm_notify.conf icinde Slack mesaj formatini duzenle
# Asagidaki degiskkenler kullanilabilir

SLACK_WEBHOOK_URL="https://hooks.slack.com/services/..."
DEFAULT_RECIPIENT_SLACK="#monitoring"

# Bildirim seviyesine gore emoji eklemek icin
# Bu gelismis bir konfigurasyondur, custom script gerektirir

Özelleştirilmiş bir Slack mesajı göndermek için:

#!/bin/bash
# /usr/local/bin/slack-netdata-alert.sh

WEBHOOK_URL="$SLACK_WEBHOOK_URL"
STATUS="$1"
HOST="$2"
ALARM="$3"
VALUE="$4"

case "$STATUS" in
    "CRITICAL") EMOJI=":red_circle:" COLOR="danger" ;;
    "WARNING")  EMOJI=":warning:" COLOR="warning" ;;
    "CLEAR")    EMOJI=":white_check_mark:" COLOR="good" ;;
    *)          EMOJI=":information_source:" COLOR="#439FE0" ;;
esac

PAYLOAD=$(cat <<EOF
{
    "attachments": [
        {
            "color": "$COLOR",
            "title": "$EMOJI Netdata Alarm: $ALARM",
            "text": "Sunucu: *$HOST*nDurum: $STATUSnDeger: $VALUEnZaman: $(date '+%d.%m.%Y %H:%M:%S')",
            "footer": "Netdata Monitoring",
            "ts": $(date +%s)
        }
    ]
}
EOF
)

curl -s -X POST -H 'Content-type: application/json' 
     --data "$PAYLOAD" "$WEBHOOK_URL"

Yaygın Sorunlar ve Çözümleri

Kurulum sırasında karşılaşılan en sık problemlere ve çözümlerine bakalım:

E-posta gönderilmiyor ama hata da yok:

# netdata kullanicisi olarak test et
sudo -u netdata /usr/libexec/netdata/plugins.d/alarm-notify.sh test email

# sendmail path'ini kontrol et
which sendmail
ls -la /usr/sbin/sendmail

# /etc/netdata/health_alarm_notify.conf'da sendmail path'i varsa kontrol et
grep -i sendmail /etc/netdata/health_alarm_notify.conf

Slack webhook 400 Bad Request hatası:

# Webhook URL'ini kontrol et, eski webhook'lar expire olabilir
# Slack'te webhook'u yeniden olustur ve URL'i guncelle

# Test curl ile
curl -v -X POST -H 'Content-type: application/json' 
  --data '{"text":"test"}' 
  "WEBHOOK_URL_BURAYA"

Çok fazla bildirim geliyor (alarm flooding):

# health_alarm_notify.conf'da rate limiting ayarla
# Ayni alarm icin minimum bekleme suresi
MINIMUM_SEND_INTERVAL=300  # 5 dakika

# Alarm tekrari limiti
# delay parametresini alarm taniminda kullan
# delay: up 5m down 15m multiplier 2 max 2h

Netdata servisi yeniden başlatma:

# Degisiklikleri uygulamak icin
systemctl restart netdata

# Sadece health engine'i yeniden yukle (daha az invasive)
netdatacli reload-health

# Servis durumunu kontrol et
systemctl status netdata
journalctl -u netdata -f

Birden Fazla Sunucuyu Merkezi Yönetme

Eğer birden fazla sunucu izliyorsanız, Netdata Cloud veya parent-child mimarisi kullanmak mantıklıdır. Tüm bildirimler merkezi bir parent node üzerinden yönetilebilir:

# Parent node'da (bildirimler buradan gonder)
# /etc/netdata/netdata.conf
[health]
    # Child node'lardan gelen alarmlari da isle
    enabled = yes

# /etc/netdata/stream.conf
[API_KEY_BURAYA]
    enabled = yes
    default history = 3600
    default memory mode = ram
    health enabled by default = auto
    allow from = *

Child node’larda bildirimleri devre dışı bırakıp sadece parent’a stream edebilirsiniz:

# Child node health_alarm_notify.conf
SEND_EMAIL="NO"
SEND_SLACK="NO"
# Child sadece parent'a veri gonderir, bildirim gondermez

Monitoring Stack ile Entegrasyon

Netdata bildirimlerini PagerDuty, OpsGenie veya benzeri sistemlerle entegre etmek de mümkündür. health_alarm_notify.conf içinde bu servislerin webhook desteği bulunur:

# PagerDuty entegrasyonu
SEND_PAGERDUTY="YES"
PAGERDUTY_SERVICE_KEY="ANAHTARINIZ_BURAYA"

# OpsGenie entegrasyonu
SEND_OPSGENIE="YES"
OPSGENIE_API_KEY="ANAHTARINIZ_BURAYA"

Ancak bu entegrasyonları kullanmadan önce Netdata versiyonunuzu kontrol edin:

netdata -v
# veya
apt-cache policy netdata

Eski sürümlerde bazı entegrasyon seçenekleri bulunmayabilir. En güncel bildirim desteği için Netdata’yı güncel tutmak her zaman iyi bir pratiktir.

Sonuç

Netdata’nın bildirim sistemi oldukça esnek yapıda tasarlanmış. E-posta için ihtiyacınız olan temel şey çalışan bir MTA ve doğru konfigürasyon. Slack içinse bir webhook URL’i yeterli. Ama asıl değer, bu iki kanalı birlikte ve akıllıca kullanmakta yatıyor.

Şöyle bir çerçeve oluşturursanız uzun vadede çok fayda görürsünüz: WARNING seviyesindeki alarmlar Slack’e gitsin, ekip mesai saatlerinde görsün ve gerekirse aksiyon alsın. CRITICAL alarmlar hem Slack’e hem e-postaya gitsin, nöbetçi kişi her iki kanaldan da haberdar olsun. Gece yarısı için SMS veya PagerDuty entegrasyonu eklerseniz tam bir bildirim hiyerarşisi elde edersiniz.

Alarm yorgunluğuna karşı dikkatli olun. Çok fazla bildirim gelirse ekip bunları görmezden gelmeye başlar, bu da asıl kritik uyarıların gözden kaçmasına yol açar. Eşik değerlerini gerçekçi tutun, delay parametrelerini iyi ayarlayın ve düzenli aralıklarla alarm kurallarınızı gözden geçirin. Bir sunucunun normal çalışma profili zamanla değişir, alarmlarınızın da buna ayak uydurması gerekir.

Son olarak şunu söyleyeyim: Bu konfigürasyonları hazırladıktan sonra test etmeden canlıya almayın. alarm-notify.sh test komutunu her kanal için çalıştırın, gerçek bir alarm simüle edin ve tüm alıcıların bildirimi aldığından emin olun. Kriz anında “neden bildirim gelmedi” sorusunu sormak yerine önceden test etmek çok daha az streslidir.

Benzer Konular

Bir yanıt yazın

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