Monitoring koji nitko ne gleda je skuplji od nikakvog monitoringa: lažan osjećaj sigurnosti. Za mali tim ili jednog admina cilj nije „puni observability stack“, nego nekoliko signala koji vode do akcije.
Četiri sloja (od jednostavnog prema dubljem)
Prvo uptime / probe: je li HTTPS endpoint živ izvana? Zatim logovi: što se dogodilo kad nije? Metrike pokrivaju disk, memoriju, CPU, latency, queue dubinu. Alertovi odgovaraju na tko, kada, i što napraviti.
Većina SMB setupova treba uptime odmah, logove u nekom obliku, metrike selektivno, i alertove s kratkim popisom pravila.
Uptime: najjeftiniji ROI
Vanjski HTTP(S) check na kritične URL-ove (svakih 1 do 5 minuta) hvata „server down“, istekao cert (ako check validira TLS), i greške reverse proxyja. Alati tipa Healthchecks.io, Uptime Kuma (self-host) ili managed uptime servisi rade posao. Bitno: alert na kanal koji stvarno čitate (email plus mobitel), ne na inbox koji ignorirate.
Logovi bez ELK opsesije
Na jednom VPS-u često dovoljan: journalctl, Docker log driver s rotacijom, i povremeno centralizacija (Loki, ili samo sync na drugi host). Ne gradite Elasticsearch cluster da biste našli jedan 502.
# Brza dijagnostika
docker compose logs --since=1h web
journalctl -u docker -n 100 --no-pager
Metrike: Prometheus+Grafana vs lakše opcije
Netdata i slični host agent daju brzo „što se događa na stroju“, s manje custom queryja. Prometheus plus Grafana plus node_exporter plus cAdvisor ima smisla kad trebate povijest, dashboard po servisu, i alert rules koje posjedujete.
Za jedan Docker VPS Prometheus stack ima smisla ako ćete ga održavati. Ako nećete, lakši agent plus vanjski uptime često daje više vrijednosti po satu rada.
# docker-compose isječak: ideja, ne cijeli stack
services:
node-exporter:
image: prom/node-exporter:v1.8.2
restart: unless-stopped
pid: host
volumes:
- /:/host:ro,rslave
command: ["--path.rootfs=/host"]
Što pratiti na tipičnom Docker VPS-u
Disk space i inode usage (logovi i kontejneri vole napuniti inodes). Memorija i swap pritisak, jer OOM ubija tiho. Load/CPU kad očekujete mir: spike noću često znači backup ili bot. TLS cert expiry (Traefik/Let's Encrypt obično renewa; i dalje alertajte 14 dana prije). Systemd/Docker restart petlje na kritičnim servisima. I backup job success. Vidi Backup strategija 3-2-1.
Ako ste ispred proxyja s Traefikom, pratite i 5xx rate te renew greške. Traefik na VPS-u.
Minimalni alert set (start)
- Host down / HTTPS fail > 2-3 minute
- Disk > 85% ili inode > 85%
- TLS cert < 14 dana
- Backup job nije javio success u očekivanom prozoru
- OOM / česti restart kritičnog kontejnera
Sve ostalo može biti dashboard ili tjedni pregled, ne noćni page.
Alert fatigue
Deset mailova dnevno znači nula reakcije. Alertajte samo na stvari koje traže ljudsku akciju. Razlikujte warning i critical (disk 80% nije isto što disk 95%). Dedup i quiet hours za non-critical pomažu. U samom alertu stavite runbook u jednoj rečenici: „oslobodi /var/lib/docker, provjeri restic timer“.
SLO lite za mali tim
Ne trebate formalni SRE program. Dovoljan dogovor: „javni site up ≥ X% mjesečno“ i „backup restore testiran kvartalno“. Mjerite uptime checkovima. Kad padnete ispod, popravite uzrok. Nemojte samo spustiti cilj.
Zaključak
Počnite s vanjskim uptimeom, rotacijom logova i par metrika (disk, memorija, cert). Prometheus dodajte kad vam treba povijest i vlastita pravila. Cilj je signal, ne dashboard galerija. Za postavljanje razumnog monitoringa uz postojeći stack, DevOps usluge na disketa.hr.