Superviser un serveur consiste à mesurer en continu son état interne — disque, mémoire, processeur, services — pour détecter une dégradation avant qu'elle ne devienne une panne. Voici les métriques qui comptent, les seuils à retenir et la manière de les collecter.
Elles couvrent la grande majorité des incidents serveur. Tout le reste est du raffinement.
Alerte à 85 %, critique à 95 %
La première cause de panne évitable. Un disque système plein bloque les écritures, les journaux et souvent la base de données. Surveillez la tendance autant que le pourcentage : un remplissage de 2 % par jour annonce la saturation avant que le seuil ne soit atteint.
Alerte sous 15 % disponible
Une mémoire saturée déclenche le recours au swap, et les temps de réponse s'effondrent bien avant que le service ne tombe. Sur Linux, surveillez la mémoire réellement disponible, pas la mémoire libre : le cache système fausse la lecture.
Alerte sur une moyenne soutenue
Un pic à 100 % est normal. Une charge élevée maintenue plusieurs minutes ne l'est pas. Alertez sur une moyenne prolongée plutôt que sur une valeur instantanée, sans quoi vous générerez du bruit à chaque sauvegarde.
Contrôle continu
Un serveur qui répond au ping avec son service applicatif arrêté est considéré comme disponible par un contrôle réseau simple. Surveillez l'état des services eux-mêmes, ainsi que les redémarrages inattendus.
Les vérifications réseau externes indiquent seulement qu'un service répond. Pour connaître l'état interne — disque, mémoire, services — un agent doit être installé sur la machine. C'est un service léger, de quelques dizaines de mégaoctets en mémoire.
En mode actif, l'agent se connecte lui-même au serveur de supervision et pousse ses données. Aucun port entrant n'est à ouvrir, ce qui fonctionne derrière un NAT, entre plusieurs sites ou vers le cloud.
Par défaut, les métriques transitent en clair. Dès que le trafic sort de votre réseau, utilisez une clé pré-partagée distincte par machine : une clé unique partagée sur tout le parc annule une grande partie du bénéfice.
Un seuil trop sensible produit des alertes que plus personne ne lit, et une alerte ignorée ne sert à rien. Observez une à deux semaines de données réelles avant de fixer les valeurs définitives.
Procédures complètes, utilisables avec n'importe quel serveur Zabbix.
La démarche ci-dessus suppose un serveur de supervision à installer, une base de données à dimensionner, des templates à configurer et des seuils à régler. Logiserv s'appuie sur le moteur Zabbix et prend en charge cette partie : vous installez un agent en une commande, les templates sont appliqués selon le système détecté et les tableaux de bord sont déjà en place.
Le moteur open source de référence, opéré et mis à jour par Logiserv.
Dashboards préconfigurés, accessibles sans installation ni compte séparé.
Debian, Ubuntu, RHEL, Rocky Linux, AlmaLinux et Oracle Linux sont reconnus automatiquement par le script d'installation.
Chaque agent reçoit une clé pré-partagée unique. Aucune métrique ne transite en clair.
Aucun port entrant à ouvrir : l'agent travaille en mode actif.
139 déclencheurs d'alerte préréglés, dont la détection d'anomalies système et réseau.
Une commande à coller, et les premières métriques remontent en quelques minutes.
Les points qui reviennent le plus souvent avant de mettre en place une supervision.
Quatre familles suffisent à couvrir la majorité des incidents : l'espace disque et sa vitesse de remplissage, la mémoire disponible, la charge processeur sur la durée, et la disponibilité des services critiques. La saturation disque reste la première cause de panne évitable.
Pour les métriques système détaillées (mémoire, disques, services, journaux), oui : un agent est nécessaire. Certaines vérifications réseau comme la disponibilité d'un port ou d'une page web peuvent se faire sans agent, mais elles ne disent rien de l'état interne de la machine.
Oui. Zabbix fournit un agent pour Windows, Linux et macOS, avec des templates adaptés à chaque système. Un parc mixte se supervise depuis une interface unique, sans doubler les outils.
Pas si l'agent fonctionne en mode actif : il se connecte lui-même au serveur de supervision et pousse ses données. Seul le trafic sortant est nécessaire, ce qui évite d'exposer les machines derrière un NAT ou un pare-feu restrictif.
L'installation manuelle d'un agent prend une dizaine de minutes par machine, en comptant la configuration et la création de l'hôte côté serveur. Avec une commande d'installation générée, l'agent s'enregistre seul et les premières métriques remontent en quelques minutes.
