VPS’te Prometheus ve Grafana ile İzleme

VPS'te Prometheus ve Grafana kurulumu için Prometheus metrikleri toplar, Node Exporter Linux kaynaklarını sunar ve Grafana bunları grafiklerle gösterir. Güvenli bir kurulumda 9090, 3000 ve 9100 portları herkese açılmaz; servisler ayrı kullanıcılarla çalışır, disk saklama sınırı belirlenir ve alarm bildirimleri gerçek bir testle doğrulanır.

Prometheus ve Grafana ne işe yarar?

Bir VPS’in SSH bağlantısının açık kalması, sağlıklı çalıştığı anlamına gelmez. Disk dolabilir, RAM tükenebilir veya Nginx gelen istekleri karşılayamayacak kadar yoğunlaşabilir. Prometheus metrikleri zaman serisi olarak toplar; Grafana bu verileri grafik, panel ve alarm kurallarına dönüştürür. Sağlam bir izleme düzeni yalnızca CPU yüzdesini göstermez, değişimin ne zaman başladığını da ortaya çıkarır.

Prometheus, HTTP üzerinden metrikleri çeken ve bunları kendi zaman serisi veritabanında saklayan bir izleme sunucusudur. Grafana doğrudan sistem ölçmez; Prometheus gibi bir veri kaynağına bağlanarak sorgu sonuçlarını görselleştirir. Küçük bir VPS ortamında temel mimari şöyledir:

• Prometheus: Metrikleri toplar, saklar ve PromQL ile sorgular.
• Node Exporter: Linux çekirdeği ve sistem kaynaklarını metrik olarak sunar.
• Grafana: Panelleri ve uyarıları gösterir.
• systemd: Servislerin açılışta başlamasını ve çalışırken yönetilmesini sağlar.

Prometheus’un temel çalışma modeli pull yaklaşımıdır: Prometheus belirli aralıklarla hedefteki /metrics uç noktasını sorgular. Bu ayrıntı, güvenlik duvarında yalnızca gerekli erişimi açmak ve hedeflerin gerçekten erişilebilir olduğunu doğrulamak açısından önemlidir.

Ne yapılmalı – İzleme tasarımında CPU, RAM, disk, ağ, servis erişilebilirliği ve alarm teslimini ayrı ayrı planlayın.

Kurulumdan önce VPS kaynakları nasıl planlanır?

Tek VPS üzerinde Prometheus, Grafana ve Node Exporter çalıştırmak küçük ortamlar için mümkündür. Kaynak ihtiyacı hedef sayısına, scrape aralığına, saklama süresine ve metrik kardinalitesine bağlıdır. Tek bir Linux VPS’ini izlemek için ağır bir küme gerekmez; ölçüm verisini de sıradan bir log gibi sınırsız bırakmamak gerekir.

Prometheus’un disk tüketimi; örnek sayısı, etiket sayısı ve saklama süresiyle büyür. Her beş saniyede veri toplamak daha ayrıntılı grafik sağlayabilir, ancak gereksiz örnek yükü oluşturur. Başlangıç için 15 veya 30 saniyelik scrape_interval çoğu VPS uygulamasında yeterlidir. Disk kullanımını hesaplarken Prometheus’un kendi veri dizinini de hesaba katın.

Ubuntu 22.04 veya 24.04 gibi desteklenen bir dağıtım, ayrı bir izleme VPS’i ve güncel paketlerle daha temiz bir başlangıç sağlar. İzleme sunucusu izlediği makineyle aynı VPS’teyse, makine tamamen çöktüğünde alarmı da göremezsiniz. Kritik sistemlerde Prometheus ve Grafana’yı farklı bir VPS’te tutmak daha güvenlidir.

Sunucunuzda işlem ve bellek tüketimini ilk kontrolden geçirmek için Linux’ta İşlem Yönetimi: ps, top ve kill Kullanımı başlığındaki temel komutlardan yararlanabilirsiniz. Grafana’nın veritabanı, eklenti ve panel sayısı arttıkça bellek ihtiyacı da yükselir.

Ne yapılmalı – İzleme bileşenlerini mümkünse izlenen uygulamadan ayrı bir VPS’e yerleştirin ve veri saklama süresini kurulumdan önce belirleyin.

Prometheus Grafana kurulumu hangi adımlarla yapılır?

Aşağıdaki örnek Debian veya Ubuntu üzerinde ayrı kullanıcılarla çalışan binary kurulumunu gösterir. Dağıtım deposundaki sürüm eski olabilir; üretimde sürümü Prometheus ve Grafana’nın resmi indirme sayfalarından kontrol edin. Buradaki Prometheus 2.55.1 ve Node Exporter 1.8.2 değerleri örnek kurulum sürümleridir; kurulum gününde yayımlanan sürümü ve SHA256 değerini doğrulayın.

Prometheus kullanıcısını ve dizinlerini oluşturma

sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus
sudo mkdir -p /etc/prometheus /var/lib/prometheus
sudo chown prometheus:prometheus /var/lib/prometheus

Prometheus’un yapılandırması /etc/prometheus/prometheus.yml, zaman serisi verisi ise /var/lib/prometheus altında tutulabilir. Servisi root olarak çalıştırmamak, bir süreç açığından sonra yetki alanını daraltır.

Prometheus binary dosyasını yerleştirme

cd /tmp
curl -LO https://github.com/prometheus/prometheus/releases/download/v2.55.1/prometheus-2.55.1.linux-amd64.tar.gz
tar xzf prometheus-2.55.1.linux-amd64.tar.gz
sudo cp prometheus-2.55.1.linux-amd64/prometheus /usr/local/bin/
sudo cp prometheus-2.55.1.linux-amd64/promtool /usr/local/bin/
sudo cp -r prometheus-2.55.1.linux-amd64/consoles /etc/prometheus/
sudo cp -r prometheus-2.55.1.linux-amd64/console_libraries /etc/prometheus/
sudo chown -R prometheus:prometheus /etc/prometheus

Üretimde arşivin SHA256 değerini resmi sürüm sayfasındaki değerle karşılaştırın. HTTPS üzerinden indirmek bağlantıyı korur; dosyanın bütünlüğünü tek başına kanıtlamaz.

Temel yapılandırmayı yazma

sudo vim /etc/prometheus/prometheus.yml

global:
  scrape_interval: 15s
  evaluation_interval: 15s

rule_files:
  - /etc/prometheus/alerts.yml

scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets: ['127.0.0.1:9090']

  - job_name: node
    static_configs:
      - targets: ['127.0.0.1:9100']

Buradaki job_name ve instance etiketleri daha sonra PromQL sorgularında kullanılır. Prometheus yapılandırmasını servisi başlatmadan önce promtool ile kontrol edin:

sudo -u prometheus promtool check config /etc/prometheus/prometheus.yml

Geçerli bir dosyada SUCCESS mesajı görürsünüz. Girinti hatası veya tanınmayan alan varsa servis başlatılmadan önce düzeltilmelidir.

Node Exporter VPS metriklerini nasıl toplar?

Node Exporter; CPU, bellek, dosya sistemi, ağ ve yük gibi Linux sistem metriklerini Prometheus’un okuyabileceği biçimde sunar. Temel akış, exporter servisinin çalıştırılması ve Prometheus’un 9100 portundan scrape etmesidir.

sudo useradd --no-create-home --shell /usr/sbin/nologin 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 xzf 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

Servis tanımını oluşturun:

sudo vim /etc/systemd/system/node_exporter.service

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

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

[Install]
WantedBy=multi-user.target

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

Çıktıda # HELP ve # TYPE satırlarıyla başlayan metrik açıklamaları görünür. Bu endpoint internete açık bırakılmamalıdır. Node Exporter’ın 9100 portuna yalnızca Prometheus sunucusunun erişmesine izin veren bir firewall kuralı yeterlidir.

Web sunucusu da izlenecekse Nginx kurulumu ve ilk yapılandırma adımlarından sonra Nginx exporter veya uygun bir metrics modülü ayrıca planlanmalıdır. Node Exporter, Nginx’in istek sayısı ve upstream gecikmesi gibi uygulamaya özgü metriklerini kendiliğinden sağlamaz.

Ne yapılmalı – Node Exporter’ı ayrı kullanıcıyla çalıştırın ve 9100/TCP portunu yalnızca Prometheus sunucusuna açın.

Prometheus servisi ve erişim güvenliği

Prometheus için systemd servis dosyası oluşturun:

sudo vim /etc/systemd/system/prometheus.service

[Unit]
Description=Prometheus
Wants=network-online.target
After=network-online.target

[Service]
User=prometheus
Group=prometheus
Type=simple
ExecStart=/usr/local/bin/prometheus \
  --config.file=/etc/prometheus/prometheus.yml \
  --storage.tsdb.path=/var/lib/prometheus \
  --web.listen-address=127.0.0.1:9090 \
  --storage.tsdb.retention.time=15d \
  --storage.tsdb.retention.size=20GB

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now prometheus
sudo systemctl status prometheus --no-pager
curl -s http://127.0.0.1:9090/-/ready

/-/ready isteğinin HTTP 200 döndürmesi Prometheus’un sorgu kabul etmeye hazır olduğunu gösterir. Servis başlamazsa doğrudan yeniden başlatmak yerine journalctl -u prometheus -n 50 --no-pager çıktısını okuyun. Yanlış dosya yolu, sahiplik veya YAML sözdizimi genellikle burada görünür.

Grafana’nın resmi Debian kurulumunda imzalı paket deposu veya dağıtım paketi kullanılabilir. Kurulumdan sonra servisi etkinleştirin:

sudo systemctl enable --now grafana-server
sudo systemctl status grafana-server --no-pager

Grafana’nın 3000 portunu doğrudan internete açmak yerine Nginx reverse proxy, HTTPS ve erişim kısıtlaması kullanın. Nginx kullanıyorsanız domain, URL ve proxy başlıklarını ayrıca doğrulayın; erişim problemi her zaman Grafana servisinin kapalı olduğu anlamına gelmez.

Prometheus’u 127.0.0.1:9090 üzerinde dinletmek, web arayüzünü dış ağa kapatır. Grafana farklı bir VPS’teyse Prometheus’un dinleme adresi, firewall ve TLS gereksinimleri yeniden tasarlanmalıdır. Yönetim portlarını yalnızca SSH tüneli veya WireGuard üzerinden erişilebilir yapmak çoğu küçük ortamda daha düşük risklidir.

Ne yapılmalı – Prometheus ve Grafana portlarını herkese açmadan önce reverse proxy, firewall ve erişim kaynağını birlikte belirleyin.

Grafana’da veri kaynağı ve dashboard nasıl eklenir?

Grafana arayüzüne ilk girişten sonra Connections veya sürüme göre Data sources bölümünden Prometheus’u ekleyin. Aynı VPS üzerindeki kurulumda URL olarak http://127.0.0.1:9090 kullanılabilir. Grafana konteynerde, Prometheus host üzerinde çalışıyorsa 127.0.0.1 konteyneri ifade eder; bu durumda servis adı veya erişilebilir host adresi gerekir.

Bağlantıyı Save & test ile sınayın. Başarılı bağlantıdan sonra Explore ekranında şu PromQL sorgularını deneyin:

up
node_memory_MemAvailable_bytes
rate(node_cpu_seconds_total{mode="idle"}[5m])
100 - (node_filesystem_avail_bytes{mountpoint="/"} * 100 / node_filesystem_size_bytes{mountpoint="/"})

up değeri 1 ise hedef son scrape işleminde erişilebilir, 0 ise erişim veya exporter sorunu vardır. CPU sorgusu çekirdek başına idle oranını verir; toplam kullanım için sorgunun matematiksel biçimi ve panel birimi doğru ayarlanmalıdır. Disk sorgusunda geçici dosya sistemlerini filtrelemek gerekebilir.

Hazır dashboard içe aktarmak hızlıdır, fakat rastgele bir JSON dosyasına güvenmeyin. Dashboard’un kullandığı metrik adlarını, değişkenleri ve sorguları inceleyin. Prometheus sürümü, Node Exporter sürümü veya etiket isimleri farklıysa grafikler boş görünebilir.

Panel tasarımında tek grafiğe çok fazla seri eklemek yerine önce VPS’in sağlığına odaklanın: CPU kullanım eğilimi, kullanılabilir bellek, root dosya sistemi, ağ trafiği ve up durumu. TTFB’yi milisaniye hassasiyetinde izlemek istiyorsanız önce uygulama ve cache ölçümünün gerçekten kurulu olduğundan emin olun.

Prometheus ile hangi alarmlar kurulmalı?

Grafik görmek ile olaydan haberdar olmak aynı şey değildir. Prometheus alerting rule dosyaları koşulları tanımlar; Alertmanager ise gruplama, susturma ve e-posta, webhook veya başka bildirim kanallarını yönetir. Küçük bir VPS için ilk alarmlar ölçülebilir ve eyleme dönük olmalıdır.

groups:
  - name: vps-health
    rules:
      - alert: InstanceDown
        expr: up{job="node"} == 0
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Node Exporter erişilemiyor"

      - alert: RootFilesystemLow
        expr: 100 * node_filesystem_avail_bytes{mountpoint="/",fstype!="rootfs"} / node_filesystem_size_bytes{mountpoint="/"} < 15
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Root dosya sisteminde boş alan az"

      - alert: HighMemoryPressure
        expr: 100 * (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) > 90
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Kullanılabilir bellek düşük"

Dosya sistemi sorgularında fstype, mountpoint ve device etiketlerini ortamınıza göre daraltın. Aksi halde /run, container bind mount’ları veya sanal dosya sistemleri gereksiz alarm üretebilir. Alarm eşiğini gerçek çalışma desenini gördükten sonra belirlemek, gece boyunca süren sahte alarmları azaltır.

Alarm dosyasını Prometheus’a tanıtmak için rule_files alanını yapılandırın ve kuralları doğrulayın:

sudo -u prometheus promtool check rules /etc/prometheus/alerts.yml
sudo systemctl reload prometheus

Bir alarm tanımlamak yetmez. Bildirimin gerçekten ulaştığını test edin; e-posta, webhook veya telefon uygulamasında teslim bilgisi görünmelidir. İzleme sisteminin kendisi de izlenmelidir. Prometheus servisi durmuşsa Grafana paneli bir süre eski veriyi göstererek sahte güven yaratabilir.

Ne yapılmalı – Her kritik alarm için eşik, bekleme süresi, bildirim kanalı ve müdahale adımını yazılı hale getirin.

İzleme verisi ne kadar süre saklanmalı?

Prometheus varsayılan olarak veriyi yerel TSDB alanında saklar. Saklama süresi ve disk sınırı için servis parametreleri kullanılabilir:

--storage.tsdb.retention.time=15d
--storage.tsdb.retention.size=20GB

Zaman ve boyut sınırlarını birlikte kullanmak daha öngörülebilir bir disk kullanımı sağlar. Boyut sınırı diskin tamamen dolmasını engellemeye yardımcı olur; işletim sistemi, Grafana ve loglar için ayrıca boş alan bırakılmalıdır. Prometheus verisini aynı diskteki yoğun uygulama loglarıyla yarıştırmayın.

Uzun dönem kapasite veya çok sayıda VPS izlenecekse remote write, Thanos veya başka uzun süreli depolama mimarileri değerlendirilebilir. Küçük bir VPS’te önce doğru metrikleri ve alarm akışını oturtmak daha sağlıklıdır. Snapshot almak geri dönüş için yararlı olsa da canlı Prometheus verisinin tek yedeği sayılmaz; VPS Snapshot Nedir? Anlık Yedekleme Rehberi başlığındaki ayrımı dikkate alın.

Prometheus verisinin yedeği alınacaksa servisin veri tutarlılığı, TSDB belgeleri ve geri dönüş prosedürü ayrıca test edilmelidir. Grafana dashboard JSON’ları, provisioning dosyaları, alarm kuralları ve Prometheus yapılandırması da yedeklenmelidir. Yalnızca grafik ekranını yedeklemek izleme sistemini yeniden kurmaya yetmez.

Kurulumdan sonra hangi kontroller yapılır?

Önce hedef durumunu kontrol edin. Prometheus arayüzünde Status > Targets bölümünde Node Exporter hedefi UP görünmelidir. Ardından aynı kontrolü komut satırından yapın:

curl -s http://127.0.0.1:9090/api/v1/targets | jq '.data.activeTargets[] | {instance,health,lastError}'

health alanı up, lastError alanı boşsa scrape başarılıdır. connection refused Node Exporter’ın çalışmadığını veya adresin yanlış olduğunu, context deadline exceeded ise firewall ya da ağ gecikmesini düşündürür.

Grafana’da panel sorgularının zaman aralığını değiştirerek eski verinin geldiğini doğrulayın. Ardından bilerek bir test alarmı üretin veya Alertmanager test mekanizmasını kullanın. Alarmın oluşması, gruplanması ve kapanması ayrı ayrı görülmelidir.

İzleme VPS’inde journalctl -u prometheus, journalctl -u grafana-server ve disk kullanımını düzenli kontrol edin. Bir grafik boşsa servisi yeniden başlatmadan önce hedef listesini, HTTP endpoint’ini, etiketleri ve sorguyu karşılaştırın. Log okumadan restart etmek bazen yalnızca kanıtı siler.

DNS üzerinden Grafana yayınlanacaksa alan adının doğru IP’ye çözüldüğünü dig +short ile kontrol edin. DNS değişikliklerinin etkisini anlamak için DNS Yayılması Nedir? Ne Kadar Sürer? başlığındaki TTL ve resolver ayrımından yararlanabilirsiniz.

Kurulumu Tamamlamadan Önce Şunları Kontrol Edin

• Prometheus ve Grafana'yı ayrı, yetkisiz kullanıcılarla çalıştırın.
• Node Exporter'ın 9100 portunu yalnızca Prometheus sunucusuna açın.
• promtool check config ve promtool check rules komutlarını çalıştırın.
• Prometheus Targets ekranında bütün hedeflerin UP olduğunu doğrulayın.
• Grafana'da CPU, RAM, disk, ağ ve up panellerini test edin.
• Disk saklama süresiyle boyut sınırını birlikte yapılandırın.
• Bir alarm üretip bildirimin gerçekten ulaştığını ve kapandığını doğrulayın.

Sık Sorulan Sorular