Storico del carico del server: 24 ore, 7 o 30 giorni (raccolta ogni 5 minuti)
| Processo | CPU % | RAM % |
|---|---|---|
| crowdsec | 4.7 | 4.2 |
| clamd | 3.0 | 18.1 |
| mysqld | 1.9 | 11.9 |
| falco | 0.9 | 14.2 |
| apache2 | 0.6 | 0.7 |
| Processo | CPU % | RAM % |
|---|---|---|
| fail2ban-server | 9.0 | 17.5 |
| falco | 4.9 | 1.9 |
| clamd | 3.5 | 11.0 |
| crowdsec | 2.4 | 1.8 |
| mysqld | 1.4 | 4.5 |
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.