Ücretsiz Sunucu İzleme (Monitoring): Araçlar, Kurulum ve Karşılaştırma

Sunucu izleme (monitoring), altyapı sorunlarını kullanıcı görmeden önce yakalamanın en kısa yoludur. Ücretsiz araçlarla; CPU/RAM/disk kullanımını, servis durumunu, gecikmeyi ve bant genişliğini düzenli ölçebilir, uyarıları e-posta/Slack gibi kanallara iletebilirsiniz. Bu rehberde, VDS/VPS/dedicated senaryolarında işe yarayan ücretsiz çözümleri net biçimde karşılaştırıyor; hangi aracı ne zaman seçeceğinizi kurulum odaklı anlatıyoruz.

1) İzleme stratejisi: Neyi, hangi sıklıkla izleyeceksiniz?

Önce “tek bir araç her şeyi çözer” yaklaşımını bırakın. Ücretsiz araçlar güçlüdür; ancak kapsamı doğru kurgulamak gerekir. Aşağıdaki tablo, izleme hedeflerini ve hangi metriklerin kritik olduğunu netleştirir.

Hedefe göre araç sınıfı

• Agent tabanlı sistem ölçümü (ör. Netdata): Sunucu üzerinde metrik toplar, görselleştirir.
• Zaman serisi + sorgu (ör. Prometheus): Metrikleri toplar ve sorgular; uyarı kurallarını yönetir.
• Agent+sunucu (ör. Zabbix): Hem metrik hem servis kontrolüyle geniş kapsam sağlar.
• Dışarıdan erişim kontrolü (ör. Uptime Kuma): HTTP/TCP/sertifika kontrolüyle “dış görünürlük” sağlar.

2) En popüler ücretsiz monitoring araçları (net karşılaştırma)

Aşağıdaki karşılaştırma, yalnızca “popülerlik” değil; kurulum karmaşıklığı, kapsam ve tipik kullanım senaryosuna göre yapılmıştır.

Zabbix ne zaman daha mantıklı?

Zabbix, “CPU düştü değil; servis çalışmıyor” gibi durumları da net yakalayan bir yaklaşıma sahiptir. Şablonlar sayesinde aynı kontrol setini birden fazla sunucuya taşımak kolaylaşır. Ücretsiz olması, küçük ekiplerin maliyetsiz başlangıç yapmasını sağlar.

Netdata ne zaman en hızlı sonuç verir?

Netdata, agent kurduğunuz anda gerçek zamanlı grafikler üretir. Özellikle VDS üzerinde “şu an ne oluyor?” sorusuna hızlı cevap almak istiyorsanız avantajlıdır.

Prometheus neden seçiliyor?

Prometheus; etiket (label) mantığıyla metrikleri düzenler. Bu, “hangi uygulama/endpoint/servis” sorularını sorgularken güçlü olur. Ancak tek başına “uygulama seviyesinde servis down” kontrolünü her zaman aynı kolaylıkla sunmayabilir; genelde exporter/blackbox yaklaşımıyla genişletirsiniz.

3) Kurulum: Netdata ile hızlı sistem metrik izleme (ücretsiz)

Bu bölüm “en kısa sürede çalışan monitoring” hedefiyle hazırlanmıştır.

Hangi bilgiyi izler?

Netdata; CPU, RAM, swap, disk kullanımı, I/O, ağ arayüzleri gibi metrikleri çoğunlukla anlık/near-realtime toplar.

Basit kurulum mantığı

Dağıtımınıza göre komutlar değişir; fakat genel akış şöyledir: 1. Sunucuya Netdata agent kurun. 2. Agent servisinin çalıştığını doğrulayın. 3. Uyarı (notification) kanallarını ekleyin. 4. Paneller üzerinden temel eşiği (ör. disk %80) belirleyin.

Not: Kurulum komutları dağıtıma göre değiştiği için, kullandığınız işletim sistemi (Ubuntu/Debian/CentOS/Rocky vb.) ile uyumlu resmi kurulum talimatını referans alın.

Uyarıları netleştirin

Ücretsiz araçlarda en sık hata “her şeye alarm” üretmektir. Aşağıdaki gibi 3-5 alarm ile başlayın: - Disk doluluğu: %80 uyarı, %90 kritik - CPU yük: load average veya CPU kullanımına göre 15 dk ortalama - RAM/swap: swap yükselmesi (swap, gerçek RAM darboğazına işaret eder) - Servis: (opsiyonel) süreç bazlı kontrol veya ayrı araç entegrasyonu

4) Zabbix ile çoklu sunucu monitoring: Tek merkez, şablon mantığı

Birden fazla VDS/VPS yönetecekseniz Zabbix’in “merkezi kontrol” yaklaşımı değerlidir.

Mimariyi doğru kurun

Tipik kurulum iki parçadan oluşur: - Zabbix server: Metriği alır, veri tabanına yazar, alarm/rapor üretir. - Zabbix agent: İzlenecek sunucuda metrikleri toplar.

Servis izleme için pratik yaklaşım

Zabbix’te servis izlemenin en net yolu şu iki katmanı birlikte düşünmektir: 1. Sistem metrikleri (CPU/RAM/disk): Sunucu sağlığı 2. Uygulama kontrolü (HTTP/TCP/komut): Servis çalışıyor mu?

Alarm eşiği örnekleri

• Web sunucusu için: HTTP status 2xx/3xx değilse 2-3 denemeden sonra alarm
• MySQL/PostgreSQL için: servis down veya bağlantı reddi (connection refused)
• Disk için: inode doluluk (inode, sık log üreten sistemlerde erken uyarır)

5) Prometheus ile metrik odaklı izleme: Esneklik + sorgu gücü

Prometheus; metrikleri zaman serisi veritabanı mantığıyla toplar. Ücretsiz olduğundan üretim için de başlangıçta uygundur, fakat ek bileşenler gerektirebilir.

Temel parçalar

• Prometheus server: Scrape eder (hedeflerden metrik toplar).
• Exporters: Uygulama/OS metriklerini Prometheus formatına dönüştürür.
• Alertmanager: Alarm yönetimi (gruplama, tekrar bastırma, bildirim).
• Grafana (opsiyonel): Paneller için yaygın kullanılır.

Kim için uygun?

• Uygulama metriklerini (ör. uygulama içi endpoint sayıları/latency) etiketlerle sorgulamak isteyen ekipler
• “Hangi servis ne kadar hata üretiyor?” gibi sorulara hızlı rapor üretmek isteyenler

Sık yapılan hata: yanlış scrape aralığı

• 1 saniyelik scrape ile küçük sunucularda dahi gereksiz yük oluşabilir.
• 60 saniyeden uzun aralıklar, “hızlı çökme” olaylarını geç yakalamanıza neden olur.

Net kural: Başlangıçta 15-30 sn hedefleyin, kritik olaylarda sadece ilgili target’larda daha sık aralığa geçin.

6) Uptime Kuma ile “dışarıdan erişilebilirlik” takibi (ücretsiz)

Uptime Kuma; kullanıcıların gördüğü erişim durumunu ölçmek için idealdir. Monitoring dünyasında bu “synthetic monitoring” olarak da geçer.

Neyi izler?

• HTTP/HTTPS yanıt süresi ve status
• Belirli URL’lerde içerik kontrolü (bazı senaryolarda)
• TCP/port kontrolü
• Sertifika bitiş tarihi (TLS)

Net alarm politikası

• Tek başarısız denemede alarm vermeyin: 2-3 denemeyi bekleyin
• Aynı anda birden fazla endpoint için aşırı bildirim kurgulamayın
• Eşik değerleri: Örn. 30 saniyeden fazla yanıt süresi (p95/p99 yoksa ortalama) + 3 deneme

7) Hangi aracı birlikte kullanmalısınız? (Net senaryo önerileri)

Tek araç seçmek yerine “katmanlı” düşünmek daha doğru sonuç verir.

Senaryo A: Tek VDS + hızlı başlangıç

• Netdata: sistem metrikleri
• (Opsiyonel) Uptime Kuma: dışarıdan web uptime

Senaryo B: 5-20 sunucu + merkezi alarm

• Zabbix: sistem+servis kontrolü
• (Opsiyonel) Grafana: raporlama ihtiyaçları için görselleştirme

Senaryo C: Uygulama metrikleri ve sorgu öncelikli

• Prometheus + exporters
• Alertmanager ile alarm
• Grafana paneller

Senaryo D: “Sadece servis çalışıyor mu?” odak

• Uptime Kuma ile HTTP/TCP check
• Disk/CPU için Netdata veya basit agent tabanlı yaklaşım

8) Ücretsiz monitoringde kaliteyi artıran 8 kontrol listesi

Ücretsiz araçlar doğru kurulmazsa ya yanlış alarm üretir ya da veri toplamada süreklilik kaybolur. Aşağıdaki liste pratikte fark yaratır.

• Uyarı eşiğini sayısallaştırın: “yük çok arttı” yerine %80 veya belirli gecikme eşiği
• Alarm tekrarını sınırlayın: 5 dakika üst üste aynı alarmı tek bildirim yapmak gibi
• Zaman senkronizasyonu kontrolü: Sunucuların saatleri kayarsa grafik ve alarm tutarsız görünür
• Depolama planı yapın: Veri tabanının diskini izleyin (monitoring de monitoring ister)
• Log ve agent tüketimini ölçün: Agent aşırı CPU tüketiyorsa “monitoring kendi performans sorununa dönüşür”
• Ağ sorunlarını ayırın: “Sunucu down” ile “network drop” aynı şey değildir; kontrolü farklı hedeflerle doğrulayın
• Bildirim kanalını netleştirin: E-posta/Slack/Telegram; tek kanalda kalın, filtre uygulayın
• Düzenli doğrulama: Ayda 1 “alarm doğru mu?” denemesi yapın (test endpoint ile)

Sonuç: Aksiyona dönüşen seçim yapın

Bugün başlayacaksanız en net yol şu şekilde ilerlemektir: (1) Önce Netdata ile sistem metriklerini görünür kılın, (2) Uptime Kuma ile dışarıdan erişim ve sertifika bitişini takip edin, (3) Sunucu sayısı ve alarm ihtiyacı büyürse Zabbix veya Prometheus ekleyerek merkezi ve sorgu tabanlı yapıya geçin. Bir sonraki adım olarak, izleyeceğiniz ilk 5 alarmı (disk %80, swap artışı, HTTP durumu, yanıt süresi eşiği, servis down) yazıp kurulumları buna göre sıralayın; böylece ücretsiz araçlarla bile ölçüm kalitesi net biçimde artar.