Kurumsal Altyapılarda Sunucu İzleme Araçları: Metrik Takibi, Alarm Mekanizmaları ve Operasyonel Sürdürülebilirlik

Bir sistem yöneticisinin ya da DevOps mühendisinin en büyük kabusu, kullanıcılar ‘Sistem çalışmıyor’ şikayetiyle kapıyı çalmadan önce bir şeylerin ters gittiğini fark edememektir. Reaktif bir yaklaşımdan proaktif bir operasyon modeline geçişin temel taşı, doğru ve sürdürülebilir bir sunucu izleme (monitoring) altyapısı kurmaktır. Bu yazıda, modern sunucu izleme araçlarının mimari temellerini, kritik metrikleri ve üretim ortamlarında karşılaşılan pratik senaryoları ele alacağız.

İzleme (Monitoring) ve Gözlemlenebilirlik (Observability) Arasındaki Fark

Sistematik bir altyapı kurmadan önce kavramları netleştirmek gerekir. İzleme, sistemin çalışıp çalışmadığını, kaynak kullanım oranlarını ve önceden tanımlanmış hata kodlarını takip etmenizi sağlar. Gözlemlenebilirlik ise sistemin iç durumunu, dışarıdan alınan çıktılara (loglar, metrikler, trace’ler) bakarak ne kadar iyi çıkarabildiğinizle ilgilidir.

Günümüz karmaşık mimarilerinde sadece CPU kullanımının %90’a ulaştığını görmek yetersizdir. O CPU artışına hangi mikroservisin, hangi veritabanı sorgusunun veya hangi ağ trafiğinin sebep olduğunu anlamak gözlemlenebilirliğin alanına girer. Ancak her şeyden önce, sağlam bir temel olan sunucu izleme araçlarını yapılandırmamız gerekir.

Modern Sunucu İzleme Mimarisinin Bileşenleri

Bir izleme çözümü genellikle üç ana katmandan oluşur:

1. Veri Toplama (Agents & Exporters): Sunuculardan, konteynerlerden ve uygulamalardan metrikleri toplayan hafif yazılımlar.
2. Zaman Serisi Veritabanı (TSDB - Time Series Database): Toplanan verilerin zaman damgasıyla birlikte yüksek verimlilikle depolandığı veritabanı katmanı (örneğin Prometheus).
3. Görselleştirme ve Alarm (Visualization & Alerting): Verilerin grafiklere döküldüğü ve eşik değerleri aşldığında ekipleri uyardığı arayüzler (örneğin Grafana, Alertmanager).

Kritik Metrikler: Neyi İzlemeliyiz?

Her şeyi izlemek, hiçbir şeyi izlememekle eşdeğerdir. Çok fazla alarm (alert fatigue), operatörlerin gerçek krizleri gözden kaçırmasına neden olur. Odaklanılması gereken temel kaynak grupları şunlardır:

• CPU (İşlemci): User, system ve iowait oranları. Özellikle iowait yüksekse, disk performansında bir darboğaz var demektir.
• Bellek (RAM): Kullanılabilir (available) bellek miktarı ve Swap kullanımı. Swap alanının sürekli aktif olması, fiziksel RAM’in yetersizliğinin ilk işaretidir.
• Disk: Boş alan oranları ve I/O operasyon süreleri (IOPS, latency). Disklerin sadece doluluk oranına değil, yazma/okuma gecikmelerine de dikkat edilmelidir.
• Ağ (Network): Arayüzlerdeki paket kayıpları (packet loss), hata oranları ve bant genişliği kullanımı.

Pratik Kurulum Senaryosu: Prometheus ve Node Exporter ile Linux İzleme

Küçük ve orta ölçekli Linux sunucularında en yaygın ve güvenilir kombinasyonlardan biri Prometheus ve Node Exporter ikilisidir. Aşağıda bu yapının temel adımlarını bulabilirsiniz.

1. Node Exporter Kurulumu

Node Exporter, hedef Linux sunucusundaki sistem metriklerini Prometheus’un okuyabileceği bir formatta sunar.

Öncelikle bir sistem kullanıcısı oluşturalım ve binary dosyayı indirelim:

sudo useradd -rs /bin/false node_exporter
VERSION="1.8.1"
wget https://github.com/prometheus/node_exporter/releases/download/v${VERSION}/node_exporter-${VERSION}.linux-amd64.tar.gz
tar xvf node_exporter-${VERSION}.linux-amd64.tar.gz
sudo cp node_exporter-${VERSION}.linux-amd64/node_exporter /usr/local/bin/
sudo chown node_exporter:node_exporter /usr/local/bin/node_exporter

2. Systemd Servis Dosyası Oluşturma

Node Exporter’ın arka planda bir servis olarak çalışması için /etc/systemd/system/node_exporter.service dosyasını oluşturalım:

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

[Service]
User=node_exporter
Group=node_exporter
Type=simple
ExecStart=/usr/local/bin/node_exporter

[Install]
WantedBy=multi-user.target

Servisi etkinleştirelim ve başlatalım:

sudo systemctl daemon-reload
sudo systemctl enable --now node_exporter
sudo systemctl status node_exporter

Artık sunucunuzun 9100 portunda /metrics endpoint’i üzerinden sistem metrikleri sunulmaktadır.

3. Prometheus Yapılandırması

Merkezi Prometheus sunucunuzun prometheus.yml dosyasına yeni hedefi ekleyin:

scrape_configs:
  - job_name: 'ubuntu-production-server'
    static_configs:
      - targets: ['<SUNUCU_IP_ADRESI>:9100']

Yapılandırmayı güncelledikten sonra Prometheus servisini yeniden başlatarak metrikleri toplamaya başlayabilirsiniz.

Alarm Yönetimi ve Eşik Değerleri Belirleme

İzleme sisteminin kalbi alarm mekanizmasıdır. Yanlış yapılandırılmış alarmlar ya gece yarısı gereksiz uyarılarla uykunuzu böler ya da gerçek bir kesinti sırasında sessiz kalarak sistemin çökmesine neden olur.

İyi bir alarm kuralının özellikleri şunlardır:

1. Eyleme Geçirilebilir Olmalı: Alarm çaldığında sistem yöneticisinin yapabileceği somut bir işlem olmalıdır. (Örn: “CPU %90” yerine “Disk doluluk oranı %95 ve mevcut yazma hızıyla 2 saat içinde tamamen dolacak”).
2. Anlık Değil, Sürdürülebilir Durumları Yakalamalı: Anlık CPU sıçramaları alarm üretmemelidir. Bunun yerine kuralın belirli bir süre devam etmesi şart koşulmalıdır (Örn: for: 5m).

Prometheus Alertmanager Örneği

Disk doluluğu için örnek bir Prometheus alarm kuralı (alert.rules.yml):

groups:
  - name: disk_alerts
    rules:
      - alert: DiskSpaceRunningLow
        expr: (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100 < 15
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Disk alanı azalıyor (instance {{ $labels.instance }})"
          description: "Kök dizin (/) üzerindeki boş alan %15'in altına düştü. Mevcut oran: {{ $value }}%"

Bu kural, kök dizindeki boş alan %15’in altına düştüğünde ve bu durum 10 dakikadan uzun sürerse bir uyarı (warning) üretir.

Log Yönetimi ile İzlemenin Entegrasyonu

Metrikler sistemin “ateşini ve tansiyonunu” ölçer; ancak sorunun kaynağını tam olarak bulmak için loglara ihtiyaç duyarsınız. Modern mimarilerde sunucu metrikleri ile sistem logları (syslog, auth.log, uygulama logları) aynı ekranda (örneğin Grafana Loki entegrasyonu ile) birleştirilmelidir.

Bir güvenlik ihlali veya yetkilendirme hatası (örneğin ard arda başarısız SSH denemeleri), metrik ekranlarında hemen fark edilmeyebilir. Ancak log analizi ile birleştirilmiş bir izleme paneli, bu tür anomalileri erken aşamada yakalamanızı sağlar.

Sürdürülebilir Operasyonlar İçin En İyi Uygulamalar

• İzleme Araçlarını da İzleyin (“Monitoring the Monitor”): İzleme sunucunuz çöktüğünde bunu kim fark edecek? Kritik izleme bileşenlerinizin dış servisler tarafından (harici ping servisleri vb.) kontrol edildiğinden emin olun.
• Panel Tasarımını Sade Tutun: Operasyonel panellerde göz yoran karmaşık grafikler yerine, en kritik 5-6 metriği (CPU, RAM, Disk, Ağ, Hata Oranları) öne çıkarın.
• Kapasite Planlaması İçin Veri Kullanın: İzleme verilerini sadece anlık krizler için değil, geçmişe dönük trend analizi yaparak gelecekteki kaynak ihtiyaçlarını öngörmek için kullanın.

Sonuç

Sunucu izleme araçları, sistem yöneticisinin dijital dünyadaki gözü ve kulağıdır. Doğru yapılandırılmış bir metrik toplama ve alarm altyapısı, reaktif kriz yönetiminden proaktif operasyonel mükemmeliyete geçişin anahtarıdır. Sistemi sürekli gözlem altında tutmak, hem sistem kararlılığını artırır hem de operasyonel stresi minimuma indirir.

---

Bu yazı Gemini ile otomatik oluşturulmuştur.