Performances

Historique de la charge serveur : 24 heures, 7 ou 30 jours (collecte toutes les 5 minutes)

Load Average (1m)
1.22
CPU
11.8%
RAM
30.8%
ESTABLISHED
92
Processus
1 / 397
Load Average
CPU
Mémoire
Réseau (KB/s)
E/S disque (KB/s)
Connexions TCP
Disque et limites (%)
MySQL
Processus lors de la dernière mesure 01:27
ProcessusCPU %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 au pic de la journée 11.10 08:57 · load 2.00
ProcessusCPU %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

Historique de charge sans Prometheus ni Grafana

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.