Bir VPS yavaşladığında o anki süreç listesi geçmişte ne değiştiğini göstermez. Prometheus ile düzenli metrik toplamak; CPU zamanı, kullanılabilir bellek, dosya sistemi alanı ve disk etkinliğini aynı zaman çizelgesinde incelemenizi sağlar. Alarm kuralları ise tanımladığınız koşul yeterince uzun sürdüğünde inceleme başlatır. İzleme arızayı önlemez ve her sorunu kullanıcıdan önce yakalamayı garanti etmez.
Bu rehber, bir VPS üzerinde Node Exporter 1.12.1, Prometheus 3.15.1 ve Alertmanager 0.34.2 ile yeni, native systemd kurulumu anlatır; Grafana aynı makinede ayrıca kurulur. İsteğe bağlı Docker Compose alternatifi de aşağıda ayrı kurulum yolu olarak verilir. Örnekler 4 Kasım 2026’da kontrol edilen Linux amd64 sürümlerine sabitlenmiştir. Bütün metrik ve yönetim dinleyicileri loopback adresindedir. Hedef adı, sorgu etiketleri ve alarm kuralları kurulum boyunca birbiriyle eşleşir.
Önce ikili dosyalar ve servis hesapları, sonra yapılandırmalar ve kurallar hazırlanır; servisler bütün dosyalar doğrulandıktan sonra başlatılır. Buradaki adres, kapasite ve e-posta değerleri örnektir. Mevcut izleme kurulumunun dosyalarını bu yeni kurulum komutlarıyla ezmeyin; geçiş için yedek, sürüm uyumu ve geri dönüş adımları ayrıca gerekir.
VPS İzlemede Hangi Sinyaller Önemli?
Kaynak kullanımı, gecikme ve kullanıcı etkisi aynı şey değildir. Yüksek CPU boşta olmayan zamanı; düşük MemAvailable olası bellek baskısını; yüksek disk etkinliği ise depolama incelemesi ihtiyacını gösterebilir. Bunları trafik, uygulama hataları ve bakım kayıtlarıyla ilişkilendirin. Tek bir grafik hangi süreç, sorgu veya endpoint’in sorumlu olduğunu açıklamaz.
Node Exporter Linux host metriklerini sunar. Prometheus bunları 15 saniyede bir toplar ve kuralları 15 saniyede bir değerlendirir. Alertmanager firing alarmlarının bildirimlerini yönlendirir; gruplama, bekleme ve sessizleştirme bildirim zamanını değiştirir. Bu örnekte send_resolved açık olduğundan çözülme bildirimleri de gönderilebilir. Grafana aynı veriler için pano sağlar; bu rehberde alarm sahibi Prometheus’tur.
Kapasite planlamasında günlük ve haftalık örüntüleri, trafik başına kaynak ihtiyacını ve değişiklik zamanlarını izleyin. Endpoint yükü, sipariş hatası, kuyruk derinliği veya süreç bazında bellek için uygulama enstrümantasyonu ya da uygun ek exporter gerekir. Node Exporter bu ayrıntıları kendiliğinden üretmez.
Mimari: Tek Host, Yerel Erişim
Örnek aynı host üzerinde çalışır: Prometheus, 127.0.0.1:9100 adresinden Node Exporter’ı tarar; alarmları 127.0.0.1:9093 üzerindeki Alertmanager’a yollar. Native Grafana, 127.0.0.1:9090 üzerinden Prometheus’u sorgular. Ayrı ağ alanı kullanan konteynerlerde localhost farklı hedef gösterir; aşağıdaki Linux Compose alternatifi bu nedenle açıkça host network kullanır.
Bileşenlerin sorumlulukları ve erişim sınırları şöyledir:
Node Exporter: 127.0.0.1:9100 üzerinde CPU, bellek, disk, dosya sistemi ve ağ metrikleri sunar. Varsayılanı tüm arayüzlere açılabileceğinden listen adresi açıkça belirtilir.
Prometheus: Yerel metrikleri çeker, zaman serilerini saklar ve kural koşullarını değerlendirir. 127.0.0.1:9090 yönetim arayüzü yalnız güvenilir yönetim erişimine ayrılır.
Grafana: Prometheus veri kaynağını sorgular. Native kurulumda 127.0.0.1:3000 dinleme adresi, kişisel yönetim hesapları ve uygun roller kullanılır.
Alertmanager: 127.0.0.1:9093 üzerinde alarmları alır; yetkilendirilmiş SMTP hesabıyla e-posta gönderir. Bu tek host örneğinde cluster dinleyicisi kapatılır; yüksek erişilebilirlik sağlandığı iddia edilmez.
VPS tamamen kapandığında aynı VPS üzerindeki Prometheus ve Alertmanager da çalışamaz. Host ve uygulama erişimini bağımsız bir konumdan izlemek için ayrı izleme sunucusu veya uygun blackbox probe gerekir. Başarılı HTTP yanıtı yalnız test edilen noktayı ve kontrol sözleşmesini doğrular; bütün kullanıcı işlemlerinin sağlıklı olduğunu kanıtlamaz.
Node Exporter ve Resmi İkili Dosyaları Kurma
Önkoşullar ve Sahiplik
Ubuntu/Debian tabanlı Linux, systemd, curl, tar, sha256sum ve root yetkisi gerekir. Kaynak tüketimi collector sayısı, seri sayısı ve scrape sıklığına bağlıdır. İkili dosyalar root sahipliğinde kalır; servis hesabının kendi executable dosyasını değiştirmesine izin verilmez. Prometheus ve Alertmanager yalnız kendi veri dizinlerine yazar.
Linux amd64 İçin Doğrulanmış İndirmeler
Komutlar yeni kurulumda root Bash kabuğu içindir; sudo kullanıyorsanız önce sudo -i ile geçin. uname -m sonucu x86_64 olmalıdır. ARM64 için uygun paket ve o paketin doğrulanmış SHA256 değeri gerekir. Aşağıdaki digestler yalnız belirtilen sürüm ve mimari içindir. Dosyayı indirip hash kontrolü geçmeden executable kurmayın. Burada servisler henüz başlatılmaz.
set -eu
workdir=$(mktemp -d /tmp/vps-monitoring.XXXXXX)
cd "$workdir"
curl --fail --location --proto =https --tlsv1.2 -o node_exporter-1.12.1.linux-amd64.tar.gz https://github.com/prometheus/node_exporter/releases/download/v1.12.1/node_exporter-1.12.1.linux-amd64.tar.gz
printf '%s %s\n' 'b51d8a76aa2a9156a55d501aca6276fae09e262259a5e4e831d2c2222f084e63' 'node_exporter-1.12.1.linux-amd64.tar.gz' | sha256sum --check -
tar -xzf node_exporter-1.12.1.linux-amd64.tar.gz
install -o root -g root -m 0755 node_exporter-1.12.1.linux-amd64/node_exporter /usr/local/bin/node_exporter
curl --fail --location --proto =https --tlsv1.2 -o prometheus-3.15.1.linux-amd64.tar.gz https://github.com/prometheus/prometheus/releases/download/v3.15.1/prometheus-3.15.1.linux-amd64.tar.gz
printf '%s %s\n' '6a726885328ad9efebbf36e876ce2fb6225468a71fd1e7ce3ba666d5f4d97a84' 'prometheus-3.15.1.linux-amd64.tar.gz' | sha256sum --check -
tar -xzf prometheus-3.15.1.linux-amd64.tar.gz
install -o root -g root -m 0755 prometheus-3.15.1.linux-amd64/prometheus /usr/local/bin/prometheus
install -o root -g root -m 0755 prometheus-3.15.1.linux-amd64/promtool /usr/local/bin/promtool
curl --fail --location --proto =https --tlsv1.2 -o alertmanager-0.34.2.linux-amd64.tar.gz https://github.com/prometheus/alertmanager/releases/download/v0.34.2/alertmanager-0.34.2.linux-amd64.tar.gz
printf '%s %s\n' '17ee14acd0f6ba6e25a436ff223d9c17ddd5cf484f543ad12f0932eaa89ba186' 'alertmanager-0.34.2.linux-amd64.tar.gz' | sha256sum --check -
tar -xzf alertmanager-0.34.2.linux-amd64.tar.gz
install -o root -g root -m 0755 alertmanager-0.34.2.linux-amd64/alertmanager /usr/local/bin/alertmanager
install -o root -g root -m 0755 alertmanager-0.34.2.linux-amd64/amtool /usr/local/bin/amtool
useradd --system --no-create-home --shell /usr/sbin/nologin nodeexp
useradd --system --no-create-home --shell /usr/sbin/nologin prometheus
useradd --system --no-create-home --shell /usr/sbin/nologin alertmanager
install -d -o root -g nodeexp -m 0750 /var/lib/node_exporter /var/lib/node_exporter/textfile
install -d -o root -g prometheus -m 0750 /etc/prometheus /etc/prometheus/rules
install -d -o prometheus -g prometheus -m 0700 /var/lib/prometheus
install -d -o root -g alertmanager -m 0750 /etc/alertmanager
install -d -o alertmanager -g alertmanager -m 0700 /var/lib/alertmanager
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 --web.listen-address=127.0.0.1:9100 --collector.textfile.directory=/var/lib/node_exporter/textfile
Restart=on-failure
RestartSec=5s
UMask=0027
NoNewPrivileges=true
[Install]
WantedBy=multi-user.target
EOF
node_exporter.service içinde varsayılan filesystem hariç tutma kuralları korunur; eski ignored-mount-points bayrağı kullanılmaz. Özel filtre gerektiğinde güncel –collector.filesystem.mount-points-exclude bayrağıyla gerçek mountları kontrol edin. Textfile dizini root sahipliğinde ve nodeexp tarafından okunabilirdir; exporter’a yazma yetkisi verilmez. Başlatma adımından sonra http://127.0.0.1:9100/metrics adresini yerelden kontrol edin.
Prometheus ve Alertmanager Yapılandırması
Prometheus Hedefi, Kural Dosyaları ve Servisi
Aşağıdaki komutlar Prometheus yapılandırmasını ve systemd unit dosyasını oluşturur. job=”node” ve instance=”vps-01″ bütün sorgu ve kurallarda tutarlıdır; adı değiştirirseniz beklenen hedefin yokluk kuralını da güncelleyin. Prometheus, Alertmanager adresini alerting.alertmanagers üzerinden açıkça öğrenir. Kuralları sonraki bölümde oluşturana kadar servisi başlatmayın.
cat > /etc/prometheus/prometheus.yml <<'EOF'
global:
scrape_interval: 15s
evaluation_interval: 15s
rule_files:
- /etc/prometheus/rules/*.yml
alerting:
alertmanagers:
- static_configs:
- targets:
- 127.0.0.1:9093
scrape_configs:
- job_name: prometheus
static_configs:
- targets:
- 127.0.0.1:9090
- job_name: node
static_configs:
- targets:
- 127.0.0.1:9100
labels:
instance: vps-01
EOF
cat > /etc/systemd/system/prometheus.service <<'EOF'
[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=2GB
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=5s
UMask=0027
NoNewPrivileges=true
[Install]
WantedBy=multi-user.target
EOF
Serviste 15 gün ve 2 GB blok saklama sınırı birlikte verilmiştir; önce ulaşılana göre eski bloklar silinir. 2 GB toplam disk tüketimine kesin üst sınır değildir: WAL, head ve compaction için ek alan gerekir. Bu değer yalnız küçük test başlangıcıdır; ölçülen veri hacmine göre kapasite ayırın ve doluluğu izleyin. Prometheus genel bakış belgesi toplama ve saklama modelini açıklar. Yerel TSDB tek düğümlüdür; replikasyon veya yedek yerine geçmez.
Alertmanager Servisi ve SMTP Bildirimi
Önce gerçek alıcı, gönderen, SMTP sunucusu ve kullanıcı adını belirleyin. Hesabın SMTP yetkisi, STARTTLS desteği, geçerli sertifika ve dışarıya 587 erişimi gerekir; örnek example.com değerleri teslim yapmaz. Parolayı güvenli bir yerel editörle /etc/alertmanager/smtp-password dosyasına kaydedin; root:alertmanager sahipliği ve 0640 izni verin. Parolayı komut satırına, yazıya veya sürüm kontrolüne koymayın. Aşağıdaki dosyalar erişimi sınırlandırılmış yapılandırma dizininde tutulur.
cat > /etc/alertmanager/alertmanager.yml <<'EOF'
route:
receiver: mail
group_by:
- alertname
- instance
group_wait: 30s
group_interval: 5m
repeat_interval: 2h
receivers:
- name: mail
email_configs:
- to: alerts@example.com
from: monitoring@example.com
smarthost: smtp.example.com:587
auth_username: monitoring@example.com
auth_password_file: /etc/alertmanager/smtp-password
require_tls: true
send_resolved: true
EOF
cat > /etc/systemd/system/alertmanager.service <<'EOF'
[Unit]
Description=alertmanager
Wants=network-online.target
After=network-online.target
[Service]
User=alertmanager
Group=alertmanager
Type=simple
ExecStart=/usr/local/bin/alertmanager --config.file=/etc/alertmanager/alertmanager.yml --storage.path=/var/lib/alertmanager --web.listen-address=127.0.0.1:9093 --cluster.listen-address=
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=5s
UMask=0027
NoNewPrivileges=true
[Install]
WantedBy=multi-user.target
EOF
Bu alıcı warning, critical ve info seviyelerini aynı e-posta adresine yollar; seviye etiketleri kendiliğinden farklı nöbet kanalı oluşturmaz. Ayrı yönlendirme gerekiyorsa alt route tanımlayıp test edin. Grafana’da aynı koşullar için ikinci alarm seti açmak mükerrer bildirim üretebilir. İlk kurulumda Prometheus → Alertmanager → SMTP zincirini tek alarm sahibiyle doğrulayın.
Prometheus Alarm Kuralları
Aşağıdaki dört YAML dosyasını belirtilen adlarla /etc/prometheus/rules dizinine kaydedin. Her dosya groups → name → rules yapısını taşır; tek başına bir alarm listesi geçerli dosya değildir. Örnek eşikler evrensel sınırlar değildir. Her alarm için sorumlu kişi, inceleme adımı ve kabul edilen bildirim gecikmesi belirleyin.
CPU: Boşta Olmayan Zamanın Oranı
Host CPU hesabı, çekirdek başına idle sayacının beş dakikalık hızının ortalamasını 1’den çıkarır. Non-idle modları birlikte ortalamak aynı oranı vermez; process_cpu_seconds_total ise exporter sürecini ölçer. Bu idle tamamlayıcısı iowait ve steal değerlerini de kapsar; yalnız uygulamanın gerçekten çalıştığı zaman veya kesin doygunluk yüzdesi değildir.
# /etc/prometheus/rules/cpu.yml
groups:
- name: vps-cpu
rules:
- alert: CPUHighSustained
expr: (1 - avg by (instance) (rate(node_cpu_seconds_total{job="node",mode="idle"}[5m]))) > 0.85
for: 10m
labels:
severity: warning
annotations:
summary: High non-idle CPU ({{ $labels.instance }})
description: Non-idle CPU ratio remains above 85%. Check modes and workload; this includes iowait and steal.
Beş dakika rate penceresi, on dakika ise for bekleme süresidir. Koşul aynı etiket kümesi için her değerlendirmede doğru kalırsa firing olur; arada düşerse pending sıfırlanır. Yeni başlayan veya eksik örnekli serilerde rate ekstrapolasyonu ilk değerleri etkileyebilir; başlangıç verisini tam pencereyle aynı güvenle yorumlamayın. Bildirim zamanı ayrıca scrape, evaluation ve Alertmanager grup beklemesine bağlıdır.
Bellek: MemAvailable ve Baskı Belirtileri
MemAvailable, yeni uygulamalar için swap kullanmadan ayrılabileceği tahmin edilen bellektir; geri kazanılabilir cache/slab ve kernel eşikleri hesaba katılır. Kullanılabilir oran yüzde 10 altında beş dakika kalırsa aşağıdaki kural uyarır. Bu, bellek sızıntısını veya yakın çöküşü kanıtlamaz; swap, OOM kayıtları, süreç/cgroup sınırları ve iş yükü birlikte incelenir.
# /etc/prometheus/rules/memory.yml
groups:
- name: vps-memory
rules:
- alert: MemoryLow
expr: (node_memory_MemAvailable_bytes{job="node"} / node_memory_MemTotal_bytes{job="node"}) < 0.10
for: 5m
labels:
severity: warning
annotations:
summary: Low available memory ({{ $labels.instance }})
description: Available memory remains below 10%; inspect workload, swap and limits before diagnosing a leak.
Önbelleği rastgele kapatmak veya temizlemek bellek grafiğini düzeltirken uygulamayı yavaşlatabilir. Hangi katmanın baskı yarattığını belirledikten sonra kapasite ve cache politikasını değerlendirin. WordPress ve WooCommerce CDN önbellek kuralları web katmanı için ayrı bir inceleme konusudur; bu host alarmı hangi cache kuralının doğru olduğunu söylemez.
Disk Alanı, Cihaz Etkinliği ve CPU Iowait
DiskSpaceLow yalnız yazılabilir, boyutu sıfırdan büyük ve seçilen filesystem türlerindeki kullanılabilir alanı değerlendirir. Salt okunur veya dışlanan dosya sistemleri için ayrı sağlık kontrolü gerekir; ayrıca inode ve mutlak boş bayt izleyin. DiskBusyHigh cihazın I/O etkinlik zamanını, CPUWaitingForIO ise kernel’in CPU iowait hesabını izler. Bunlar farklı ölçümlerdir.
# /etc/prometheus/rules/disk.yml
groups:
- name: vps-disk
rules:
- alert: DiskSpaceLow
expr: ((node_filesystem_avail_bytes{job="node",fstype!~"tmpfs|overlay|squashfs"} / node_filesystem_size_bytes{job="node",fstype!~"tmpfs|overlay|squashfs"})
and (node_filesystem_size_bytes{job="node"} > 0) and (node_filesystem_readonly{job="node"} == 0)) < 0.10
for: 10m
labels:
severity: critical
annotations:
summary: Low filesystem space ({{ $labels.instance }} {{ $labels.mountpoint }})
description: Available space on a writable nonzero filesystem remains below 10%. Check bytes, inodes and growth;
preserve required data.
- alert: DiskBusyHigh
expr: rate(node_disk_io_time_seconds_total{job="node"}[5m]) > 0.60
for: 15m
labels:
severity: warning
annotations:
summary: High device busy-time ratio ({{ $labels.instance }} {{ $labels.device }})
description: Busy-time ratio remains above 60%; correlate latency and queueing. This is not a universal saturation
percentage.
- alert: CPUWaitingForIO
expr: avg by (instance) (rate(node_cpu_seconds_total{job="node",mode="iowait"}[5m])) > 0.20
for: 10m
labels:
severity: warning
annotations:
summary: High reported CPU iowait ({{ $labels.instance }})
description: Reported CPU iowait remains above 20%; inspect storage latency and workload. Kernel accounting
has limitations.
Modern paralel depolamada busy-time oranı tek başına kapasite doygunluğu veya gecikme yüzdesi değildir; kernel muhasebesinin de sınırları vardır. Iowait için de benzer dikkat gerekir. Cihaz başına gecikme, IOPS, aktarım hızı ve kuyruk davranışını inceleyin; fiziksel/virtual cihaz ile mount ilişkisini doğrulayın. InnoDB ve yavaş sorgu incelemesi ancak veritabanı yüküyle zaman ilişkisi kurulduktan sonra olası sonraki adımdır.
Scrape Hatası, Eksik Hedef ve Son Açılış
up=0 son scrape’ın başarısız olduğunu söyler; exporter, ağ, yetki veya host sorunu olabilir. up=1 uygulamanın çalıştığını kanıtlamaz. Hedef yapılandırmadan çıkarıldığında up serisi kaybolabilir; bu yüzden vps-01 için ayrı absent_over_time kuralı vardır. time() – node_boot_time_seconds ise gözlenen son açılıştan geçen saniyedir, hizmet erişilebilirliği yüzdesi değildir.
# /etc/prometheus/rules/availability.yml
groups:
- name: vps-availability
rules:
- alert: NodeScrapeFailed
expr: up{job="node"} == 0
for: 1m
labels:
severity: critical
annotations:
summary: Node scrape failed ({{ $labels.instance }})
description: Prometheus has failed to scrape this target for one minute; inspect exporter, network and host
separately.
- alert: ExpectedNodeSamplesMissing
expr: absent_over_time(up{job="node",instance="vps-01"}[5m])
for: 1m
labels:
severity: critical
annotations:
summary: Expected node samples missing ({{ $labels.instance }})
description: No up samples for the expected target exist in the five-minute window. Check target configuration
and relabeling.
- alert: RecentBoot
expr: (time() - node_boot_time_seconds{job="node"} >= 0) and (time() - node_boot_time_seconds{job="node"} <
600)
for: 1m
labels:
severity: info
annotations:
summary: Recent host boot observed ({{ $labels.instance }})
description: Observed boot age is less than ten minutes. Compare maintenance records and system logs; this
is not outage duration.
Yokluk kuralı son beş dakikalık pencerede beklenen hedef için hiç up örneği kalmadığında etkinleşir; ardından bir dakika bekler. Başlangıçtan beri hiç örnek yoksa pencerenin dolmasını beklemez. RecentBoot yalnız ilk on dakikada gözlenebilen bilgilendirme kuralıdır; her yeniden başlatmayı yakalama garantisi yoktur. Anycast DNS ve otomatik failover rehberi erişim sürekliliği planına yardımcı olur; DNS TTL, istemci cache’i ve uygulama durumu geçişte yine önemlidir.
Grafana Kurulumu ve Pano Sorguları
Native Grafana Önkoşulu ve Veri Kaynağı
Grafana bu indirme betiğine dahil değildir. Aynı host üzerine resmi Debian/Ubuntu stable paketiyle desteklenen Grafana sürümünü kurun; kontrol tarihi için sürüm 13.3.0’dır. İlk başlatmadan önce /etc/grafana/grafana.ini içinde [server] bölümünde http_addr = 127.0.0.1 ve http_port = 3000 ayarlayın. Paket kurulumu sonrası servis açık geldiyse dış erişimi kısıtlayın ve ayarları uygulayarak yeniden başlatın. Başlangıç yönetici parolasını değiştirin ve anonim erişimi kapalı tutun.
Güvenilir SSH tüneliyle Grafana’ya erişin. Connections → Add new connection → Prometheus → Add new data source akışında URL http://127.0.0.1:9090 olmalıdır; bu adres native, aynı-host kurulum içindir. Save & test sonrasında gerçek node metriklerini sorgulayın. Grafana resmi belgeleri paket kurulumu ve veri kaynağı ayarlarının ayrıntılarını içerir. Bir veri kaynağı bağlantı testi alarm veya e-posta teslim testi değildir.
Önce Birimi Belli Panolar Oluşturun
CPU non-idle oranı: 1 - avg by (instance) (rate(node_cpu_seconds_total{job="node",mode="idle"}[5m])). Percent (0.0–1.0) birimini seçin; çekirdek ortalaması tek çekirdek darboğazını gizleyebileceğinden gerektiğinde çekirdek bazında da bakın.
Kullanılabilir bellek oranı: node_memory_MemAvailable_bytes{job="node"} / node_memory_MemTotal_bytes{job="node"}. Percent (0.0–1.0) birimi kullanın. Düşük değerleri süreç, swap ve uygulama ölçümleriyle ilişkilendirin; bu sorgu süreç bazında dağılım vermez.
Cihaz busy-time oranı: rate(node_disk_io_time_seconds_total{job="node"}[5m]). instance ve device etiketlerini gösterin. CPU iowait için avg by (instance) (rate(node_cpu_seconds_total{job="node",mode="iowait"}[5m])) ayrı panelde kullanılmalıdır; iki grafiğe aynı “disk kullanım yüzdesi” adını vermeyin.
Scrape durumu: up{job="node"}; 1 başarılı, 0 başarısız, veri yok ayrı durumdur. Açılıştan geçen süre için time() - node_boot_time_seconds{job="node"} kullanın ve birimi saniye/süre seçin. Dosya sistemi alanı için disk kuralındaki filtrelenmiş oranı eşiksiz sorgulayın; mountpoint ve mutlak boş alanı da gösterin.
Panoların normal trafik, düşük trafik ve veri yok durumlarını kontrol edin. Boş veriyi otomatik sıfırla doldurmak arızayı saklayabilir. Dağıtım ve bakım anotasyonları ekleyin; eşikleri gerçek uygulama etkisiyle ilişkilendirin. Grafana’nın alarm özellikleri kullanılacaksa sahiplik ve tekrar bildirim politikası ayrıca belirlenmelidir.
Alarm Gürültüsü ve Bildirim Gecikmesi
for Süresi Histerezis Değildir
for, koşulun kesintisiz gözlenmesi gereken süreyi belirler; açılma ve kapanma için farklı sayısal eşikler tanımlamaz. Bu örnekte koşul ilk yanlış değerlendirmede çözülür. Gerçek histerezis ayrı mantık ister; keep_firing_for ise koşul bittikten sonra firing durumunu belirli süre koruyan farklı bir seçenektir. Daha uzun bekleme gürültüyü azaltabilir ama müdahaleyi de geciktirir.
Gruplama ve Tekrar Aralıkları
Örnek, alertname ve instance etiketleriyle gruplar; ilk grup için 30 saniye, grup değişikliği için beş dakika, tekrar için iki saat kullanır. Bunlar kuralın for süresine eklenir; tam teslim süresi ağ ve SMTP’ye de bağlıdır. E-postada send_resolved açık olduğundan çözülme bildirimi de gönderilebilir. Birbirinden ayrı cihaz alarmlarının aynı host grubuna girebileceğini bildirim şablonunda hesaba katın.
Bakım Sessizleştirmelerini Sınırlandırma
Bakım için doğru job/instance veya başka dar etiketlerle başlangıç ve bitişi belli silence oluşturun. Silence, metrik toplamayı veya alarm değerlendirmesini durdurmaz; eşleşen bildirimleri bastırır. Bakım bitince silence durumunu ve gerçek teslimi kontrol edin. Süresi geçmiş sessizleştirme tek başına bütün alarm zincirinin sağlıklı olduğunu göstermez.
Eşiği İş Yüküne Göre Seçme
Yüzde 85 CPU veya yüzde 10 boş alan bütün VPS’ler için doğru eşik değildir. Büyüme hızı, kapasite, işlem süresi ve kabul edilen hizmet seviyesi birlikte değerlendirilir. vCPU, RAM ve IOPS kapasite planlama rehberi kaynak seçimini destekler. Normal grafiği yakalamak için tek bir sakin günü değil temsil edici yoğunluk dönemlerini de ölçün.
Metrik ve Yönetim Erişimini Koruma
Bu örnekte 9100, 9090 ve 9093 internetten erişilebilir olmamalıdır; dinleyiciler 127.0.0.1 ile sınırlıdır. Uzak izleme eklenirse özel ağ/VPN, uygun TLS ve kimlik doğrulama ile yalnız gerekli kaynaklara erişim verin. IPv4 ve IPv6’yı dış konumdan kontrol edin. Sadece bir firewall allow satırı eklemek daha geniş izinleri otomatik kaldırmaz.
Port numarasını gizlemek kimlik doğrulamanın yerini tutmaz. Grafana’da kişisel hesaplar, en az yetkili roller ve gerekiyorsa TLS korumalı proxy/SSO kullanın; backend yerel kalsın. Sertifika yenilemeyi ve erişim iptalini test edin. Loopback aynı host üzerindeki güvenilmeyen kullanıcı veya süreçleri birbirinden ayıran bir güvenlik sınırı değildir.
Doğrulama, Başlatma ve Yeniden Yükleme
Bütün kural, config ve unit dosyalarını hazırlayıp gerçek SMTP bilgilerini yerleştirdikten sonra aşağıdaki kontrolleri çalıştırın. promtool/amtool sözdizimini ve şemayı denetler; gerçek kullanıcı altında çalıştırmak okunabilirlik sorunlarını da gösterebilir. systemd-analyze verify çalışma ortamının ve teslimin başarılı olduğunu tek başına kanıtlamaz. Unit değişikliğinde daemon-reload ve ilgili servisin yeniden başlatılması gerekir.
# Run only after all files and the protected SMTP password exist.
set -eu
chown root:prometheus /etc/prometheus/prometheus.yml /etc/prometheus/rules/*.yml
chmod 0640 /etc/prometheus/prometheus.yml /etc/prometheus/rules/*.yml
chown root:alertmanager /etc/alertmanager/alertmanager.yml /etc/alertmanager/smtp-password
chmod 0640 /etc/alertmanager/alertmanager.yml /etc/alertmanager/smtp-password
chown root:root /etc/systemd/system/{node_exporter,prometheus,alertmanager}.service
chmod 0644 /etc/systemd/system/{node_exporter,prometheus,alertmanager}.service
runuser -u alertmanager -- test -s /etc/alertmanager/smtp-password
runuser -u alertmanager -- test -r /etc/alertmanager/smtp-password
runuser -u prometheus -- /usr/local/bin/promtool check config /etc/prometheus/prometheus.yml
runuser -u alertmanager -- /usr/local/bin/amtool check-config /etc/alertmanager/alertmanager.yml
systemd-analyze verify /etc/systemd/system/{node_exporter,prometheus,alertmanager}.service
systemctl daemon-reload
systemctl enable --now node_exporter alertmanager prometheus
systemctl --no-pager --full status node_exporter alertmanager prometheus
curl --fail http://127.0.0.1:9100/metrics
curl --fail http://127.0.0.1:9090/-/ready
curl --fail http://127.0.0.1:9093/-/ready
# After later configuration-only changes:
runuser -u prometheus -- /usr/local/bin/promtool check config /etc/prometheus/prometheus.yml && systemctl reload prometheus
runuser -u alertmanager -- /usr/local/bin/amtool check-config /etc/alertmanager/alertmanager.yml && systemctl reload alertmanager
journalctl -u prometheus -u alertmanager --since '-5 minutes' --no-pager
Prometheus Targets, Rules ve Alerts ekranlarında node hedefini, sekiz yüklenmiş alarmı, pending/firing durumlarını ve Alertmanager hedefini kontrol edin; loglarda reload başarısını doğrulayın. Ayrı test ortamında kısa ömürlü, açıkça test diye etiketlenmiş sentetik bir alarmı yetkili test alıcısına yönlendirerek kural → Alertmanager → SMTP → alıcı teslim zincirini sınayın, sonra test kuralını kaldırıp çözülmeyi doğrulayın. Üretim CPU’sunu yükle doldurmak veya gerçek kişilere deneme bildirimi yağdırmak gerekmez.
İsteğe Bağlı Docker Compose Alternatifi
Bu ayrı yol Linux üzerinde Docker Engine ve Compose eklentisi gerektirir; native servisleri aynı portlarda eşzamanlı çalıştırmayın. Yeni ve ayrı bir çalışma dizini kullanın. Aşağıdaki imaj digestleri sırasıyla Node Exporter 1.12.1, Prometheus 3.15.1, Alertmanager 0.34.2 ve Grafana 13.3.0 etiketlerinden doğrulanmıştır. Dört servis host network kullandığından aynı loopback adresleri geçerlidir; ports eşlemesi eklenmez. Host PID ve /host bağlaması Node Exporter içindir; tam host görünürlüğünün erişim etkisini değerlendirin. Bu örnekte timex collector kapalıdır; gerekli syscall yetkisini artırmadan temel CPU/bellek/disk metrikleri kullanılır.
prometheus/prometheus.yml ve prometheus/rules altına yukarıdaki config/kuralları, alertmanager/alertmanager.yml ve alertmanager/smtp-password içine gerçek SMTP ayarlarını yerleştirin. Dosya adları aynı container yollarına bağlanır. state/prometheus, state/alertmanager, state/grafana, textfile ve secrets dizinlerini önceden oluşturun; secrets/grafana-admin-password gerçek, ayrı bir başlangıç parolası içersin. Örnekte açıkça seçilen UID/GID değerleri 65001, 65002, 65003 ve 472’dir; hostta bu kimliklerin çakışmadığını doğrulayın. Prometheus ve Alertmanager veri dizinleri kendi UID’sine, Grafana verisi 472’ye yazılabilir olmalıdır. Config dizinleri root ve ilgili 65002/65003 grubu için 0750, dosyalar 0640; textfile root:65001 ve 0750; Grafana parola dosyası root:472 ve 0640 olmalıdır. Kaynak dizinlerin türünü, geçiş/okuma iznini, gerekiyorsa SELinux politikasını ve ek mountların gerçekten görünürlüğünü kontrol edin. Node Exporter’a textfile yazma yetkisi verilmez.
services:
node-exporter:
image: prom/node-exporter@sha256:1b4e4438faca4dd7e001dd445d161a4a2091b0fededa84093b3a8dfeae1f1be0
user: 65001:65001
network_mode: host
pid: host
restart: unless-stopped
command:
- --path.rootfs=/host
- --web.listen-address=127.0.0.1:9100
- --collector.textfile.directory=/textfile
- --no-collector.timex
volumes:
- /:/host:ro,rslave
- ./textfile:/textfile:ro
prometheus:
image: prom/prometheus@sha256:fa3302279710be2f21a8301ec17a8b4f2301fd829bd113839b3b6b02b6f191a2
user: 65002:65002
network_mode: host
restart: unless-stopped
command:
- --config.file=/etc/prometheus/prometheus.yml
- --storage.tsdb.path=/prometheus
- --web.listen-address=127.0.0.1:9090
- --storage.tsdb.retention.time=15d
- --storage.tsdb.retention.size=2GB
volumes:
- ./prometheus:/etc/prometheus:ro
- ./state/prometheus:/prometheus
alertmanager:
image: prom/alertmanager@sha256:39d8bb3966c694a124428a3a88fbcffd40bd069129ecd47c059f8a3f17c55f3b
user: 65003:65003
network_mode: host
restart: unless-stopped
command:
- --config.file=/etc/alertmanager/alertmanager.yml
- --storage.path=/alertmanager
- --web.listen-address=127.0.0.1:9093
- --cluster.listen-address=
volumes:
- ./alertmanager:/etc/alertmanager:ro
- ./state/alertmanager:/alertmanager
grafana:
image: grafana/grafana@sha256:488984b716c0862639f91a698adbe2862677a5a07bad42da5f03f3030883b205
user: 472:472
network_mode: host
restart: unless-stopped
environment:
GF_SERVER_HTTP_ADDR: 127.0.0.1
GF_SERVER_HTTP_PORT: '3000'
GF_SECURITY_ADMIN_USER: admin
GF_SECURITY_ADMIN_PASSWORD__FILE: /run/secrets/grafana-admin-password
GF_AUTH_ANONYMOUS_ENABLED: 'false'
volumes:
- ./state/grafana:/var/lib/grafana
- ./secrets/grafana-admin-password:/run/secrets/grafana-admin-password:ro
docker compose config ile birleştirilmiş yapıyı kontrol edin. Prometheus kontrolü için docker compose run --rm --no-deps --entrypoint /bin/promtool prometheus check config /etc/prometheus/prometheus.yml, Alertmanager için docker compose run --rm --no-deps --entrypoint /bin/amtool alertmanager check-config /etc/alertmanager/alertmanager.yml kullanın. entrypoint açıkça değiştirilir; normal Prometheus executable dosyasına promtool komutu eklemek aynı şey değildir. Ardından test ortamında docker compose up -d ile başlatıp logları, yerel readiness uçlarını ve gerçek metrik/bildirim zincirini doğrulayın. Native Grafana paketini bu alternatifte ayrıca kurmayın; veri kaynağı yine http://127.0.0.1:9090’dır. Parola dosyası yalnız yeni Grafana hesabının başlangıcı içindir; var olan veritabanındaki parolayı döndürmez. Config değişikliğinde aynı kontrollerden sonra docker compose kill -s SIGHUP prometheus alertmanager ile yeniden yükleyin ve loglarda kabul edildiğini doğrulayın. Host network, kalıcı dizinler veya digest sabitlemek yüksek erişilebilirlik sağlamaz; gerçek container başlangıcı, izinler ve teslim ortamınızda ayrıca sınanmalıdır.
Bakım ve Eksik Veri Kontrolleri
Her alarm için ilk inceleme adımını yazın; eylem gerektirmeyen sinyalleri panoda tutun. Kural dosyalarını promtool test rules ile normal, eşik, kısa sıçrama, eksik veri ve çözülme örnekleri üzerinden sınayın. Bir kuralın parse edilmesi doğru alarm verdiğinin kanıtı değildir.
up=1 bütün collector’ların başarılı olduğu anlamına gelmez. Gerekli collector metriklerini, node_scrape_collector_success değerlerini ve textfile kullanılıyorsa node_textfile_scrape_error durumunu da kontrol edin. Boş panoda önce gerçek seri, job/instance etiketleri, zaman aralığı ve veri kaynağını doğrulayın.
Disk uyarısını rastgele log veya yedek silmeye bağlamayın. Rotasyon, saklama, yasal/iş ihtiyacı ve doğrulanmış geri yükleme politikasını birlikte uygulayın. 3-2-1 yedekleme stratejisi ayrı kopyalar için çerçeve sağlar. Prometheus tutarlı TSDB yedeği, config/kurallar, Alertmanager durumu ve Grafana verisi için kurtarma kapsamını belirleyip ayrı ortamda restore deneyin.
Sürümleri ve digestleri dağıtım kaydında tutun; yükseltmeden önce sürüm notlarını, config uyumunu ve veri formatını inceleyin. Node Exporter deposu ve kurulum notları güncel collector seçeneklerini gösterir. İzleme araçları bakım gerektirir; başarılı ilk kurulum yıllarca sorunsuz çalışacakları anlamına gelmez.
Textfile collector, makineye bağlı batch işlerinin son başarı zamanı gibi metrikler içindir. Yetkili üretici önce aynı dizinde geçici dosya yazıp atomik rename ile .prom adına geçirsin; örneklere timestamp eklemeyin. Sürekli uygulama istek, hata ve kuyruk metrikleri için uygun enstrümantasyon/exporter kullanın; eski dosyanın kaldığını fark edecek tazelik kuralı ayrıca gerekir.
Metrikten Düzeltme Kararına Geçme
CPU yükseldi diye otomatik kaynak artırmak veya cache açmak yerine ilgili iş yükünü belirleyin. Cloudflare WAF ve oran sınırlama rehberi istenmeyen web trafiği için ayrı bir seçenek sunar; meşru trafiği engelleme riski ölçülmelidir. Taşıma için DNS TTL stratejileri ise geçiş planına yardımcı olur. TTL tek başına sıfır kesinti garantisi değildir; eski kayıtlar, bağlantılar ve veri tutarlılığı da yönetilir.
Kapasiteyi Ne Zaman Değiştirmeli?
Kalıcı kaynak baskısını gecikme, hata oranı ve talep artışıyla birlikte değerlendirin. Yüksek CPU bazen verimli kullanım, bazen tek çekirdek veya steal sorunudur. Disk busy-time yükselişi farklı cihazlarda aynı anlama gelmez. Optimizasyon, iş zamanlama değişikliği, dikey büyütme veya hizmetleri ayırma seçeneklerini ölçüm ve kontrollü testle karşılaştırın.
WooCommerce, Laravel ve Node.js için VPS kaynak seçimi başlangıç kararlarını destekler; gerçek seri hacmi ve uygulama yükü yine ölçülmelidir. İzleme bileşenlerini ayrı hosta taşırken scrape adresi, firewall, kimlik doğrulama, instance benzersizliği ve alarm hedeflerini beraber güncelleyin; aynı hosttaki ortak arıza alanı ancak mimari değişiklikle azaltılır.
İlk Kurulumun Kabul Kontrolleri
Kurulum hazır sayılmadan önce hedef metrikleri, doğru birimli panoları, sekiz kuralın koşullarını, gerçek test alıcısına teslimi ve eksik veri davranışını kontrol edin. Dosya izinleri, localhost dinleme adresleri, disk kapasitesi ve servis yeniden başlatma sonrası toparlanma ayrıca doğrulanmalıdır. Her kontrolün tarihi, sürümü ve sonucu kaydedilirse sonraki değişiklikler daha kolay karşılaştırılır.
Tek hedefle başlayın; normal ve yoğun trafik örneklerini gözleyip eşiği ve bildirim gecikmesini sorumlu ekibin müdahale süresine göre ayarlayın. İzleme sunucusunun kendisini bağımsız bir noktadan kontrol edin. Böylece metrik, alarm koşulu ve bildirim arasındaki boşluklar görünür olur; güven, yalnız yeşil bir panodan değil doğrulanmış çalışma zincirinden gelir.





