Storico del carico del server: 24 ore, 7 o 30 giorni (raccolta ogni 5 minuti)
| Processo | CPU % | RAM % |
|---|---|---|
| suricata | 9.5 | 10.7 |
| falco | 6.2 | 14.6 |
| clamd | 3.6 | 17.4 |
| crowdsec | 2.4 | 1.1 |
| php-fpm | 1.3 | 11.5 |
| Processo | CPU % | RAM % |
|---|---|---|
| mysqld | 15.0 | 9.2 |
| clamd | 10.5 | 3.1 |
| php-fpm | 7.9 | 10.2 |
| suricata | 5.2 | 17.2 |
| falco | 2.5 | 17.3 |
top risponde a una domanda sul secondo corrente, mentre la domanda che ci si pone davvero riguarda la notte passata: perché alle tre tutto si è bloccato per poi ripartire da solo. A quel punto non c'è più nulla da guardare, perché nulla è stato conservato. Installare Prometheus e Grafana per un solo VPS pone un problema a sé: lo stack che osserva pesa più del server osservato.
Un collettore aggiunge una riga al database ogni cinque minuti, e questa pagina ne disegna le ultime 24 ore. Load average, uso della CPU con l'I/O wait tenuto separato, RAM e swap, traffico di rete in entrata e in uscita, letture e scritture su disco, connessioni TCP stabilite, processi, riempimento della partizione, inode e descrittori di file in percentuale sul limite, connessioni MySQL. Tutto su una pagina sola e sullo stesso asse temporale, così le coincidenze si notano a occhio.
Questi grafici vanno letti a coppie. Un I/O wait alto con la CPU tranquilla significa che il server aspetta il disco, e aggiungere core non servirà. Uno swap salito una volta e mai tornato a zero dice che il picco di memoria è già avvenuto, per quanto ora sembri tutto calmo. I descrittori di file vicini al cento per cento sono un too many open files con qualche ora di anticipo. E sulla maggior parte dei server gli inode finiscono ben prima dello spazio libero.