Storico del carico del server: 24 ore, 7 o 30 giorni (raccolta ogni 5 minuti)
| Processo | 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 |
| Processo | 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 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.