Belastingsgeschiedenis van de server: 24 uur, 7 of 30 dagen (verzameling — één keer per 5 minuten)
| Proces | 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 |
| Proces | 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 beantwoordt een vraag over de huidige seconde, terwijl de vraag die men werkelijk stelt over de afgelopen nacht gaat: waarom om drie uur alles vastliep en vanzelf weer terugkwam. Op dat moment valt er niets meer te bekijken, want er is niets bewaard gebleven. Prometheus en Grafana opzetten voor één enkele VPS levert een eigen probleem op: de observerende stack weegt zwaarder dan de geobserveerde server.
Een collector schrijft elke vijf minuten een regel naar de database, en deze pagina tekent daaruit de laatste 24 uur. Load average, CPU-gebruik met I/O wait apart, RAM en swap, binnenkomend en uitgaand netwerkverkeer, lees- en schrijfacties van de schijf, tot stand gebrachte TCP-verbindingen, processen, vulling van de partitie, inodes en bestandsdescriptors als percentage van hun limiet, MySQL-verbindingen. Alles op één pagina en op dezelfde tijdas, zodat samenlopen met het blote oog zichtbaar worden.
Deze grafieken leest u het best in paren. Een hoge I/O wait bij een rustige CPU betekent dat de server op de schijf wacht, en meer cores helpen dan niet. Swap die eenmaal opliep en nooit naar nul terugkeerde zegt dat de geheugenpiek al geweest is, hoe rustig het nu ook oogt. Bestandsdescriptors tegen de honderd procent zijn een too many open files enkele uren voordat die optreedt. En op de meeste servers raken de inodes ruim eerder op dan de vrije ruimte.