Prin ce diferă de Uptime Kuma?

Uptime Kuma răspunde la „e pornit?”. Prometheus și Grafana răspund la „de ce e lent și de când a început?” — metrici de CPU, memorie, disc, rețea și aplicație în timp. Mulți le rulează pe amândouă: Kuma pentru alerte la căderi, Grafana pentru tendințe și planificarea capacității.

Cât disc folosește Prometheus?

Aproximativ 1–2 octeți per eșantion după comprimare. Zece servere care exportă câte o mie de serii fiecare, citite la fiecare 15 secunde, înseamnă cam 60 de milioane de eșantioane pe zi — de ordinul a 100 MB. Cu păstrarea implicită de 15 zile, asta înseamnă câțiva gigaocteți.

Pot monitoriza servere pe planuri NAT?

Da, dar nu prin citire directă — un server NAT nu acceptă conexiuni de intrare spre exporterul lui. Rulează Prometheus în modul agent pe serverul NAT și împinge metricile spre serverul de monitorizare cu remote_write. Serverul de monitorizare în sine ar trebui să fie pe un plan cu IP dedicat.

Ce plan ar trebui să aibă serverul de monitorizare?

Micro-IP (2 GB RAM, $10/lună) duce comod una-două duzini de hosturi. Dacă adaugi metrici de aplicație cu cardinalitate mare sau păstrezi date pe luni întregi, treci la Small-IP. Un IP dedicat îți dă HTTPS pentru Grafana și o adresă stabilă pe care s-o pui pe lista albă a țintelor.

Ar trebui serverul de monitorizare să fie separat de ce monitorizează?

Da. Dacă Grafana rulează pe serverul care tocmai a rămas fără memorie, pierzi imaginea problemei exact când ai nevoie de ea. Un VPS mic, separat, merge mai departe atunci când o mașină de producție nu mai merge.

VPS pentru monitorizarea serverelor cu Grafana + Prometheus

Adună metricile de CPU, RAM, disc și servicii de la toate serverele tale într-un singur loc: Prometheus, node_exporter și Grafana pe un VPS, în spatele HTTPS.

„Serverul e lent” e un raport de bug inutil — dacă nu poți deschide un grafic și vedea că memoria a urcat trei zile înainte de cădere. Asta îți dau Prometheus și Grafana: CPU-ul, RAM-ul, discul și rețeaua fiecărui server, înregistrate la fiecare 15 secunde și desenate ca grafice prin care poți derula înapoi. Pune-le pe propriul VPS mic și vor veghea în continuare chiar și când o mașină de producție cade.

Piesele

node_exporter pe fiecare server pe care vrei să-l urmărești — expune metricile sistemului pe portul 9100.
Prometheus pe VPS-ul de monitorizare — trage (scrape) aceste metrici și le stochează.
Grafana — dashboardurile, în spatele HTTPS.
Opțional, Alertmanager sau alertele din Grafana, ca să-ți scrie când ceva trece de un prag.

De ce ai nevoie

Micro-IP ($10/lună, 2 vCPU, 2 GB RAM, 25 GB) urmărește una-două duzini de servere. Mai multe hosturi, metrici proprii de aplicație sau păstrare pe luni: Small-IP.
Un IPv4 dedicat pentru serverul de monitorizare — Grafana e servită prin HTTPS, iar țintele tale pot pune pe lista albă o singură adresă stabilă pentru portul 9100.

1. node_exporter pe fiecare țintă

apt install -y prometheus-node-exporter
# allow only the monitoring server to scrape it
ufw allow from 203.0.113.10 to any port 9100 proto tcp

Înlocuiește 203.0.113.10 cu adresa VPS-ului de monitorizare. Nu lăsa niciodată 9100 deschis spre toată lumea — divulgă multe despre serverul tău.

2. Prometheus și Grafana pe VPS-ul de monitorizare

apt update && apt install -y docker.io docker-compose-v2 caddy
mkdir -p /opt/monitoring && cd /opt/monitoring

cat > prometheus.yml <<'EOF'
global:
  scrape_interval: 15s
scrape_configs:
  - job_name: nodes
    static_configs:
      - targets: ['198.51.100.21:9100', '198.51.100.22:9100']
EOF

cat > compose.yml <<'EOF'
services:
  prometheus:
    image: prom/prometheus
    volumes: [ "./prometheus.yml:/etc/prometheus/prometheus.yml:ro", "prom:/prometheus" ]
    command: [ "--config.file=/etc/prometheus/prometheus.yml", "--storage.tsdb.retention.time=15d", "--web.enable-remote-write-receiver" ]
    ports: [ "127.0.0.1:9090:9090" ]
    restart: unless-stopped
  grafana:
    image: grafana/grafana
    volumes: [ "grafana:/var/lib/grafana" ]
    ports: [ "127.0.0.1:3000:3000" ]
    restart: unless-stopped
volumes: { prom: {}, grafana: {} }
EOF

docker compose up -d

HTTPS în fața lui Grafana:

echo 'grafana.example.com {
    reverse_proxy 127.0.0.1:3000
}' > /etc/caddy/Caddyfile && systemctl reload caddy

Autentifică-te (admin / admin, apoi schimbă parola), adaugă Prometheus ca sursă de date la http://prometheus:9090 și importă dashboardul comunității „Node Exporter Full” (ID 1860). Ai un dashboard complet al sistemului în aproximativ un minut.

Servere pe planuri NAT

Un server NAT acceptă conexiuni de intrare doar pe portul lui SSH personal, așa că Prometheus nu-i poate citi exporterul. Inversează direcția: rulează Prometheus în modul agent pe serverul NAT și împinge datele spre serverul de monitorizare, care acceptă deja scrieri de la distanță (parametrul --web.enable-remote-write-receiver de mai sus).

# /etc/prometheus/agent.yml on the NAT server
scrape_configs:
  - job_name: self
    static_configs: [ { targets: ['127.0.0.1:9100'] } ]
remote_write:
  - url: https://prom-push.example.com/api/v1/write

Expune acel endpoint de primire prin Caddy, cu autentificare basic, în loc să deschizi portul 9090 așa cum e.

Note cinstite

Prometheus trage datele; e excelent pentru o flotă pe care o controlezi și incomod pentru orice e în spatele unui NAT — de aici trucul cu agentul. Stocarea lui locală nu e gândită pentru ani de istoric; pentru păstrare lungă ai adăuga mai târziu o stocare la distanță. Iar dashboardurile sunt doar jumătate din valoare: setează din prima zi măcar trei alerte (disc peste 85%, presiune pe memorie, țintă căzută), altfel te vei uita la grafice abia după ce ceva s-a stricat deja.

Legate

VPS pentru monitorizarea disponibilității (Uptime Kuma) — alerte la căderi și pagini de stare
Cum configurezi un firewall UFW
De câtă RAM are nevoie un VPS?