Comment surveiller un serveur Linux
Guide pas à pas pour surveiller un serveur Linux — suivez le CPU, la RAM et le disque, surveillez la disponibilité et recevez des alertes avec Servor.
Surveiller un serveur Linux, c'est savoir en permanence deux choses : est-il en ligne et est-il en bonne santé ? Ce guide couvre les deux — les métriques qui comptent, comment suivre la disponibilité et comment être alerté dès qu'un problème survient — puis montre comment tout mettre en place dans Servor en quelques minutes.
Ce que « surveiller un serveur Linux » recouvre vraiment
Il y a deux tâches complémentaires, et une configuration complète assure les deux :
- Disponibilité (uptime) — les services de la machine sont-ils accessibles ? C'est la vue de l'extérieur : requêtes HTTP, ports ouverts, ping, DNS, certificats SSL.
- Santé des ressources — la machine elle-même est-elle sous tension ? C'est la vue de l'intérieur : charge CPU, utilisation mémoire, espace disque. Elle vous alerte avant la panne.
Sur un serveur Linux nu, vous assembleriez tout cela à partir d'outils comme top,
htop, df -h, uptime, plus quelque chose pour vérifier le service depuis
l'extérieur et quelque chose pour vous alerter. Servor réunit tout au même endroit.
Le classique instantané en ligne de commande
Sur le serveur lui-même, un contrôle rapide reste utile : uptime pour la charge
moyenne, free -h pour la mémoire, df -h pour le disque et top pour voir ce
qui consomme le CPU. Servor transforme ces instantanés ponctuels en un historique
continu et alertable.
Surveiller un serveur Linux avec Servor
Ajoutez le serveur
Ajoutez votre serveur en collant la commande d'installation en une ligne dans son shell. Cela installe l'agent léger ; une fois lancé, le serveur apparaît comme connecté. C'est la seule étape qui touche à SSH — voir qu'est-ce que SSH si vous voulez comprendre pourquoi. Ajouter un serveur dans Servor
Activez les métriques de ressources
Avec l'agent connecté, les métriques de ressources (CPU, RAM, disque) remontent automatiquement. Ouvrez le serveur pour voir les graphiques en direct et l'historique. Voir lire les métriques serveur pour comprendre les chiffres.
Ajoutez des moniteurs de disponibilité
Créez un moniteur pour chaque service de la machine. Utilisez un moniteur HTTP pour un site ou une API, un moniteur TCP/port pour une base de données ou un cache, et un moniteur certificat SSL pour être averti avant l'expiration d'un certificat. Créer un moniteur dans Servor
Définissez des alertes et un canal de notification
Configurez des alertes pour qu'un changement de statut vous parvienne réellement, et ajoutez un canal de notification — Email, Slack, Discord ou Webhook. Définissez un délai de garde (cooldown) pour qu'un service instable ne vous submerge pas. Ouvrir les réglages d'alertes dans Servor
Réglez les seuils de ressources
Dans les paramètres du serveur (icône engrenage → seuils de surveillance), définissez des limites raisonnables pour le CPU, la RAM et le disque afin d'être prévenu d'une machine sous tension, pas seulement d'une machine déjà tombée.
Que surveiller sur un serveur Linux
| Signal | Pourquoi c'est important | Dans Servor |
|---|---|---|
| Charge CPU | Une charge élevée soutenue signifie que la machine ne suit plus | Métriques de ressources |
| Mémoire (RAM) | Une montée constante trahit souvent une fuite ; le quasi-plein provoque du swap | Métriques de ressources |
| Espace disque | Un disque plein fait tomber les services brutalement et se rétablit lentement | Métriques de ressources |
| Réponse HTTP | Confirme que le service réel — pas seulement la machine — fonctionne | Moniteur HTTP |
| Ports ouverts | Confirme qu'une base, un cache ou une app écoute bien | Moniteur TCP/port |
| Expiration SSL | Évite l'avertissement de certificat que vos utilisateurs verraient en premier | Moniteur SSL |
| Taux de disponibilité | Le chiffre qui résume la fiabilité dans le temps | Statut des moniteurs |
Utilisez un contrôle par mot-clé
Un moniteur HTTP qui ne vérifie qu'un code 200 peut être trompé par une page
d'erreur qui renvoie tout de même 200. Ajoutez un contrôle par mot-clé pour
qu'une page qui se charge mais affiche une erreur compte bien comme hors ligne.
Lire les statuts
Chaque moniteur signale l'un de trois états : en ligne, dégradé ou hors ligne. Un état dégradé (réponses lentes, échecs partiels) est votre alerte précoce — prenez-le au sérieux avant qu'il ne devienne une panne complète. Voir statut des moniteurs pour savoir précisément comment chaque état est déterminé et comment le taux de disponibilité est calculé.
Bouclez la boucle
Détecter un problème n'est que la moitié du travail. Une fois la surveillance en place :
- Publiez une page de statut avec des composants liés à vos moniteurs pour que les utilisateurs voient la réalité automatiquement.
- Laissez les incidents automatiques s'ouvrir sur le passage hors ligne d'un moniteur, pour disposer d'une chronologie publique dès le début de la panne.
- Demandez au copilote IA d'enquêter sur un serveur signalé et de proposer un correctif — que vous approuvez avant qu'il ne s'exécute.
Si le serveur est « injoignable »
Les métriques de ressources proviennent de l'agent. Si le serveur devient injoignable, c'est que l'agent n'est pas connecté — les métriques se suspendent jusqu'à son retour. Utilisez Réparer l'agent plutôt que de vous reconnecter en SSH.