| Process | 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 |
| Process | 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 svarar på en fråga om den aktuella sekunden, medan frågan man verkligen ställer gäller natten som gick: varför allt stannade klockan tre och kom tillbaka av sig självt. Då finns det inget kvar att titta på, eftersom ingenting sparades. Att sätta upp Prometheus och Grafana för en enda VPS är ett problem i sig: stacken som observerar väger tyngre än servern som observeras.
En insamlare lägger till en rad i databasen var femte minut, och den här sidan ritar det senaste dygnet utifrån dem. Load average, CPU-användning med I/O wait separat, RAM och swap, inkommande och utgående nätverkstrafik, diskens läsningar och skrivningar, etablerade TCP-anslutningar, processer, partitionens fyllnadsgrad, inoder och filbeskrivare i procent av sin gräns, MySQL-anslutningar. Allt på en sida och på samma tidsaxel, så att sammanträffanden syns med blotta ögat.
Diagrammen läses bäst parvis. Hög I/O wait vid lugn CPU betyder att servern väntar på disken, och fler kärnor hjälper inte. Swap som steg en gång och aldrig återvände till noll säger att minnestoppen redan inträffat, hur stilla det än ser ut nu. Filbeskrivare nära hundra procent är ett too many open files några timmar innan det inträffar. Och på de flesta servrar tar inoderna slut långt före det lediga utrymmet.