Situatie
Cel mai des îmi spun clienții SMB: “Avem deja Zabbix / PRTG / un script care trimite mail când scade spațiul pe disc, e suficient.” Și până într-un punct chiar e. Funcționează, te anunță când ceva moare, costă puțin sau nimic. Apoi crești la 30-40 de servere, încep să apară micro-serviciile, container-ele, un cluster de Kubernetes mic, și deodată stack-ul vechi nu mai poate ține pasul.
L-am întâlnit la un client cu 25 de VM-uri pe Proxmox, 3 noduri Kubernetes (k3s pe bare metal pentru aplicațiile interne) și o stivă de containere Docker pe câteva host-uri standalone. PRTG-ul lor cu 100 sensori plătiți era depășit – nu putea face metrics per-container, alertele erau rigide, dashboard-urile fixe. Ne-au cerut “ceva care să crească cu noi fără să plătim 10k/an”.
Răspunsul a fost Prometheus + Grafana, cu Alertmanager în spate. Setup zero costuri de licențiere, scalează ușor, comunitate uriașă. Dar nu e plug-and-play – dacă vrei să faci treabă serioasă, intri în câteva concepte care la prima vedere par overkill pentru SMB.
Solutie
Primul pas – arhitectura minimală care funcționează
Pentru un SMB cu 20-50 de target-uri, stack-ul pe care îl recomand arată așa:
[Targets] [Scraping] [Storage]
───────── ────────── ─────────
node_exporter ──┐
cAdvisor ──┤
blackbox_exporter ──┼──> Prometheus (15s scrape) ──> TSDB local (15-30 zile)
postgres_exporter ──┤ └─> Remote write opțional →
mysqld_exporter ──┤ Mimir / VictoriaMetrics
custom /metrics ──┘ pentru retention long-term
│
▼
Alertmanager ──> Slack / Email / PagerDuty / SMS
│
▼
Grafana ──> Dashboards + ad-hoc queries
Pentru un client mic, Prometheus pe un singur VM cu 4 vCPU și 8GB RAM ține lejer 50 de target-uri și 30 de zile de retention pe SSD de 200GB. Nu trebuie cluster, nu trebuie HA, nu trebuie Thanos. Add complexity only when needed.
Lucrul pe care mulți îl ignoră la început: relabel_configs. Dacă nu îți organizezi labels-urile de la început (env=prod/staging, role=db/web/cache, datacenter=ro1/ro2), vei avea dashboard-uri haotice și alertare imposibilă. Investește o zi în taxonomia de labels înainte să adaugi al 10-lea exporter.
După 2 luni de la implementare, am pus o regulă banală în Alertmanager:
- alert: DiskWillFillIn4Hours
expr: predict_linear(node_filesystem_avail_bytes{mountpoint!~"/run.*|/tmp.*"}[1h], 4*3600) < 0
for: 15m
labels:
severity: warning
annotations:
summary: "Disk {{ $labels.device }} on {{ $labels.instance }} will fill in <4h"
Vineri seară, ora 22:30, primesc ping pe telefon: “Disk /var pe sql-prod-01 will fill in <4h”. Mă conectez, văd că o aplicație pornise un job de import care scria 50GB/oră în /var/log fără rotație. Dacă mergea până dimineață, baza de date se prăbușea sâmbătă la prânz. 10 minute de logrotate forțat și o regulă nouă în rsyslog au rezolvat problema fără ca cineva să afle vreodată.
Diferența față de Zabbix-ul vechi care trimitea “Disk usage > 90%” e enormă: aici PRIMESC alertă înainte ca problema să fie problemă, bazat pe trend, nu pe prag fix. Predictia liniară din PromQL e una din cele mai subutilizate funcții.
După 3 ani de dashboard-uri în Grafana la diverși clienți, am decantat 5 panel-uri esențiale pe care le construiesc primele:
1. Overview SRE Golden Signals (Latency, Traffic, Errors, Saturation) 2. Host fleet health (CPU/RAM/Disk pe toate VM-urile, top-N în roșu) 3. Network throughput per interface (detectare exfiltration / DDoS intern) 4. Backup jobs status (job duration, last success age, success rate) 5. Certificate expiry (blackbox_exporter pentru toate HTTPS-urile interne)
Pentru #5 – blackbox_exporter cu modul http_2xx și o regulă “cert expiry < 30d → alert” a salvat 4 clienți de la outage-uri pe certificate expirate. E genul de problemă care în 2026 nu mai ar trebui să existe, dar încă există peste tot.
Leave A Comment?