Métriques de ressources (CPU, RAM, disque)

Pour chaque serveur connecté, Servor collecte des métriques de ressources — utilisation du CPU, de la RAM et du disque — directement depuis l'agent qui tourne sur la machine. Vous obtenez ainsi une vue en direct de la santé d'un serveur, aux côtés de sa disponibilité, pour repérer un disque qui se remplit ou un processus emballé avant qu'ils ne deviennent une panne.

Les métriques de ressources nécessitent un serveur connecté. Si vous n'avez pas encore installé l'agent, commencez par ajouter un serveur. Surveiller une simple URL (un moniteur HTTP) ne collecte pas ces données — elles proviennent de la machine elle-même.

Où les trouver

Ouvrez un serveur depuis la liste Serveurs — ouvrir les Serveurs dans Servor — pour voir ses métriques de ressources : utilisation actuelle et tendances dans le temps. Comme les métriques proviennent de l'agent, le serveur doit apparaître comme connecté. S'il est injoignable, les métriques cessent de se mettre à jour — voir réparer l'agent.

Ce que chaque métrique indique

Métrique	Ce qu'elle mesure	À surveiller
CPU	Charge du processeur, en % de la capacité	Usage élevé et durable — processus surchargé ou emballé
RAM	Mémoire utilisée vs totale	Constamment proche de 100 % — risque de swap ou d'OOM killer
Disque	Stockage utilisé vs disponible	Remplissage — un disque plein casse apps, logs et bases

CPU

L'utilisation du CPU montre à quel point le processeur travaille. Les pics brefs sont normaux — un build, une sauvegarde, une pointe de trafic. C'est l'usage élevé durable qui est le signal : la machine ne suit plus, les requêtes ralentissent, et le service peut glisser vers dégradé avant de passer down.

RAM

La mémoire montre la quantité de RAM utilisée. Quand une machine tourne en permanence proche du plein, l'OS se met à swapper sur le disque (lent) ou, au pire, tue des processus pour récupérer de la mémoire. Une mémoire qui monte sans jamais redescendre trahit souvent une fuite à investiguer.

Disque

L'utilisation du disque est celle qui provoque le plus souvent une panne surprise. Un disque se remplit discrètement de logs, d'uploads ou de la croissance d'une base, et lorsqu'il atteint 100 % les applications n'arrivent plus à écrire et peuvent planter. Surveillez la tendance, pas seulement le chiffre actuel — un disque qui grimpe de 1 % par jour vous dit quand vous serez à court.

Au-delà des métriques : ce qui tourne et la santé de la machine

L'onglet Surveillance ne se limite pas aux courbes. Quand l'agent est à jour, il fait aussi remonter un état des lieux du serveur — affiché en widgets qui n'apparaissent que si l'élément est présent, et que vous pouvez réorganiser (voir Composer votre tableau de bord) :

• Système : OS et version, noyau, architecture, vCPU, RAM, disque, mode de connexion.
• Exposition réseau : ce que la machine expose, et ce qui est censé l'en empêcher. Les ports en écoute (port, protocole, processus, nom du service pour les ports connus) — ceux joignables depuis l'extérieur d'abord — avec l'état du pare-feu (ufw, firewalld, nftables), ses règles telles que l'outil les imprime, et sa bascule pour les administrateurs. Pare-feu et ports formaient deux cartes distinctes, chacune ne racontant que la moitié de l'histoire : le pare-feu dit ce qui est autorisé, la liste des ports ce qui écoute réellement. La réponse utile est à leur croisement — un service lié à 0.0.0.0 derrière un pare-feu inactif est joignable ; le même service lié à 127.0.0.1 ne l'est pas, quoi que dise le pare-feu. Servor compare cette liste à celle du relevé précédent et vous alerte quand un port devient joignable depuis l'extérieur — soit qu'il apparaisse, soit, plus insidieux, qu'un service déjà en cours passe de 127.0.0.1 à 0.0.0.0. Dans ce second cas rien ne s'est « ouvert » : le service tournait, il a seulement cessé d'être privé, et c'est exactement le genre de dérive qu'on découvre le jour où quelqu'un d'autre la trouve. Un port qui n'écoute que sur la boucle locale ne déclenche rien, et le tout premier relevé d'une machine non plus — sinon chaque nouveau serveur alerterait sur toute sa surface.
• Ce qui tourne : les conteneurs Docker/Podman (état, health, ports publiés), les process pm2 (statut, redémarrages, CPU/mémoire), et les services détectés (nginx, PostgreSQL, Redis… — actif/inactif + version). Après une action depuis cet écran — arrêter un conteneur, redémarrer un service, basculer le pare-feu, appliquer des mises à jour — l'agent renvoie un relevé sans attendre son intervalle et l'écran se met à jour de lui-même en quelques secondes. Inutile de recharger la page.
• Santé du serveur : un résumé tricolore synthétisant les signaux — unités systemd en échec, redémarrage requis, pare-feu actif, horloge synchronisée, pression CPU/RAM/disque.
• TLS & domaines : les certificats détectés avec leurs jours restants, et les domaines branchés au serveur. k3s et les outils auto-hébergés (Coolify, Portainer) apparaissent s'ils sont là.

Agir sur un conteneur

Les conteneurs ne sont pas seulement listés : chaque tuile porte ses commandes — démarrer, arrêter et redémarrer s'appliquent immédiatement, tandis que mettre à jour l'image (pull) et supprimer demandent confirmation, l'une changeant ce qui démarrera ensuite et l'autre détruisant le conteneur.

La suppression n'est volontairement pas forcée : Docker refuse de supprimer un conteneur encore en cours d'exécution, et Servor conserve ce refus plutôt que de le contourner. Arrêtez le conteneur d'abord si c'est bien votre intention.

Une tuile de conteneur en cours d'exécution porte aussi un bouton shell, qui ouvre une session interactive dans le conteneur, directement dans la page. C'est sh qui est lancé, et non bash : c'est le seul shell que pratiquement toutes les images embarquent — les images alpine et slim n'ont souvent pas bash, et viser bash referme la session aussitôt. Tapez bash une fois à l'intérieur si l'image en dispose.

Chacune de ces actions est une commande comme une autre — signée dans votre navigateur, consignée dans votre historique des commandes et dans le journal d'audit. Pour lire ce qu'un conteneur écrit, voir Suivre les logs en direct.

Redémarrer ou éteindre la machine

Depuis l'onglet Surveillance, la carte Alimentation propose de redémarrer ou d'éteindre le serveur. C'est réservé aux administrateurs, protégé par un MFA renforcé, et confirmé en saisissant le nom du serveur — pas par un simple clic.

Ce niveau de friction est délibéré : c'est la seule action de Servor qu'aucun accès à distance ne rattrape. Si la machine ne revient pas, ni le terminal ni l'agent ne peuvent la rallumer — il faut passer par votre hébergeur, ou vous déplacer.

Agir sur un service

La carte Services détectés fonctionne de la même manière : démarrer, arrêter, redémarrer et recharger la configuration s'appliquent immédiatement, tandis qu'activer et désactiver au démarrage, masquer et démasquer demandent confirmation — les deux premières changent ce qui se lancera au prochain boot, et masquer rend l'unité impossible à démarrer, y compris comme dépendance d'un autre service.

Ces boutons n'apparaissent que pour les services que systemd supervise réellement. Servor détecte aussi les services lancés par pm2, supervisord ou un conteneur : ceux-là sont bien listés, mais sans boutons, parce que systemctl ne parle pas pour eux et que la commande échouerait à chaque fois.

Composer votre tableau de bord

Le bouton Personnaliser, en haut de l'onglet, fait passer la page en mode composition. Chaque widget reçoit alors une barre où vous pouvez :

• le déplacer, à la souris par la poignée, ou au clavier (Tab jusqu'à la poignée, Espace pour saisir, flèches pour déplacer, Espace pour poser) ;
• changer sa largeur — 1, 2 ou 4 colonnes. Un widget dont le contenu cesse d'être lisible en dessous d'une certaine largeur refuse les tailles trop étroites ;
• le retirer du tableau.

Les widgets retirés se retrouvent sous la grille et se rajoutent d'un clic. Réinitialiser rétablit la disposition par défaut.

Fixer des seuils

Les paramètres de chaque serveur (l'icône engrenage) incluent des seuils de surveillance pour ses ressources. Fixez un niveau — par exemple alerter quand le disque dépasse 85 % — pour qu'une métrique qui dérive vers le rouge devienne quelque chose dont on vous informe, plutôt que quelque chose que vous découvrez pendant un incident. Combinez les seuils avec les alertes et les canaux de notification pour que l'avertissement vous parvienne.

Deux réglages accompagnent chaque seuil et décident quand l'alerte part :

• Échantillons consécutifs — le nombre de relevés d'affilée au-dessus du seuil avant qu'une alerte parte. Un pic d'une seconde pendant une sauvegarde n'est pas une panne.
• Marge de retour — de combien de points la métrique doit redescendre sous le seuil avant qu'une nouvelle alerte puisse partir. Avec un seuil à 90 % et une marge de 5, l'alerte ne se réarme qu'une fois la valeur retombée à 85 % ou moins, sur autant d'échantillons consécutifs.

La marge de retour est ce qui empêche une machine qui tourne en permanence autour de son seuil de vous notifier à chaque oscillation. Mettez-la à 0 pour qu'une seule descente sous le seuil suffise à réarmer l'alerte.

Métriques vs moniteurs

Les deux se complètent :

• Les moniteurs répondent à « ce service répond-il ? » — voir types de moniteurs. Le type métrique agent fait le pont entre les deux : il pose un seuil, et donc une alerte, sur les valeurs de cette page.
• Les métriques de ressources répondent à « la machine elle-même est-elle saine à l'intérieur ? »

Un serveur peut être parfaitement up pour un moniteur HTTP alors que son disque est à 98 % — c'est la vue des ressources qui repère cela avant que ça ne tourne à la panne.

Étapes suivantes