Historia obciążenia serwera: 24 godziny, 7 lub 30 dni (zbieranie — raz na 5 minut)
| 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 odpowiada na pytanie o bieżącą sekundę, podczas gdy pytanie, które naprawdę się zadaje, dotyczy minionej nocy: dlaczego o trzeciej wszystko stanęło i wróciło samo. W tym momencie nie ma już na co patrzeć, bo nic nie zostało zapisane. Stawianie Prometheusa i Grafany dla jednego VPS-a to osobny kłopot: stos, który obserwuje, waży więcej niż obserwowany serwer.
Kolektor co pięć minut dopisuje do bazy jeden wiersz, a ta strona rysuje z nich ostatnią dobę. Load average, obciążenie CPU z osobno pokazanym I/O wait, RAM i swap, ruch sieciowy przychodzący i wychodzący, odczyty i zapisy dysku, nawiązane połączenia TCP, procesy, zapełnienie partycji, i-węzły oraz deskryptory plików w procentach limitu, połączenia MySQL. Wszystko na jednej stronie i na tej samej osi czasu, więc zbieżności widać gołym okiem.
Te wykresy warto czytać parami. Wysoki I/O wait przy spokojnym CPU oznacza, że serwer czeka na dysk i dokładanie rdzeni nic nie da. Swap, który raz urósł i nigdy nie wrócił do zera, mówi, że szczyt zużycia pamięci już był, choćby teraz wyglądało spokojnie. Deskryptory plików zbliżające się do stu procent to too many open files na kilka godzin przed wystąpieniem. A na większości serwerów i-węzły kończą się wyraźnie wcześniej niż wolne miejsce.