[ OK ]Kernel başlatılıyor...
~/im/blog
Beni İşe Alın

Konuşalım

Çözülmesi gereken bir altyapı probleminiz mi var veya projeniz için desteğe mi ihtiyacınız var? Yeni projeler için bana ulaşabilirsiniz.

İletişime geç

Bağlantılar

Beni sosyal medyada ve profesyonel ağlarda bulun.

© 2026 Irfan Miral. Tüm hakları saklıdır.Geliştiren:Irfan Miral
Gizlilik PolitikasıŞartlar & Koşullar
Ana SayfaHizmetlerHakkımda/ÖzgeçmişBlogİletişimAraçlar
2026-10-14• 5 dk okuma süresi

Küçük Bir VPS'i Prometheus ve Grafana İle İzlemek

DevOps Prometheus Grafana Monitoring

Reklam

Sistem izleme (monitoring) genelde tamamen farklı bir ölçekteki operasyonlara aitmiş gibi geldiğinden süresiz olarak ertelenir. İnsanın aklına onlarca sunucu, özel bir operasyon (ops) ekibi ve duvardaki devasa gösterge panelleri (dashboards) gelir.

Müşteriye ait bir uygulamayı çalıştıran tek bir küçük VPS için, "monitoring kurmak" kulağa sadece bir şeyler yavaşladığında SSH atıp htop çalıştırmaya kıyasla inanılmaz bir abartı gibi gelir.

Oysa tek bir sunucu için asıl kurulum son derece küçüktür. Ve "bir şeyler yavaş geldiğinde SSH atıp bakmak" ile "son bir haftanın hassas bir grafiğine bakmak" arasındaki fark, o küçük kurulum çabasının hissettirdiğinden çok ama çok daha büyüktür.

Tek sunucu için gereken parçalar

node_exporter doğrudan sunucunun kendi üzerinde çalışır. CPU, bellek, disk ve ağ kullanımı gibi sistem metriklerini Prometheus'un doğal olarak anlayabileceği bir formatta dışarı sunar (expose):

wget https://github.com/prometheus/node_exporter/releases/download/v1.8.0/node_exporter-1.8.0.linux-amd64.tar.gz
tar xzf node_exporter-*.tar.gz
sudo mv node_exporter-*/node_exporter /usr/local/bin/

Küçük bir systemd servisi onu arka planda sürekli çalışır halde tutar:

# /etc/systemd/system/node_exporter.service
[Unit]
Description=Node Exporter
After=network.target

[Service]
ExecStart=/usr/local/bin/node_exporter
Restart=always

[Install]
WantedBy=multi-user.target

Prometheus'un kendisi, tek sunuculu bir kurulumda tam olarak aynı VPS üzerinde çalışabilir. Alternatif olarak, izlediği sunucunun gerçekten kötü bir gün geçirmesi ihtimaline karşı ayakta kalmasını istiyorsanız, onu ayrı küçük bir monitoring VPS'ine de koyabilirsiniz. Her iki durumda da yapılandırma (config) inanılmaz kısadır:

# prometheus.yml
scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100']

Grafana sadece bir veri kaynağı (data source) olarak Prometheus'a bağlanır ve bu ham metrikleri dashboard'lara dönüştürür. node_exporter için resmi topluluk dashboard'u, sıfırdan tek bir panel bile inşa etmenize gerek kalmadan size anında CPU, bellek, disk ve ağ grafiklerini verir.

Bu size aslında ne kazandırır?

En bariz cevap grafiklerdir. Ancak çok daha kullanışlı olan asıl cevap geçmiş verisidir.

"Sunucu bugün yavaş hissettiriyor" cümlesi, "bellek kullanımı son iki hafta boyunca istikrarlı bir şekilde tırmandı ve şu an sınıra dayanıyor" cümlesine dönüşür. Bu tamamen farklı ve çok daha aksiyon alınabilir bir ifadedir. Yavaş bir bellek sızıntısı (memory leak), yavaş yavaş dolan bir disk veya trafik arttıkça sinsice yükselen yük ortalaması (load average), o anlık çekilmiş tek bir htop görüntüsünde tamamen görünmezdir. Ancak bir haftalık grafikte acı verici derecede nettir.

Uyarı (Alerting) Sistemi: Minimal de olsa kesinlikle yapılması gereken kısım

Dashboard'lar bir insanın aktif olarak onlara bakmasını gerektirir. Alerting ise bir şeyler ters gittiğinde sunucunun aktif olarak size söylemesi demektir. İki veya üç kurallık minimal bir Alertmanager kurulumu bile, küçük bir VPS için gerçekten önemli olan senaryoları sıkıca güvence altına alır:

# alert.rules.yml
groups:
  - name: basic
    rules:
      - alert: DiskSpaceLow
        expr: node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} < 0.10
        for: 30m
        annotations:
          summary: "Disk space below 10% on {{ $labels.instance }}"

      - alert: HighMemoryUsage
        expr: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) > 0.90
        for: 15m
        annotations:
          summary: "Memory usage above 90% on {{ $labels.instance }}"

Sadece bu iki kural bile, "sunucu yavaş yavaş ölüyordu ve kimse fark etmedi" şeklindeki en yaygın iki senaryoyu yakalar. Alertmanager daha sonra bu uyarıyı e-postaya, Slack'e veya bir webhook'a yönlendirebilir—yani dikkatinizi gerçekten çeken şey her neyse oraya.

Daha sonra sistemi büyütmek ekstra hiçbir şeye mal olmaz

Bunu tek bir sunucu için kurmaya değer kılan açık ara en iyi neden, ikinci bir sunucu geldiğinde ana kurulumun hiçbir şekilde değişmemesidir. Sadece bir scrape_configs girdisi ve yeni bir node_exporter kurulumu daha eklenir.

Daha sonra başlatılacak devasa bir "monitoring projesi" yoktur. "Hiçbir izleme yok" aşamasından "her şeyi izliyoruz" aşamasına sancılı bir geçiş (migration) yoktur. Sadece zaten orada olan bir yapılandırma dosyasına bir hedef (target) daha eklersiniz. Bir sunucuyla başlamak, ikinci, üçüncü ve onuncu sunucuların halihazırda mükemmel çalışan bir sisteme pürüzsüzce katılması demektir. Onları baskı ve panik altında böyle bir sistemi sıfırdan kurmak için tetikleyici olarak kullanmak zorunda kalmazsınız.

Reklam

Yardıma mı ihtiyacınız var?

Eğer Sunucu Yönetimi ve Bakımı işini sizin yerinize birinin halletmesini tercih ederseniz, benim asıl işim tam olarak bu.

İletişime Geç
ÖncekiÇoğu Saldırıyı Durduran WordPress Güvenlik TemelleriSonraki Tek Bir Sunucuda Log Yönetimi