Istoricul încărcării serverului: 24 de ore, 7 sau 30 de zile (colectare — o dată la 5 minute)
| 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 răspunde la o întrebare despre secunda curentă, în timp ce întrebarea pe care și-o pune omul cu adevărat privește noaptea trecută: de ce la trei dimineața totul s-a oprit și a revenit singur. În acel moment nu mai e nimic de privit, fiindcă nimic nu a fost consemnat. Să ridici Prometheus și Grafana pentru un singur VPS este o problemă în sine: stiva care observă cântărește mai mult decât serverul observat.
Un colector adaugă în baza de date o linie la fiecare cinci minute, iar această pagină desenează din ele ultimele 24 de ore. Load average, încărcarea CPU cu I/O wait ținut separat, RAM și swap, traficul de rețea primit și trimis, citirile și scrierile discului, conexiunile TCP stabilite, procesele, umplerea partiției, inode-urile și descriptorii de fișier ca procent din limita lor, conexiunile MySQL. Totul pe o singură pagină și pe aceeași axă a timpului, astfel încât coincidențele se văd cu ochiul liber.
Aceste grafice merită citite în perechi. Un I/O wait ridicat cu un CPU liniștit înseamnă că serverul așteaptă discul, iar adăugarea de nuclee nu va ajuta. O swap care a urcat o dată și nu s-a mai întors la zero spune că vârful de memorie s-a produs deja, oricât de calm ar părea acum. Descriptorii de fișier apropiați de o sută la sută sunt o eroare too many open files cu câteva ore înainte să se producă. Iar pe majoritatea serverelor inode-urile se termină cu mult înaintea spațiului liber.