Historique de la charge serveur : 24 heures, 7 ou 30 jours (collecte toutes les 5 minutes)
| Processus | CPU % | RAM % |
|---|---|---|
| apache2 | 13.4 | 4.7 |
| clamd | 9.8 | 5.3 |
| crowdsec | 6.6 | 9.6 |
| suricata | 4.7 | 0.9 |
| falco | 2.6 | 16.5 |
| Processus | CPU % | RAM % |
|---|---|---|
| falco | 19.5 | 5.3 |
| mysqld | 13.1 | 9.6 |
| fail2ban-server | 8.1 | 8.8 |
| crowdsec | 5.7 | 13.6 |
| apache2 | 3.5 | 11.0 |
top répond à une question sur la seconde en cours, alors que la question posée porte presque toujours sur la nuit passée : pourquoi tout s'est figé à trois heures du matin avant de repartir seul. À ce moment-là il n'y a plus rien à regarder, puisque rien n'a été conservé. Déployer Prometheus et Grafana pour un seul VPS pose son propre problème : la pile qui observe pèse plus lourd que le serveur observé.
Un collecteur ajoute une ligne en base toutes les cinq minutes, et cette page en trace les dernières 24 heures. Load average, charge CPU avec I/O wait à part, RAM et swap, trafic réseau entrant et sortant, lectures et écritures disque, connexions TCP établies, processus, remplissage de la partition, inodes et descripteurs de fichiers en pourcentage de leur limite, connexions MySQL. Le tout sur une seule page et sur le même axe de temps, si bien que les coïncidences se voient à l'œil nu.
Ces courbes se lisent par paires. Un I/O wait élevé avec un CPU calme signifie que le serveur attend le disque, et ajouter des cœurs n'y changera rien. Un swap qui a monté une fois sans jamais revenir à zéro indique que le pic mémoire a déjà eu lieu, même si tout paraît tranquille maintenant. Des descripteurs de fichiers proches de cent pour cent annoncent un too many open files quelques heures à l'avance. Et sur la plupart des serveurs, les inodes s'épuisent bien avant l'espace libre.