Bir sunucu on saniye boyunca tıkanıp sonra kendine geliyorsa, otuz saniyede bir örnek alan bir izleme sistemi bunu çoğu zaman hiç görmez. Grafikte küçük bir tümsek belki fark edilir, belki edilmez; ama o on saniyede hangi sürecin diski kilitlediğini asla öğrenemezsin. Netdata kurulumu tam olarak bu boşluk için vardır: varsayılan olarak saniyede bir örnek alır, kurulur kurulmaz yüzlerce metriği kendiliğinden bulur ve tarayıcıda anında çizmeye başlar.
Netdata'yı Prometheus ya da Zabbix gibi araçların rakibi olarak düşünmek yanlış olur; farklı bir soruya cevap verir. Prometheus "son üç ayda bu metrik nasıl seyretti" sorusunda güçlüdür, Netdata ise "şu anda bu makinede tam olarak ne oluyor" sorusunda. Bu rehberde Netdata'yı kurmayı, saklama ve bellek modunu ihtiyacına göre ayarlamayı, uygulama collector'larını devreye almayı, uyarıları ve bildirim kanallarını yapılandırmayı, Prometheus ile birlikte nasıl kullanılacağını ve en kritik konu olan port güvenliğini anlatacağım.
Netdata'yı Farklı Kılan Ne#
Üç tasarım tercihi Netdata'yı diğerlerinden ayırır. Birincisi çözünürlük: varsayılan toplama aralığı bir saniyedir ve arayüz canlı akar. Kısa süreli tıkanmaları, tek seferlik disk kilitlenmelerini, bir yedek betiğinin yarattığı ani G/Ç dalgasını gerçekten görebilirsin. İkincisi sıfır yapılandırma: kurduğun anda CPU, bellek, disk, ağ, sistemd birimleri, çalışan servisler ve tespit edebildiği tüm uygulamalar için grafikler hazır gelir; hiçbir dosya düzenlemeden işe yarar bir sonuç alırsın. Üçüncüsü yerel çalışma: veriyi merkezî bir sunucuya göndermek zorunda değildir, her makine kendi verisini kendi tutar ve kendi arayüzünü sunar.
Bu tercihlerin bedeli de var. Saniyelik çözünürlük bellek ister; uzun geçmiş tutmak istersen disk ister. Merkezî sorgulama Prometheus'taki kadar esnek değildir, PromQL benzeri güçlü bir sorgu dili yoktur. Yani Netdata teşhis aracı olarak parlar, uzun vadeli kapasite planlaması aracı olarak değil.
| İhtiyaç | Netdata | Prometheus + Grafana |
|---|---|---|
| Kurulum süresi | Dakikalar, yapılandırmasız | Saatler, elle kurulum |
| Çözünürlük | 1 saniye | 15-60 saniye (tipik) |
| Uzun vadeli saklama | Sınırlı, disk yoğun | Aylarca, verimli |
| Sorgu esnekliği | Sınırlı | PromQL ile çok yüksek |
| Anlık teşhis | Çok güçlü | Orta |
| Çok sunuculu birleşik görünüm | Ek yapılandırma ister | Doğal |
Pratikte gördüğüm en verimli kurulum ikisini birlikte kullanmaktır: uzun vadeli metrikler ve uyarılar için Prometheus, "şu an ne oluyor" anı için Netdata. Prometheus tarafını hiç kurmadıysan Prometheus kurulumu yazısı bu ikilinin diğer yarısını anlatıyor.
Kurulum: Tek Satırlık Betik ve Docker#
Netdata'nın resmi kurulum betiği dağıtımı algılar, bağımlılıkları kurar ve servisi başlatır. İnternetten indirilen bir betiği doğrudan kabuğa borulamak yerine önce indirip okumanı öneririm:
# Betiği indir ve incele
curl -fsSL https://get.netdata.cloud/kickstart.sh -o /tmp/netdata-kickstart.sh
less /tmp/netdata-kickstart.sh
# Telemetriyi kapatarak ve buluta bağlanmadan kur
sudo sh /tmp/netdata-kickstart.sh --disable-telemetry --no-updates
# Servis durumu
sudo systemctl status netdata --no-pager
Kurulum bittiğinde arayüz http://SUNUCU_IP:19999 adresinde çalışıyor olur — ama bu adresi tarayıcıda açmadan önce güvenlik bölümünü okumanı özellikle rica ediyorum, çünkü varsayılan kurulum bu portu tüm arayüzlerde açar.
Docker tarafında ise host metriklerini doğru okuyabilmesi için birkaç bağlamaya ihtiyaç duyar:
# docker-compose.yml
services:
netdata:
image: netdata/netdata:latest
container_name: netdata
restart: unless-stopped
pid: host
network_mode: host
cap_add:
- SYS_PTRACE
- SYS_ADMIN
security_opt:
- apparmor:unconfined
volumes:
- netdata-config:/etc/netdata
- netdata-lib:/var/lib/netdata
- netdata-cache:/var/cache/netdata
- /etc/passwd:/host/etc/passwd:ro
- /etc/group:/host/etc/group:ro
- /proc:/host/proc:ro
- /sys:/host/sys:ro
- /etc/os-release:/host/etc/os-release:ro
- /var/run/docker.sock:/var/run/docker.sock:ro
volumes:
netdata-config:
netdata-lib:
netdata-cache:
pid: host ve SYS_PTRACE olmadan süreç bazlı metrikler eksik kalır; docker.sock bağlaması ise konteyner adlarının grafiklere yansımasını sağlar. Üç ayrı kalıcı birim de gereklidir: yapılandırma, veritabanı ve önbellek farklı dizinlerde durur ve birini atlarsan ya ayarların ya geçmişin kaybolur.
Yapılandırma, Saklama ve Bellek Modu#
Netdata'nın ana yapılandırma dosyası /etc/netdata/netdata.conf dosyasıdır ama doğrudan düzenlemek yerine edit-config betiğini kullanmalısın; betik varsayılan şablonu doğru yere kopyalar:
cd /etc/netdata
sudo ./edit-config netdata.conf
Ayarlanmaya değer üç blok var:
[global]
# Toplama aralığı; 1 saniye varsayılan, kaynak darsa 2-5 yapılabilir
update every = 1
# Kaç saniyelik geçmiş bellekte tutulsun (dbengine modunda katman boyutu)
memory mode = dbengine
[db]
# Katmanlı saklama: yüksek çözünürlük kısa, düşük çözünürlük uzun süre
storage tiers = 3
dbengine multihost disk space MB = 2048
[web]
# Yalnızca yerel arayüze bağlan
bind to = 127.0.0.1
memory mode seçimi en önemli karardır ve seçenekler net biçimde ayrışır:
| Mod | Nerede saklar | Ne zaman kullanılır |
|---|---|---|
dbengine | Disk, katmanlı ve sıkıştırılmış | Varsayılan ve önerilen; günler-haftalar geçmiş |
ram | Yalnızca bellek | Diski yormak istemediğin geçici kurulumlar |
alloc | Bellek, dinamik ayırma | Konteyner içi kısa ömürlü kullanım |
none | Hiç saklamaz | Yalnızca dışarı aktarım yapılan kurulumlar |
dbengine katmanlı çalışır: birinci katman saniyelik veriyi kısa süre, ikinci ve üçüncü katmanlar giderek düşen çözünürlükle daha uzun süre tutar. dbengine multihost disk space MB değeri toplam disk bütçendir; 2 GB tipik bir sunucuda haftalarca geçmiş demektir. Diskin darsa bu sayıyı düşür, ama ram moduna geçmeden önce iki kez düşün — yeniden başlatmada tüm geçmişin silinir ve olay sonrası inceleme yapamazsın.
Collector'lar ile Uygulama İzleme#
Netdata yalnızca sistem metriklerini değil, tespit edebildiği uygulamaları da izler. Nginx, Apache, MySQL, PostgreSQL, Redis, Docker ve onlarca başka servis için hazır collector'lar gelir; çoğu ilgili servis çalışıyorsa kendiliğinden devreye girer. Çalışmayanları elle yapılandırırsın.
Nginx için önce durum uç noktasını açman gerekir:
# /etc/nginx/conf.d/status.conf
server {
listen 127.0.0.1:8080;
server_name localhost;
location /stub_status {
stub_status;
allow 127.0.0.1;
deny all;
}
}
Ardından Netdata tarafında collector'ı işaret edersin:
cd /etc/netdata
sudo ./edit-config go.d/nginx.conf
jobs:
- name: yerel_nginx
url: http://127.0.0.1:8080/stub_status
MySQL için de benzer bir mantık işler; salt okunur bir izleme kullanıcısı oluşturup collector'a tanıtırsın:
-- İzleme için asgari yetkili kullanıcı
CREATE USER 'netdata'@'localhost' IDENTIFIED BY 'guclu-bir-parola';
GRANT USAGE, REPLICATION CLIENT, PROCESS ON *.* TO 'netdata'@'localhost';
FLUSH PRIVILEGES;
Hangi collector'ların aktif olduğunu görmek için arayüzdeki sol menüye bakabilir ya da log dosyasını kontrol edebilirsin:
# Hangi collector'lar çalışıyor, hangileri başarısız
sudo grep -iE 'collector|failed' /var/log/netdata/error.log | tail -20
Bir collector "failed" görünüyorsa neredeyse her zaman erişim sorunudur: durum uç noktası kapalıdır, parola yanlıştır ya da Netdata kullanıcısının sokete erişim izni yoktur.
Uyarılar ve Bildirim Kanalları#
Netdata yüzlerce hazır alarmla gelir ve kurulduğu andan itibaren eşik aşımlarını arayüzde kırmızıya boyar. Ama bildirim göndermesi için kanal yapılandırman gerekir:
cd /etc/netdata
sudo ./edit-config health_alarm_notify.conf
# E-posta bildirimi
SEND_EMAIL="YES"
DEFAULT_RECIPIENT_EMAIL="[email protected]"
# Slack webhook
SEND_SLACK="YES"
SLACK_WEBHOOK_URL="https://hooks.slack.com/services/XXX/YYY/ZZZ"
DEFAULT_RECIPIENT_SLACK="#alarm"
# Telegram
SEND_TELEGRAM="YES"
TELEGRAM_BOT_TOKEN="BOT_TOKENI"
DEFAULT_RECIPIENT_TELEGRAM="CHAT_ID"
Kendi alarmını eklemek de basittir. Aşağıdaki örnek, kök diskin dolmasına az kaldığında uyarır:
# /etc/netdata/health.d/disk-ozel.conf
alarm: kok_disk_doluluk
on: disk_space./
lookup: average -1m percentage of used
units: %
every: 1m
warn: $this > 80
crit: $this > 92
delay: down 15m multiplier 1.5 max 1h
info: Kok disk doluluk orani yuksek
to: sysadmin
delay: down 15m satırı gürültüyü kesen kısımdır: alarm normale döndüğünde "çözüldü" bildirimi on beş dakika geciktirilir, böylece eşiğin etrafında salınan bir değer sana onlarca bildirim göndermez. Bildirimlerin gerçekten gittiğini test etmeyi unutma:
# Bildirim kanallarını test et
sudo -u netdata /usr/libexec/netdata/plugins.d/alarm-notify.sh test
E-posta bildirimleri gitmiyorsa sorun genellikle SMTP tarafındadır; port ve TLS modu uyumunu SMTP test aracı ile hızlıca doğrulayabilirsin.
Prometheus ile Birlikte Kullanmak#
Netdata'nın uzun vadeli saklama zayıflığını, verisini Prometheus'a aktararak çözebilirsin. Netdata zaten Prometheus biçiminde bir uç nokta sunar:
# Prometheus uyumlu çıktı
curl -s 'http://127.0.0.1:19999/api/v1/allmetrics?format=prometheus&help=no' | head -20
Prometheus tarafında sıradan bir job olarak eklersin:
scrape_configs:
- job_name: 'netdata'
scrape_interval: 30s
metrics_path: '/api/v1/allmetrics'
params:
format: ['prometheus']
help: ['no']
static_configs:
- targets: ['10.0.0.11:19999']
Bu kurulumda Netdata saniyelik anlık teşhisi, Prometheus ise aylık eğilimi verir. Yalnızca uzun vadeli metrik istiyorsan ve saniyelik çözünürlüğe ihtiyacın yoksa, daha hafif bir seçenek olarak Node Exporter tercih etmen daha yerinde olur; Netdata'nın avantajı zaten anlık ayrıntıdır. Toplanan veriyi panolarda birleştirmek istersen Grafana dashboard oluşturma yazısındaki değişken yaklaşımı burada da işini görür.
Güvenlik: 19999 Portu Herkese Açık Olmamalı#
Bu bölüm rehberin en önemli kısmı. Netdata varsayılan kurulumda kimlik doğrulaması olmadan çalışır ve arayüzü tüm ağ arayüzlerinde açar. Açık bırakılmış bir Netdata arayüzü; çekirdek sürümünü, çalışan tüm süreçleri, sistemd birimlerini, dinlenen portları, disk düzenini, veritabanı sorgu istatistiklerini ve kurulu uygulamaları herkese gösterir. Bu, saldırgan için hazırlanmış bir keşif raporudur.
Doğru yapılandırma, arayüzü yalnızca yerelde dinletip erişimi kimlik doğrulamalı bir ters vekil üzerinden vermektir:
# /etc/netdata/netdata.conf
[web]
bind to = 127.0.0.1
# Arayüzü tamamen kapatmak istersen: mode = none
# /etc/nginx/conf.d/netdata.conf
server {
listen 443 ssl;
server_name izleme.firmaniz.com;
ssl_certificate /etc/letsencrypt/live/izleme.firmaniz.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/izleme.firmaniz.com/privkey.pem;
location / {
auth_basic "Izleme";
auth_basic_user_file /etc/nginx/.htpasswd;
proxy_pass http://127.0.0.1:19999;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_http_version 1.1;
# Canlı grafikler için akış tamponlamasını kapat
proxy_buffering off;
}
}
Firewall katmanını da ihmal etme; ters vekil kursan bile portun doğrudan erişilebilir kalmadığından emin ol:
sudo ufw deny 19999/tcp
sudo ss -tlnp | grep 19999 # yalnızca 127.0.0.1 görünmeli
Temel kimlik doğrulama parolasını elle uydurma; şifre üretici aracımızla güçlü bir değer üretip htpasswd ile ekle.
Sık Yapılan Hatalar ve Tuzaklar#
19999 portunu açık bırakmak. En yaygın ve en pahalı hata. Kurulum betiği portu tüm arayüzlerde açar ve kimse fark etmez. Kurulumdan hemen sonra bind to = 127.0.0.1 ayarını yap.
ram moduyla üretimde çalıştırmak. Sunucu yeniden başladığında tüm geçmiş silinir. Bir olayın ardından "ne olmuştu" diye baktığında elinde hiçbir şey kalmaz; dbengine kullan.
Saniyelik çözünürlüğü küçük sunucuda zorlamak. 1 GB bellekli bir makinede varsayılan ayarlarla Netdata belirgin bir yük yaratır. Kaynak darsa update every = 2 ya da 5 yapmak, faydanın büyük kısmını korurken maliyeti ciddi biçimde düşürür.
Netdata'yı tek izleme aracı sanmak. Uzun vadeli kapasite planlaması, çok sunuculu birleşik uyarı yönetimi ve karmaşık sorgular Netdata'nın güçlü olduğu alanlar değildir. Merkezî bir izleme ihtiyacın varsa Prometheus ya da Zabbix kurulumu yazısındaki yaklaşımı değerlendir.
Hazır alarmların hepsini açık bırakmak. Netdata cömert bir alarm setiyle gelir ve bir kısmı senin ortamın için anlamsızdır. Kullanmadığın alarmları health.d altında kapat, yoksa gerçek uyarılar gürültünün içinde kaybolur.
Otomatik güncellemeyi düşünmeden açmak. Kurulum betiği varsayılan olarak otomatik güncelleme kurar. Üretim sunucusunda beklenmedik bir sürüm geçişi istemiyorsan --no-updates parametresiyle kur ve güncellemeleri kendin planla.
Sıkça Sorulan Sorular#
Netdata sunucuya ne kadar yük bindirir#
Varsayılan saniyelik toplamayla tipik bir sunucuda tek bir çekirdeğin küçük bir yüzdesini ve birkaç yüz megabayt belleği kullanır. Yük büyük ölçüde aktif collector sayısına ve dbengine disk bütçesine bağlıdır. Kaynağı dar bir makinede update every değerini 2-5 saniyeye çıkarmak tüketimi belirgin biçimde düşürür ve pratikte kaybettiğin şey çok kısa süreli tepe noktalarıdır.
Netdata ücretsiz mi, bulut hesabı zorunlu mu#
Netdata Agent açık kaynaklıdır ve GPLv3 lisansıyla ücretsiz dağıtılır; tüm izleme, alarm ve arayüz özellikleri yerel kurulumda çalışır. Netdata Cloud hizmeti birden fazla sunucuyu tek panelde birleştirmek için sunulan ayrı bir üründür ve zorunlu değildir. Kurulum betiğine --disable-telemetry verip buluta bağlamadan tamamen yerel kullanabilirsin.
Netdata mı Prometheus mu kullanmalıyım#
İkisi farklı soruları cevaplar, bu yüzden birçok ekip ikisini birlikte kullanır. Netdata "şu anda bu makinede ne oluyor" sorusunda saniyelik ayrıntısıyla rakipsizdir ve dakikalar içinde kurulur. Prometheus ise uzun vadeli saklama, esnek sorgulama ve çok sunuculu merkezî uyarı yönetiminde öne çıkar. Tek bir sunucun varsa Netdata tek başına yeter; filo büyüdükçe merkezî bir katmana ihtiyaç duyarsın.
Netdata verileri ne kadar süre saklar#
dbengine modunda saklama süresi ayırdığın disk alanına ve katman yapılandırmasına bağlıdır. dbengine multihost disk space MB değerini 2048 verirsen tipik bir sunucuda saniyelik veri birkaç gün, düşük çözünürlüklü katmanlar ise haftalarca geriye gider. Daha uzun geçmiş istiyorsan ya disk bütçesini artır ya da veriyi Prometheus gibi bir uzun vadeli depoya aktar.
Birden fazla sunucuyu tek ekranda nasıl görürüm#
Üç yol var. Netdata'nın "parent-child" akış yapılandırmasıyla çocuk düğümler verilerini merkezî bir ebeveyn düğüme aktarır ve tek arayüzden hepsini görürsün. İkinci yol Netdata Cloud hesabıdır, ancak bu verinin dışarı çıkması anlamına gelir. Üçüncü ve en esnek yol, her düğümün Prometheus uç noktasını merkezî bir Prometheus'a kazıtıp panoları Grafana'da birleştirmektir.
Netdata arayüzünü güvenli biçimde nasıl açarım#
Arayüzü doğrudan internete açma. netdata.conf içinde bind to = 127.0.0.1 ayarını yap, ardından TLS sonlandıran bir Nginx ya da Caddy üzerinden temel kimlik doğrulamayla yayınla. Firewall'da 19999 portunu kapalı tut ve ss -tlnp çıktısında yalnızca yerel arayüzde dinlediğini doğrula. Yalnızca birkaç kişi erişecekse VPN ya da SSH tüneli en güvenli seçenektir.
Kapanış#
Netdata, izleme kurmanın en düşük sürtünmeli yoludur: tek komut, hiç yapılandırma, saniyeler içinde çalışan yüzlerce grafik. Aklında kalması gereken dört alışkanlık şunlar: kurulumdan hemen sonra bind to = 127.0.0.1 ile portu kapat, üretimde dbengine modunda kal ve disk bütçesini bilinçli seç, kullanmadığın hazır alarmları kapatarak gürültüyü azalt, ve Netdata'yı uzun vadeli izlemenin yerine değil yanına koy. Bu dördüyle birlikte, bir sunucuda ne olduğunu öğrenmek dakikalar değil saniyeler alır.
Saniyelik çözünürlükte izleme, kaynakları paylaşmayan bir makinede en iyi sonucu verir; VDS ve sanal sunucu paketlerimiz tam root erişimiyle bu kurulum için uygundur, yükün değişkense bulut sunucu tarafına bakabilirsin. Kurulumu, alarm ayarlarını ve ters vekil güvenliğini bize bırakmak isterseniz sunucu yönetimi hizmetimiz bu işleri de üstleniyor.