| Prosess | CPU % | RAM % |
|---|---|---|
| falco | 7.4 | 5.6 |
| mysqld | 4.4 | 7.3 |
| crowdsec | 2.6 | 15.6 |
| apache2 | 1.4 | 4.5 |
| fail2ban-server | 0.7 | 17.1 |
| Prosess | CPU % | RAM % |
|---|---|---|
| apache2 | 18.0 | 9.3 |
| mysqld | 12.8 | 14.0 |
| clamd | 8.9 | 14.3 |
| falco | 6.2 | 11.0 |
| suricata | 2.8 | 18.4 |
top svarer på et spørsmål om det gjeldende sekundet, mens spørsmålet man faktisk stiller gjelder natten som gikk: hvorfor alt stoppet klokken tre og kom tilbake av seg selv. Da er det ingenting igjen å se på, for ingenting ble lagret. Å sette opp Prometheus og Grafana for én enkelt VPS er et problem i seg selv: stakken som observerer veier tyngre enn serveren som observeres.
En innsamler legger til én rad i databasen hvert femte minutt, og denne siden tegner det siste døgnet ut fra dem. Load average, CPU-bruk med I/O wait for seg, RAM og swap, inn- og utgående nettverkstrafikk, diskens lesing og skriving, etablerte TCP-forbindelser, prosesser, fyllingsgrad på partisjonen, inoder og fildeskriptorer i prosent av grensen, MySQL-forbindelser. Alt på én side og på samme tidsakse, slik at sammenfall er synlige for det blotte øye.
Grafene leses best parvis. Høy I/O wait med rolig CPU betyr at serveren venter på disken, og flere kjerner hjelper ikke. Swap som steg én gang og aldri kom tilbake til null, sier at minnetoppen allerede har vært, uansett hvor stille det ser ut nå. Fildeskriptorer nær hundre prosent er en too many open files noen timer før den inntreffer. Og på de fleste servere går inodene tomme et godt stykke før den ledige plassen gjør det.