Surveiller un VPS avec des signaux qui mènent à une première réponse utile
La surveillance est utile lorsqu'elle change la décision suivante. Un serveur peut répondre au ping alors que l'application échoue, et un CPU chargé peut être normal pendant un travail prévu. Partez de ce dont les utilisateurs ont besoin, puis collectez suffisamment de preuves pour expliquer quand cette expérience change.
L'essentiel à retenir
Observez l'application de l'extérieur et ses contraintes de ressources de l'intérieur, comparez les changements à une référence, et donnez à chaque alerte urgente un responsable clair et une première action.
Définir la santé à partir d'un parcours utilisateur important
Choisissez un parcours applicatif qui compte : ouvrir une page publique, se connecter ou lire une ressource API représentative. Définissez à quoi ressemble un résultat réussi, y compris le contenu de la réponse et un délai d'achèvement raisonnable. Une réponse HTTP 200 contenant une page d'erreur ne doit pas compter automatiquement comme un succès. Gardez les vérifications synthétiques sûres et évitez de créer de vraies commandes ou d'envoyer des messages aux clients.
Exécutez une vérification externe depuis l'extérieur du VPS afin qu'elle puisse détecter les défaillances qu'un processus interne ne voit pas. Ajoutez des mesures internes de service et d'hôte pour expliquer la défaillance. Ensemble, elles répondent à deux questions différentes : un utilisateur peut-il mener sa requête à bien, et quelle partie du système est sous pression ? Aucune des deux vues ne remplace l'autre.
Documentez l'identité de la vérification, sa fréquence et les permissions attendues. Si elle utilise un compte, accordez à ce compte uniquement l'accès nécessaire au parcours synthétique. Surveillez si le système de surveillance lui-même collecte des données. Un graphique vide peut signifier une collecte manquante plutôt qu'un trafic nul, et ces deux situations exigent des premières actions différentes.
Construire un petit tableau de bord autour des symptômes et des contraintes
| Signal | Vue utile | Question à laquelle elle répond |
|---|---|---|
| Latence des requêtes | Requêtes réussies et échouées, y compris les percentiles plus lents | Quels utilisateurs attendent plus longtemps ? |
| Trafic | Requêtes, tâches ou connexions par intervalle | La demande ou le travail en arrière-plan ont-ils changé ? |
| Erreurs | Taux d'échec avec le nombre de requêtes sous-jacent | Quelle part du travail utile échoue ? |
| Saturation | CPU, mémoire disponible, pression sur le stockage et files d'attente | Quelle ressource peut limiter la progression ? |
| Changements opérationnels | Versions, changements de configuration et tâches planifiées | Qu'est-ce qui a changé près de l'apparition du symptôme ? |
Ne vous fiez pas à une latence moyenne seule. Un petit groupe de requêtes très lentes peut être masqué par de nombreuses requêtes rapides. Séparez les routes importantes ou les classes de charge sans attribuer une étiquette de métrique à chaque identifiant client. Gardez des mesures suffisamment stables pour comparer un mardi matin avec une période antérieure équivalente, plutôt que de mélanger un trafic sans rapport dans un seul chiffre rassurant.
Un graphique CPU a besoin du contexte applicatif. Une utilisation élevée pendant une tâche batch planifiée peut être attendue, tandis qu'une latence de requête croissante et une file d'attente en trafic normal peuvent indiquer un problème de capacité. De même, examinez la mémoire disponible et le comportement de l'application plutôt que d'interpréter tout le cache du système de fichiers comme une fuite. Recherchez une pression soutenue et les erreurs pertinentes avant de décider de redimensionner le serveur.
Choisissez des alertes sur lesquelles on peut agir
Une alerte urgente doit décrire un symptôme significatif et une réponse que le destinataire peut entamer. Un parcours applicatif externe en échec, soutenu sur plusieurs contrôles, diffère d'un pic CPU bref. Acheminez les travaux de capacité planifiés vers une file de revue lorsque l'interruption immédiate n'est pas nécessaire. Chaque alerte a besoin d'un responsable, d'un canal de notification fonctionnel et d'une courte note de diagnostic.
Les seuils relèvent de décisions de charge. Par exemple, une équipe peut enquêter lorsqu'une API habituellement rapide présente une latence au 95e percentile supérieure à 900 millisecondes pendant dix minutes, tout en recevant suffisamment de requêtes pour que la mesure soit utile. Il s'agit d'une politique illustrative, non d'une limite universelle ni d'une garantie de latence de HM Bastion. Confrontez les fausses alertes et les incidents manqués à l'impact réel sur les utilisateurs.
Les alertes de stockage doivent tenir compte de la vitesse à laquelle l'espace libre évolue. Vingt gigaoctets restants n'ont pas la même signification selon que la croissance est d'un gigaoctet par jour ou de dix gigaoctets par heure. Incluez la pression sur les inodes le cas échéant et distinguez une croissance applicative persistante d'un journal qui s'emballe. Préférez un avertissement de capacité précoce et exploitable plutôt que d'attendre que les écritures aient déjà échoué.
Utilisez la première passe de diagnostic pour isoler la couche défaillante
- Confirmez le symptôme depuis un emplacement indépendant et notez son heure de début.
- Vérifiez si DNS, l'établissement de la connexion, HTTPS ou la réponse applicative est en échec.
- Comparez les erreurs de requête et la latence avec le trafic et les marqueurs de changement les plus récents.
- Inspectez l'état du service concerné, les journaux récents bornés et la connectivité des dépendances.
- Comparez le comportement du CPU, de la mémoire, du stockage et des files d'attente avec la référence normale.
- Escaladez en indiquant la couche défaillante observée avant d'apporter des changements sans rapport.
Supposez que la page d'accueil fonctionne mais que les requêtes API renvoient 502 après une mise en production. Commencez par l'erreur du proxy et le processus applicatif ou la socket qu'elle référence, plutôt que de supposer un incident réseau plus large. Si tous les contrôles locaux passent mais que les requêtes externes expirent, examinez le chemin public et le point d'entrée en écoute. Ce sont des branches de diagnostic à vérifier, non des conclusions automatiques tirées d'un code de statut.
Sur un serveur Linux basé sur systemd, le journal peut être filtré sur l'unité concernée et l'intervalle de temps. Comparez-le avec les journaux applicatifs et du reverse proxy en utilisant des horodatages cohérents. Conservez assez de contexte pour relier une erreur à une requête, mais masquez les identifiants et les charges sensibles avant de partager des extraits. Un intervalle récent ciblé est généralement plus utile qu'une archive de journaux complète et non filtrée.
Examinez la couverture et transformez les preuves en décision de capacité
Les métriques décrivent des tendances, les journaux décrivent des événements particuliers et les traces peuvent montrer comment une requête passe du temps entre les composants. Introduisez la plus petite combinaison qui répond à vos questions actuelles. Un système de traçage élaboré apporte peu si personne ne reçoit l'alerte d'application indisponible ou si la tâche de sauvegarde n'a pas signalé de résultat exploitable depuis une semaine.
Après une mise en production ou un changement de charge significatif, confirmez que les contrôles exercent toujours le bon parcours et que la collecte fonctionne toujours. Utilisez des mesures soutenues pour décider si une correction applicative, une amélioration de requête, un changement de planification ou une allocation de ressources différente est justifiée. Gardez la coordination des incidents et la reprise de service dans une procédure distincte, afin que le tableau de bord reste un point de départ clair plutôt qu'un recueil de consignes d'urgence.
