VPS İzleme ve Uyarı Nasıl Kurulur? Prometheus, Grafana ve Node Exporter ile Sessiz Alarmları Konuşturmak

Hiç ansızın sitenin yavaşladığını fark edip, ‘Acaba benim tarafta mı bir şey var?’ diye kurcaladığınız oldu mu? Benim oldu. Hem de öyle bir gece ki, tarayıcıda dönen o küçük yükleniyor simgesi bana dakikaları saat gibi hissettirdi. Sunucuya SSH ile bağlandım, birkaç komut, birkaç tahmin, sonra sessizlik… O an şunu düşündüm: Bu işleri şansa bırakmak yerine, olup biteni anlık izleyen ve doğru zamanda, doğru kişiye haber veren bir sistem kurmak şart.

Bugün konuşacağımız konu tam da bu: VPS üzerinde CPU, RAM, disk I/O ve uptime metriğini, Prometheus, Grafana ve Node Exporter üçlüsüyle nasıl toplayıp, görselleştirip, gerektiğinde alarm üretiriz? Mesela şöyle düşünün: CPU bir süre normal, sonra kısa bir sıçrama ve ardından uzun bir tırmanış. Hangisi önemli? Hangisinde uyanıp müdahale etmelisiniz? İşte bu yazıda, bunu ayırt ettirecek pratik kuralları, kurulum adımlarını ve günlük hayatta işleyen küçük püf noktalarını, samimi bir dille, adım adım anlatacağım.

Yazının sonunda, kurabileceğiniz basit ama güçlü bir izleme mimariniz olacak. Üstelik sadece metrik toplamakla kalmayacağız; gürültü yapan gereksiz uyarıları da eleyip gerçekten önemli anlarda haber veren, yani sessiz ama isabetli bir sistem kuracağız. Hazırsanız başlayalım.

Neden İzleme, Neden Şimdi?

Bir VPS’yi yönetirken en büyük yanılgı, işler yolunda gittiğinde her şeyin yolunda olduğu inancı. Oysa altyapı problemleri genelde sessizce başlar: RAM yavaş yavaş dolar, disk I/O arada bir sıçrar, CPU belirli aralıklarla tavan yapar, uptime grafiğiniz bir anlığına düşer ve siz o sırada kahve koymak için yerinizden kalkmışsınızdır. Kulağa tanıdık geldi mi?

İzleme sistemi kurmak aslında küçük bir alışkanlık meselesi. Prometheus metrikleri çeker, Grafana hikayeyi anlatır, Node Exporter da sunucunun nabzını tutar. Benim için bu üçlü, ‘anlamlı sessizlik’ sağlıyor. Yani her an bildirim yağmuru yok, ama önemli bir şey olduğunda bipleyen bir dost gibi. Performans düşmeden önce gelen küçük bir uyarı, bazen bir gece uykusunu, bazen bir kampanya satışını kurtarıyor.

Bir de şunu fark ettim: İzleme kurmak sadece sorun olduğunda değil, kapasite planlarken de yardımcı. Mesela yoğun kampanya günlerinde CPU ve RAM nasıl davranıyor, disk hangi saatlerde yoruluyor, hangi endpoint daha fazla yük yaratıyor? Bu soruların cevabı gözünüzün önünde olunca karar vermek kolaylaşıyor.

Mimarinin Kafadaki Resmi: Kim Ne Yapıyor?

Mesela şöyle düşünün: Mutfakta herkesin bir görevi var. Node Exporter, fırının ısısını, ocağın alevini, dolabın içindeki yiyecek sayısını anlık not alan sessiz bir yardımcı. Prometheus, bu notları düzenli aralıklarla mutfaktan alıp defterine işliyor. Grafana ise duvarda asılı panoda bu verileri renkli grafiklerle bize gösteriyor. Alarmlar mı? Onlar da evin zili gibi; gerektiğinde çalıyor.

Biraz daha teknik ama sade haliyle mimari şöyle:

– Node Exporter: VPS üzerinde çalışır, sistem metriklerini sunar (CPU, RAM, disk, network, uptime). Varsayılan port 9100.

– Prometheus: Bir sunucuda (aynı VPS veya ayrı) çalışır, Node Exporter’dan metrikleri çekerek kaydeder. Alarmları bu kısım tetikler.

– Grafana: Prometheus’a bağlanır, panolar oluşturur. Metrikleri okunur hale getirir.

– Alertmanager: Prometheus’tan gelen uyarıları e-posta, Slack ya da webhook gibi kanallara gönderir. Sessizlik ve bakım zamanlarını yönetmek için birebirdir.

İhtiyaca göre Blackbox Exporter gibi ekler de kullanılabilir. Örneğin HTTP ping ile dışarıdan uptime kontrolü yapmak istiyorsanız mantıklı. Ama ilk adımda şart değil; Node Exporter ve Prometheus ile sunucunun nabzını tutmak çoğu senaryo için yeterli başlangıç.

Node Exporter Kurulumu: Sunucunun Nabzını Tutalım

Hafif, Sessiz, Güvenilir

Node Exporter gerçekten hafif. Kurunca unutabilirsiniz. Temel metrikleri toplar: CPU kullanım yüzdesi gibi kaba değerlerden ziyade, çekirdek başına zaman, load average, memory available, disk okuma-yazma hızları, iowait gibi detayları sunar. Biz alarmları bu detayların yorumlanmış haline kuracağız.

Kurulum Adımları (Ubuntu örneği)

Aşağıdaki adımlar root veya sudo ile ilerler. Port 9100’ün firewall üzerinden erişilebilir olduğundan emin olun ama sadece Prometheus’un eriştiği ağlarla sınırlayın.

# Node Exporter indir ve çalıştır (servis olarak)
useradd --no-create-home --shell /usr/sbin/nologin nodeexp
cd /tmp
VER=1.8.1
curl -LO https://github.com/prometheus/node_exporter/releases/download/v$VER/node_exporter-$VER.linux-amd64.tar.gz
tar xvf node_exporter-$VER.linux-amd64.tar.gz
cp node_exporter-$VER.linux-amd64/node_exporter /usr/local/bin/
chown nodeexp:nodeexp /usr/local/bin/node_exporter

cat > /etc/systemd/system/node_exporter.service << 'EOF'
[Unit]
Description=Node Exporter
Wants=network-online.target
After=network-online.target

[Service]
User=nodeexp
Group=nodeexp
Type=simple
ExecStart=/usr/local/bin/node_exporter --collector.filesystem.ignored-mount-points='^/(sys|proc|dev|run|var/lib/docker/.+)($|/)'

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now node_exporter

Kurulumdan sonra metrikleri kontrol etmek için tarayıcı veya curl ile şunu deneyin: http://sunucu-ip:9100/metrics. Güvenlik açısından bunu herkese açık bırakmak yerine, Prometheus sunucusuna özel erişim sağlayın. Network politikası burada en iyi dostunuz.

Prometheus: Veriyi Toplayan ve Alarmı Tetikleyen Beyin

Kurulum ve Temel Ayarlar

Prometheus’u tek bir binary ile veya paket yöneticisi, Docker ya da container orchestrator üzerinden kurabilirsiniz. Basit bir dosya yapısı ile başlamak yeterli. Örnek konfigürasyon:

# /etc/prometheus/prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['10.0.0.10:9100', '10.0.0.11:9100']  # VPS'leriniz

rule_files:
  - 'rules/*.yml'

Depolama için yeriniz olsa bile, elde edeceğiniz iş değeri ilk günlerde grafikleri okumak ve alarmları ayarlamak olacaktır. Retention süresini çok uzun tutmak yerine, önce kaliteli kural yazmaya odaklanın. Prometheus dünyasına yeniyseniz, resmi dokümana göz atmak iyi gelir: Prometheus genel bakış ve çalışma mantığı.

Alertmanager ile Bildirim

Uyarıları e-posta ya da Slack’e göndermek için Alertmanager kurmanız gerekir. Prometheus, kurallara göre alarmı tetikler ve Alertmanager’e yollar; oradan da size bildirim gelir. Küçük ama etkili bir yapı.

# /etc/alertmanager/alertmanager.yml
route:
  receiver: 'mail'
  group_by: ['alertname', 'instance']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 2h

receivers:
  - name: 'mail'
    email_configs:
      - to: [email protected]
        from: [email protected]
        smarthost: smtp.ornek.com:587
        auth_username: [email protected]
        auth_identity: [email protected]
        auth_password: 'gizli-sifre'
        require_tls: true

Grafana tarafında da alarmlar oluşturabilirsiniz, ama temel sistemsel metriklerde Prometheus + Alertmanager ikilisi genellikle daha esnek. Panolar içinse Grafana şahane.

Alarm Kuralları: Gürültü Değil, Anlamlı Sinyal

İyi bir alarm kuralı, ekranı kırmızıya boyamak için değil, sizi doğru zamanda ayağa kaldırmak için vardır. Şimdi CPU, RAM, disk I/O ve uptime için yalın ama etkili örnek kurallar yazalım. Bunları ‘rules’ klasöründe ayrı dosyalarda tutabilirsiniz.

CPU: Kısa Sıçrama mı, Kalıcı Baskı mı?

Kısa süreli CPU tavanları çoğu zaman panik sebebi değildir. Asıl dikkat edilmesi gereken, belirli bir süre yüksek kalması. O yüzden ‘for’ süresi kullanırız.

# rules/cpu.yml
groups:
- name: cpu-alerts
  rules:
  - alert: CPUHighSustained
    expr: avg by (instance) (rate(node_cpu_seconds_total{mode!='idle'}[5m])) > 0.85
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: 'CPU uzun süre yüksek ({{ $labels.instance }})'
      description: 'Son 10 dakikada CPU kullanımı %85 üzeri. Uygulama yükünü ve sorguları kontrol edin.'

Burada 5 dakikalık ortalama ve 10 dakika sabit kalma koşulunu birlikte kullandık. Böylece küçük sıçramalar yerine baskıyı yakalıyoruz.

RAM: Tükenmeye Yakın Sinyali

RAM kullanımında doğrudan ‘usage’ yerine ‘available’ mantığını takip etmek daha anlaşılır. Sistem cache tutabilir, ama available düşüyorsa yavaşlama kapıda demektir.

# rules/memory.yml
groups:
- name: mem-alerts
  rules:
  - alert: MemoryLow
    expr: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.1
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: 'RAM kritik eşikte ({{ $labels.instance }})'
      description: 'Kullanılabilir bellek %10 altına indi. Uygulama bellek sızıntısı veya artan yük olabilir.'

Özellikle e-ticaret dönemlerinde bu uyarı, uygulama önbelleği veya sorgu optimizasyonu için güzel bir hatırlatıcı olur. Bu noktada önbellekleme kuralları da işinizi kolaylaştırır; merak ederseniz WordPress ve WooCommerce tarafında CDN önbellek kurallarıyla hız kazanmanın yolu yazısını faydalı bulabilirsiniz.

Disk: Dolu mu, Yorgun mu?

Disk için iki ayrı uyarı mantıklı: Alan yetersizliği ve I/O baskısı. İlki acildir, ikincisi performansı gizliden gizliye kemirir.

# rules/disk.yml
groups:
- name: disk-alerts
  rules:
  - alert: DiskSpaceLow
    expr: (node_filesystem_avail_bytes{fstype!~'tmpfs|overlay'} / node_filesystem_size_bytes{fstype!~'tmpfs|overlay'}) < 0.1
    for: 10m
    labels:
      severity: critical
    annotations:
      summary: 'Disk alanı kritik ({{ $labels.instance }})'
      description: 'Kalan disk alanı %10 altına düştü. Log temizliği veya ölçekleme gerekebilir.'

  - alert: DiskIOHigh
    expr: rate(node_disk_io_time_seconds_total[5m]) > 0.6
    for: 15m
    labels:
      severity: warning
    annotations:
      summary: 'Disk I/O baskısı ({{ $labels.instance }})'
      description: 'Son 15 dakikada disk meşguliyet oranı yüksek. Sorgular, indeksler veya yedekleme trafiğini kontrol edin.'

Disk I/O yüksekse veritabanı sorguları, indeksler ya da eş zamanlı backup işleri ilk şüpheliler. İpuçları arıyorsanız, veritabanı tarafı için InnoDB tuning ve yavaş sorgu analizi yazısı, pratik bir el feneri gibi.

Uptime: Ayağa Kalk, Sunucu Düşmüş!

En basit uptime kuralı ‘up’ metriğidir. Prometheus, hedefe erişemezse ‘up’ 0 olur. Bu, sunucu gerçekten ulaşılmaz olduğunda vurucu bir işaret.

# rules/uptime.yml
groups:
- name: uptime-alerts
  rules:
  - alert: NodeDown
    expr: up{job='node'} == 0
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: 'Uptime sorunu ({{ $labels.instance }})'
      description: 'Prometheus hedefe 1 dakikadır ulaşamıyor. VPS kapalı olabilir veya network kesintisi yaşanıyor.'

İsterseniz uygulama katmanı için dışarıdan HTTP kontrolü de ekleyebilirsiniz (Blackbox Exporter ile). Ama çekirdek izleme için bu kural çoğu zaman ilk haberi verir. Eğer yüksek erişilebilirlik planlarınız varsa, Anycast DNS ve otomatik failover ile kesintisiz kalma yazısına göz atmanızı öneririm.

Grafana: Veriyi Hikayeye Dönüştürmek

Pano Mantığı: Önce Duygu, Sonra Detay

Pano düzenlerken ben üç katmanlı bir yaklaşımı seviyorum. En üstte ‘nabız’ panosu: CPU, RAM, disk ve uptime özetleri. Orta katta ‘neden’ sorusunu aydınlatan detay panolar: çekirdek başına CPU, process bazlı bellek tüketimi, disk IOPS. En altta ise derin dalış: belirli bir servis veya port üzerinden trafik detayları.

Grafana kurulumunda ilk iş, Prometheus’u veri kaynağı olarak eklemek. Ardından hazır panolardan birini içe aktarabilir ya da kendiniz sıfırdan çizim yapabilirsiniz. Başlangıç için resmi dökümana göz atmak iyi olur: Grafana ile panoları yönetme ve alarmlar.

Basit Sorgularla Başlayın

– CPU ortalaması: avg by (instance) (rate(node_cpu_seconds_total{mode!=’idle’}[5m]))

– RAM kullanılabilirlik: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes

– Disk meşguliyet: rate(node_disk_io_time_seconds_total[5m])

– Uptime: up{job=’node’}

Renkleri, eşik çizgilerini ve anotasyonları abartmadan koyun. Ne kadar sade olursa, ‘aha’ anı o kadar hızlı geliyor. Grafana’nın kendi alarm sistemini de panel bazında kullanabilirsiniz; kritik noktalarda çift koruma güzel hissettirir.

Gürültüyü Azaltmak: İyi Alarm Stratejisinin Sırları

‘for’ Süresi ve Histerezis

En sık yapılan hata, eşik değeri aşılır aşılmaz alarm göndermek. Kısa sıçramalar işin doğasında var. Bunun yerine alarmlarda ‘for’ kullanın. CPU’da 10 dakika, RAM’de 5 dakika, disk I/O’da 15 dakika gibi. Bu, huzur verir.

Gruplama ve Tekrarlama Aralıkları

Alertmanager tarafında benzer alarmları gruplamak sakinleştirir. Tekrarlama aralığını da makul tutun. Aksi halde bir kesinti esnasında telefonunuz susmaz. Grup bazlı ‘summary’ ve açıklamalar, ekip arkadaşlarının ne olduğunu anlamasını hızlandırır.

Bakım Zamanları ve Sessizleştirme

Planlı bakım yapıyorsanız ‘silence’ kuralı hayat kurtarır. 2 saatlik bir pencere açıp ilgili etiketlere göre (örneğin instance) sessizleştirin. Sonra tekrar eski haline döner. İşte bu kadar.

Doğru Eşikler: İşinize Göre Ayarlayın

Herkese uyan tek bir eşik yok. Trafiğinizin normalini birkaç gün izleyin, sonra eşikleri buna göre belirleyin. Kaynak planlaması tarafında kararsızsanız, vCPU, RAM ve IOPS için kapasite planlama rehberi kafanızdaki soru işaretlerini güzelce topluyor.

Güvenlik: Metrikler Herkese Açık Olmasın

Node Exporter portunu internetin tamamına açmak yerine, sadece Prometheus’un bulunduğu ağdan erişime izin verin. Güvenlik grubu, firewall veya VPN ile sınırlandırın. İsterseniz reverse proxy üzerinden basic auth da koyabilirsiniz, ama en temizi ağ seviyesinde kapatmak.

Prometheus ve Grafana için de admin arayüzlerini tahmin edilmesi zor portlara, güvenilir IP’lere ve güçlü parolalara emanet edin. Grafana kullanıcılarını rollerle ayırmak, yanlışlıkla yapılan değişikliklerin önüne geçer.

Docker Compose ile Hızlı Kurulum (İsteğe Bağlı)

İsterseniz her şeyi bir arada, tek bir docker-compose ile ayağa kaldırabilirsiniz. Aşağıda basit bir iskelet var. Üretim ortamında hacim, yedek, şifre gibi detayları sıkılaştırın.

version: '3.8'
services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus:/etc/prometheus
      - promdata:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--web.enable-lifecycle'
    ports:
      - '9090:9090'

  alertmanager:
    image: prom/alertmanager:latest
    volumes:
      - ./alertmanager:/etc/alertmanager
    command:
      - '--config.file=/etc/alertmanager/alertmanager.yml'
    ports:
      - '9093:9093'

  grafana:
    image: grafana/grafana:latest
    ports:
      - '3000:3000'
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=strongpass
    volumes:
      - grafdata:/var/lib/grafana

  node-exporter:
    image: prom/node-exporter:latest
    pid: 'host'
    network_mode: 'host'
    restart: unless-stopped
    command:
      - '--path.rootfs=/host'
    volumes:
      - '/:/host:ro,rslave'

volumes:
  promdata: {}
  grafdata: {}

Bu yaklaşım, tek VPS üzerinde hızlıca denemek için ideal. Zamanla rol ayrımı yapıp Prometheus’u farklı bir sunucuya taşımak, disk I/O baskısını hafifletebilir.

Gerçek Hayattan Küçük Dersler

– Fazla alarm, alarmı değersizleştirir. Az ama isabetli olsun.

– Panoyu karmaşık hale getirmeyin. Önce özet, sonra detay. Böylece kim bakarsa baksın aynı hikayeyi okur.

– Disk doluluk alarmları için eşiklerin altına ‘temizlik görevi’ tanımlamak iyi fikir. Log rotasyonu, eski yedeklerin kaldırılması gibi ufak otomasyonlar büyük rahatlık veriyor. Yedeklemeyi ciddiye alıyorsanız, 3-2-1 yedekleme stratejisi anlatısı akılda kalıcı.

– Prometheus ve Alertmanager versiyonlarını çok arkada bırakmayın. Küçük iyileştirmeler bile gecikme ve stabilite tarafında fark yaratıyor. Resmi sürüm notlarını ara ara okumak faydalı: Node Exporter sürümleri ve kurulum notları.

– Trafiğiniz büyüdükçe, iş tarafındaki göstergeleri de izlemeye ekleyin: sepet tamamlama oranı, sipariş hata oranı, istek süresi. Teknik metrikler sağlıklıysa ama kullanıcı şikayet ediyorsa, hikayenin eksik bir sayfası var demektir.

Performansı Destekleyen Yan Notlar

İzleme bazen bir sorunu çözmez, sadece aydınlatır. Çözüm için altyapıda birkaç iyilik yapmak gerekir. Trafikte ani sıçramalar yaşıyorsanız ve CPU’yu korumak istiyorsanız, web katmanında akıllı önbellekleme ve bot koruması çok iş görür. Bu konuda, Cloudflare WAF kuralları ve oran sınırlama ile botları dizginlemek iyi bir başlangıç fikri sunuyor. Bir de, uygulama güncellemeleri veya veritabanı migrasyonlarında kesinti olmadan ilerlemek istiyorsanız, DNS TTL stratejileriyle taşıma yazısı pratik bir rehber gibi.

Baseline ve Kapasite: Ne Zaman Ölçeklemeli?

İzleme veriniz birkaç haftayı bulunca, elinizde altın gibi bir referans oluşur: normalin grafiği. CPU %70-75 bandında uzun kalıyorsa, RAM uyarıları sıklaşıyorsa ve disk I/O sürekli yüksekse ölçekleme zamanı yaklaşmış olabilir. Tek bir dev makine yerine, işi bölen bir yaklaşım bazen daha rahat çalışır. Ama tercihi netleştirmeden önce metriklerinize bakın; onlar zaten gerekeni söylüyor olacak.

Uygulamanız WooCommerce, Laravel ya da Node.js tabanlıysa ve karar vermekte zorlanıyorsanız, şu derli toplu anlatım iş görür: Doğru VPS kaynaklarını seçme rehberi. İzleme sonuçlarınızı bu rehberle birlikte okuyunca, hangi düğmeye ne kadar basmanız gerektiği netleşir.

Kapanış: Sessizliği Anlamlı Kılmak

Bir gece CPU tavan yapar, başka bir gün RAM bıçak sırtı kalır, bazen de disk fark ettirmeden yorulur. İzleme sistemi kurmak, bu sessiz değişimi anlaşılır bir hikayeye çevirmek demek. Prometheus veriyi toplar, Grafana görsel bir dille anlatır, Node Exporter da kulak verir. Birkaç sade kural yazıp, alarmlara makul bekleme süreleri koyduğunuzda, ekranlarınız kırmızıya boyanmadan önce tedbir alırsınız.

Pratik tavsiyem şu: Küçükten başlayın. Tek VPS’de Node Exporter ve Prometheus ile bir tur dönün, Grafana’da bir ‘nabız’ panosu kurun, iki üç anlamlı alarm yazın. Sonra Alertmanager ile bildirimi ekleyin. İlk uyarıyı aldığınızda ne bekleyeceğinizi bilmek, en az uyarının kendisi kadar önemli. Umarım bu rehber, kendi sisteminizi güvenle izlemenin yolunu açmıştır. Sorularınız olursa, not alın, deneyin, tekrar gelin; bir sonraki yazıda daha derine dalarız. Şimdilik hoşça kalın.