Auslastungsverlauf des Servers: 24 Stunden, 7 oder 30 Tage (Erfassung alle 5 Minuten)
| Prozess | CPU % | RAM % |
|---|---|---|
| apache2 | 13.4 | 4.7 |
| clamd | 9.8 | 5.3 |
| crowdsec | 6.6 | 9.6 |
| suricata | 4.7 | 0.9 |
| falco | 2.6 | 16.5 |
| Prozess | CPU % | RAM % |
|---|---|---|
| falco | 19.5 | 5.3 |
| mysqld | 13.1 | 9.6 |
| fail2ban-server | 8.1 | 8.8 |
| crowdsec | 5.7 | 13.6 |
| apache2 | 3.5 | 11.0 |
top beantwortet eine Frage zur aktuellen Sekunde, gefragt wird aber meist nach der letzten Nacht: warum um drei Uhr alles stehenblieb und von selbst wiederkam. Zu diesem Zeitpunkt gibt es nichts mehr anzusehen, denn nichts wurde festgehalten. Prometheus und Grafana für einen einzigen VPS aufzusetzen ist ebenfalls fragwürdig: Der beobachtende Stack wiegt schwerer als der beobachtete Server.
Ein Kollektor schreibt alle fünf Minuten eine Zeile in die Datenbank, und diese Seite zeichnet daraus die letzten 24 Stunden. Load Average, CPU-Auslastung mit separatem I/O wait, RAM und Swap, ein- und ausgehender Netzwerkverkehr, Lese- und Schreibvorgänge der Festplatte, bestehende TCP-Verbindungen, Prozesse, Belegung der Partition, Inodes und Dateideskriptoren in Prozent ihres Limits, MySQL-Verbindungen. Alles auf einer Seite und auf derselben Zeitachse, sodass Zusammenhänge mit bloßem Auge sichtbar werden.
Diese Grafiken liest man am besten paarweise. Hoher I/O wait bei ruhiger CPU heißt, dass der Server auf die Festplatte wartet; mehr Kerne helfen dann nicht. Swap, der einmal angestiegen und nie auf null zurückgekehrt ist, sagt, dass die Speicherspitze bereits stattgefunden hat, so ruhig es im Moment auch aussieht. Dateideskriptoren nahe hundert Prozent sind ein too many open files einige Stunden vor seinem Eintreten. Und auf den meisten Servern gehen die Inodes deutlich früher aus als der freie Speicherplatz.