Linux Sunucu İzleme Kurulumu: Uptime ve Alarm

Bir Linux sunucuda kaynak tükenmesi (CPU, RAM, disk, inode) ve kritik servis kesintileri genellikle kullanıcılar hata alana kadar sessizce büyür. Bu riski ortadan kaldıran etkili bir linux sunucu izleme kurulumu iki katmanlı kurgulanır: Dış katman uptime ve HTTP yanıt süresini ağ dışından ölçerken, iç katman CPU, RAM, disk ve systemd servis durumlarını doğrudan işletim sistemi çekirdeğinden toplar ve belirlenen eşikler aşıldığında alarm üretir.

Hızlı Çözüm / Özet Adımlar (TL;DR)
1. Mevcut Durumu Doğrulayın: uptime, free -h, df -h ve df -i komutlarıyla taban kaynak kullanımını görün.
2. Metrik Toplayıcıyı Kurun: Node Exporter ikili dosyasını indirip ayrıcalıksız bir kullanıcıyla systemd servisi olarak başlatın.
3. Dış Kontrol Sağlayın: Uptime Kuma gibi bir araçla HTTP durum kodlarını (200 OK) ve SSL sertifika geçerlilik sürelerini dış ağdan izleyin.
4. Gürültüsüz Alarmlar Tanımlayın: Anlık sıçramalar yerine "5 dakika boyunca %85 üzerinde" gibi süreye bağlı eşik kuralları belirleyin.

Linux Sunucu İzleme Nedir ve Hangi Katmanlar Gerekir?

Sunucu izleme, sistem bileşenlerinin sağlık durumunu telemetri verileri üzerinden sürekli analiz etme sürecidir. Birçok sistem yöneticisi yalnızca web sitesinin açık olup olmadığını kontrol etmeyi yeterli bulsa da tam kapsamlı bir izleme mimarisi iç ve dış katmanların birleşiminden oluşur.

Uptime İzleme ile Kaynak İzlemenin Farkı

Uptime izleme, sunucunun dış dünyaya sunduğu ağ kapılarını (HTTP/HTTPS, ping, TCP portları) dışarıdan periyodik olarak sorgular. Bu katman, web sunucusunun yanıt verip vermediğini ve DNS çözümleme hızını raporlar. Ancak sunucunun iç dünyasından habersizdir; örneğin diski %99 dolmuş bir makine, son bloklar tükenene kadar HTTP 200 yanıtı vermeye devam edebilir.

Sunucu kaynak izleme ise işletim sistemi içine yerleşir. Çekirdek metriklerini okuyarak belleğin tükenmek üzere olduğunu, disk kuyruklarının şiştiğini veya bir arka plan işleminin CPU çekirdeklerini kilitlediğini dış katmandan çok daha önce fark eder.

Kritik Sistem Metrikleri

Sunucu sağlığını izlerken tek bir metriğe odaklanmak yanıltıcıdır. Aşağıdaki metrikler birbirleriyle doğrudan ilişkilidir:

Kurulum Öncesi Hazırlık ve Mimari Seçimi

İzleme mimarisini tasarlarken sunucu parkının büyüklüğü ve güvenlik gereksinimleri dikkate alınmalıdır. Küçük ölçekli yapılar için hafif çözümler idealken, dağıtık sistemler merkezi izleme platformlarına ihtiyaç duyar.

Ortam Seçimi: Barındırılan Araç vs. Sunucu İçi Ajan

Tek bir VPS veya küçük bir ortam yönetiyorsanız, Docker üzerinde çalışan bir Uptime Kuma kurulumu hızlıca dış uptime kontrolü ve temel bildirimleri sağlayabilir. Birden fazla sunucudan oluşan veya mikroservis barındıran yapılarda ise Prometheus Node Exporter kurulumu ya da Zabbix Linux agent kurulumu standart yaklaşımdır. Node Exporter, işletim sistemi çekirdeğinden metrikleri çekerek HTTP üzerinden dışa aktarır (/metrics), merkezi bir Prometheus sunucusu da bu verileri toplar.

Ağ Güvenliği ve Erişim Kısıtlamaları

Node Exporter varsayılan olarak 9100 portundan kimlik doğrulamasız metrik yayını yapar. Bu portun internete açık bırakılması, sunucunun çekirdek sürümünü, dosya sistemi yapısını ve bellek durumunu kötü niyetli tarayıcılara açık hale getirir.

Metrik portlarını korumak için ufw veya iptables ile sadece merkezi izleme sunucusunun IP adresine izin verin:

sudo ufw allow proto tcp from 198.51.100.50 to any port 9100 comment "Prometheus Server"

Alternatif olarak, ajan yerel ağda (127.0.0.1:9100) çalıştırılıp Nginx reverse proxy arkasına temel kimlik doğrulama (HTTP Basic Auth) ve TLS sertifikası konularak dışarıya açılabilir.

Adım Adım Linux Sunucu İzleme Kurulumu

Eksiksiz bir izleme zinciri; temel kontrol, ajan kurulumu, dış uptime izleme ve alarm bildirim hatlarının yapılandırılmasıyla kurulur.

Adım 1: Sunucu Durumunu Temel Komutlarla Doğrulayın

Ajan kurulumuna başlamadan önce sistemin mevcut durumunu terminalden kontrol edin:

uptime
free -h
df -h
df -i
systemctl --failed

Bu çıktılar sayesinde halihazırda kilitlenmiş bir systemd servisi, tükenmiş bir inode tablosu veya swap alanına taşmış bellek durumu varsa kurulum öncesinde tespit edilir.

Adım 2: Node Exporter Kurulumu ve Systemd Servisi

Node Exporter'ı doğrudan izole bir sistem kullanıcısı ile çalıştırmak güvenlik açısından en temiz yöntemdir.

Önce izole bir sistem kullanıcısı açın ve binary dosyasını yerleştirin:

sudo useradd --no-create-home --shell /bin/false node_exporter
cd /tmp
curl -LO https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz
tar -xvf node_exporter-1.8.2.linux-amd64.tar.gz
sudo cp node_exporter-1.8.2.linux-amd64/node_exporter /usr/local/bin/
sudo chown node_exporter:node_exporter /usr/local/bin/node_exporter

Ardından bir systemd servis dosyası oluşturun (/etc/systemd/system/node_exporter.service):

[Unit]
Description=Prometheus Node Exporter
After=network.target

[Service]
User=node_exporter
Group=node_exporter
Type=simple
ExecStart=/usr/local/bin/node_exporter --web.listen-address=127.0.0.1:9100

[Install]
WantedBy=multi-user.target

Servisi kaydedip başlatın:

sudo systemctl daemon-reload
sudo systemctl enable --now node_exporter
curl http://127.0.0.1:9100/metrics | head -n 15

Adım 3: Dış Uptime ve Yanıt Süresi İzleme

Uptime katmanında birincil hedef HTTP durum kodu (200 OK) ve Time to First Byte (TTFB) süresidir. Web sunucunuz HTTP 500/502/504 döndürdüğünde ya da SSL sertifikasının bitimine 7 günden az kaldığında dış izleme motoru derhal bildirim üretmelidir.

Yüksek yanıt süreleri ve aşırı TTFB gecikmeleri algılandığında, altyapı kaynaklarının yanı sıra veritabanı sorguları ve dinamik PHP/Python süreçleri de gözden geçirilmelidir. Bu tarz gecikmelerin analizi için web sitesi neden yavaş teşhisi rehberindeki adımları uygulayabilir; barındırma ve yazılım katmanında kapsamlı bir iyileştirme gerekiyorsa doğrudan web sitesi hızlandırma hizmeti kapsamından faydalanabilirsiniz.

Adım 4: Bildirim Kanalı (Webhook Entegrasyonu)

Alarmların e-posta kutusunda kaybolmasını önlemek için Slack, Discord veya Telegram webhook yapılandırması tercih edilmelidir. Alertmanager ya da Uptime Kuma üzerinde tanımlanacak örnek bir webhook yapılandırma şablonu şu mantıkla çalışır:

global:
  resolve_timeout: 5m

receivers:
- name: 'slack-notifications'
  slack_configs:
  - api_url: 'https://hooks.slack.com/services/ENV_SLACK_WEBHOOK_SECRET'
    channel: '#sunucu-alarmlari'
    text: "Sunucu Uyarısı: {{ .CommonAnnotations.summary }}\nAçıklama: {{ .CommonAnnotations.description }}"

Eşik Değerleri ve Alarm Tasarımı

Alarm sistemlerinin en büyük handikabı gürültüdür (alert fatigue). Sürekli gereksiz uyarı gönderen bir sistem, gerçek kriz anlarında yöneticilerin bildirimi görmezden gelmesine yol açar.

Süreye Dayalı Eşikler (Gürültü Azaltma)

Bir sunucuda anlık yedekleme başladığında CPU kullanımı 30 saniyeliğine %95 seviyesine fırlayabilir. Bu bir arıza değil, olağan bir durumdur. Bu nedenle kurallar anlık tetiklemeler yerine süre filtreleriyle tanımlanmalıdır:

# 5 dakika boyunca CPU boştalık oranı %15'in altındaysa alarm üret
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85

Bu PromQL kuralı, işlemci kullanımının kesintisiz olarak 5 dakika boyunca %85 üzerinde seyretmesi durumunda uyarı verir; anlık sıçramaları filtreler.

# Disk kullanım oranı son 10 dakikadır %85 üzerinde olan bölüntüler
(node_filesystem_size_bytes{fstype!~"tmpfs"} - node_filesystem_free_bytes{fstype!~"tmpfs"})
/ node_filesystem_size_bytes{fstype!~"tmpfs"} * 100 > 85

Cooldown Süresi ve Bakım Pencereleri

Aynı sorun çözülene kadar dakikada bir telefonunuza bildirim düşmesini engellemek için sistemde repeat_interval (tekrar bildirimi) en az 2 ila 4 saat olarak yapılandırılmalıdır. Planlı güncellemeler sırasında yanlış alarmları önlemek adına izleme panelinde "Sessize Alma" (Mute / Maintenance Window) tanımlamak zorunludur.

Kritik Uç Vaka (Edge Case): Inode Tükenmesi
df -h çalıştırdığınızda disk doluluk oranınız %40 görünebilir. Ancak sunucuda binlerce minik oturum (session) veya e-posta kuyruk dosyası birikmişse inode tablosu tamamen dolabilir. Inode tükenen bir dosya sisteminde diskte yüzlerce gigabayt boş alan olsa dahi işletim sistemi "No space left on device" hatası verir ve MySQL/Nginx kilitlenir. Bu yüzden inode kullanımını (df -i) mutlaka ayrı bir metrik olarak izlemelisiniz.

Periyodik log sıkıştırma ve disk temizleme adımlarını doğru yönetmek için linux sunucu bakımı rehberi içeriğindeki optimize depolama yönergelerini inceleyebilirsiniz.

Sık Yapılan Hatalar ve Tanılama

İzleme sistemi devreye alındıktan sonra yanlış yapılandırılmış göstergeler gereksiz panik oluşturabilir.

Yanlış Pozitif: Buffer ve Cache Belleği "Dolu" Saymak

Linux çekirdeği boştaki belleği disk önbelleği (cache/buffers) olarak değerlendirir. free -m çıktısında "used" sütununu doğrudan alarm metriği yaparsanız, sunucunuz sağlıklı olmasına rağmen her zaman %90 dolu alarmı alırsınız. Dikkate alınması gereken yegane değer available (kullanılabilir) bellek sütunudur.

Log Dosyalarının Ani Büyümesi

Sunucuda dönmeyen (rotate edilmeyen) log dosyaları diski hızla doldurabilir. Diskin neden şiştiğini görmek için systemd günlüklerinin boyutunu kontrol edin:

journalctl --disk-usage
sudo journalctl --vacuum-size=500M

Adım Adım Alarm Tanılama Akışı

Telefonunuza kritik kaynak uyarısı düştüğünde sırasıyla şu rotayı takip edin:

1. Uptime ve Load İncelemesi: uptime ile işlem sırasının çekirdek sayısına oranını teyit edin.
2. Süreç Takibi: top veya htop açarak en çok CPU/RAM tüketen işlemleri PID bazında belirleyin (Shift + P veya Shift + M).
3. Disk ve Inode Kontrolü: df -h ve df -i komutlarıyla dar boğazın depolama kaynaklı olup olmadığını kesinleştirin.
4. Log Teşhisi: journalctl -xe veya tail -f /var/log/syslog ile hata fırlatan servisi tespit edin.
5. Kontrollü Müdahale: İlgili süreci öldürmek (kill -9) yerine yapılandırma hatasını giderip systemd üzerinden zarifçe (systemctl restart) yeniden başlatın.

Ne Zaman Uzman Desteği Gerekir?

Kendi kurduğunuz izleme ajanları size yalnızca durumun kötüye gittiğini haber verir; ancak sistem kilitlendiğinde, veritabanı tabloları bozulduğunda ya da sunucu yanıt vermez hale geldiğinde müdahale kabiliyeti kritikleşir. Özellikle üretim ortamlarında Nginx/PHP-FPM/MySQL ince ayarlarının yapılması, SSH ve Fail2Ban/CrowdSec sıkılaştırma adımlarının uygulanması ve 90'dan fazla kontrol noktasını barındıran çekirdek seviyesi optimizasyonlar derin Linux uzmanlığı gerektirir.

İzleme altyapınız sürekli eşik aşımları bildiriyorsa, acil müdahale ihtiyaçlarında veya altyapınızı uçtan uca aylık yönetim altında tutmak istediğinizde Linux sunucu bakım hizmeti seçeneklerini değerlendirebilirsiniz. Performans paketleri ve periyodik sistem sıkılaştırması sayesinde kaynak krizlerini henüz alarm aşamasına gelmeden önleyebilirsiniz.

Sıkça Sorulan Sorular

Linux sunucu izleme için hangi araç en uygun?

Tekil sunucular ve web servisleri için Uptime Kuma kurulum kolaylığıyla öne çıkar. Detaylı sistem telemetrisi, çekirdek metrikleri ve çoklu sunucu yönetimi gerektiğinde ise endüstri standardı Prometheus Node Exporter ve Grafana ikilisidir.

Sunucu izleme ile uptime kontrolü aynı şey midir?

Hayır. Uptime kontrolü sunucunuza dışarıdan ping veya HTTP istekleri göndererek yalnızca servisin erişilebilir olup olmadığını test eder. Sunucu izleme ise makinenin içindeki CPU, RAM, disk, inode ve servis süreçlerini içeriden okuyarak potansiyel krizleri önceden haber verir.

Disk doluluk alarmını hangi yüzdede kurmalıyım?

Genel en iyi pratik iki kademeli alarm kurmaktır: %80 doluluk seviyesinde düşük öncelikli bir uyarı (warning), %90 doluluk seviyesinde ise anında müdahale gerektiren kritik (critical) alarm tanımlanmalıdır.

Sunucu izleme yavaşlığa neden olur mu?

Düzgün yapılandırılmış modern ajanlar (Node Exporter, Zabbix Agent) C veya Go ile derlenmiş son derece hafif ikili dosyalardır. Doğru yapılandırıldığında bu ajanlar genellikle CPU'nun %0.1'inden daha azını ve 15-30 MB civarında bir RAM miktarını tüketir; sistemde fark edilir bir yavaşlık yaratmaz.

Son Kontrol Listesi
- [x] Ajan Güvenliği: Node Exporter yalnızca yerel ağa (127.0.0.1) veya firewall ile kısıtlanmış güvenli IP adreslerine açıldı.
- [x] Alarm Eşikleri: Anlık sıçramaları filtrelemek için alarmlara süre koşulları (for: 5m) ve inode takibi eklendi.
- [x] Uçtan Uca Doğrulama: Test webhook bildirimi tetiklenerek alarmın hedeflenen iletişim kanalına ulaştığı doğrulandı.