Métriques et alertes serveur

Les métriques et alertes serveur vous montrent l’activité de chaque serveur — CPU, réseau, disque et plus encore — sous forme de graphiques, et peuvent vous avertir lorsqu’un problème persiste trop longtemps. C’est fait pour quiconque veut surveiller la santé de ses serveurs sans passer sa journée à fixer des graphiques.

#Vue d’ensemble

• Chaque serveur reçoit automatiquement des graphiques CPU, réseau et disque en direct, dès que la surveillance est activée pour lui.
• La mémoire, l’espace disque et la charge moyenne nécessitent l’installation de l’agent InfraNest, car la connexion de votre fournisseur ne les communique pas.
• Les alertes sont préconfigurées — rien à créer de zéro, juste des valeurs à ajuster si besoin.
• InfraNest signale également ce qui semble inhabituel, et propose une explication probable.

#Voir les métriques

1. Allez dans Monitoring → Servers pour voir tous les serveurs d’un coup d’œil.
2. Ouvrez un serveur pour accéder à sa propre page de surveillance, avec des graphiques CPU, réseau entrant/sortant et lecture/écriture disque en direct, ainsi que l’espace disque et ce qui est en cours d’exécution.

NoteLa surveillance doit être activée pour un serveur avant que quoi que ce soit ne soit collecté à son sujet. La mémoire, l’espace disque et la charge moyenne n’apparaissent qu’une fois l’agent installé — votre fournisseur ne les communique tout simplement pas.

#Lire l’onglet Metrics

1. Ouvrez un serveur et choisissez Metrics.
2. Choisissez une plage de temps en haut : 5 minutes, 1 heure, 12 heures, 24 heures, 7 jours ou 30 jours.
3. Lisez d’abord What stands out in this period — elle liste jusqu’à trois éléments méritant votre attention, comme une métrique ayant dépassé sa ligne d’alerte, un niveau inhabituellement élevé pour ce serveur, ou un changement coïncidant avec un déploiement ou un redémarrage.
4. Utilisez Compare with pour tracer une seconde ligne, en pointillés : Same time last week, ou un autre serveur ayant un rôle similaire.
5. Survolez n’importe quel graphique — tous les autres suivent, affichant leur valeur à ce même instant.
6. Cochez ou décochez Events, Alert lines et Normal range pour afficher ou masquer ces superpositions.

#Voir ce qui est inhabituel, et pourquoi

1. Ouvrez un serveur et choisissez Unusual.
2. Passez en revue la liste des éléments qui ne correspondent pas au schéma normal du serveur, chacun accompagné d’un petit graphique.
3. Vérifiez ce qu’InfraNest indique comme ayant précédé l’événement — marqué Known cause, Likely, ou Seen together, cause unclear.
4. Répondez Oui ou No, something else sous Is this the cause? pour entraîner InfraNest pour la prochaine fois. Choisissez None of them si rien ne correspond.
5. Utilisez Show on the chart ou Alert before it gets worse si vous souhaitez agir sur un constat.

#Mettre un serveur en veille pendant que vous y travaillez

1. Ouvrez le serveur depuis Monitoring → Servers.
2. Cliquez sur Silence 1h, ou ouvrez le menu ⋯ à côté et choisissez 4 hours ou 24 hours pour un travail plus long.
3. Cliquez sur End silence sur la page du serveur, ou choisissez-le depuis le menu ⋯ de la ligne, pour arrêter plus tôt.

NoteUne mise en veille se termine d’elle-même — il n’existe aucun moyen de mettre un serveur en veille indéfiniment. Les règles continuent d’être vérifiées et les graphiques continuent de se mettre à jour ; seules les notifications sont suspendues. Si une valeur dépasse toujours une limite à la fin de la mise en veille, vous en êtes informé à ce moment-là.

#Configurer une alerte

1. Allez dans Monitoring → Alert defaults et activez l’alerte souhaitée. Elle s’enregistre immédiatement et s’applique à tous les serveurs surveillés.
2. Pour donner des valeurs différentes à un serveur en particulier, ouvrez-le depuis Monitoring → Servers, allez dans son onglet Alerts & rules, cliquez sur le seuil ou les minutes dans la phrase sous l’alerte, saisissez une nouvelle valeur, puis appuyez sur Entrée ou cliquez ailleurs.

La durée est une fenêtre sur laquelle on fait une moyenne, pas un chronomètre, donc un pic d’une minute ne déclenchera pas l’alerte. Une fois une alerte déclenchée, la métrique doit redescendre clairement sous votre limite avant d’être marquée comme rétablie.

#Vérifier un seuil par rapport aux 30 derniers jours

1. Ouvrez l’onglet Alerts & rules d’un serveur.
2. Passez en revue les 30 derniers jours de chaque alerte — combien de fois elle se serait déclenchée, combien de fois elle s’est réellement déclenchée, et la valeur la plus élevée atteinte.
3. Si tous les déclenchements ont eu lieu au même moment, par exemple tous les dimanches à 03h00, cliquez sur Add a maintenance window for that time Pro pour la faire taire à l’avenir.
4. Si la carte suggère une meilleure valeur, cliquez sur Use pour l’appliquer immédiatement.

Pour l’espace disque, envisagez de cliquer sur Switch to a forecast alert pour être averti en fonction de la date à laquelle le disque sera plein, plutôt que d’un pourcentage qui avertit trop tôt ou trop tard.

#Ce qui vous est envoyé

Vous recevez au maximum deux messages par alerte : un lorsqu’elle se déclenche, et un lorsque la situation revient à la normale. Un pic trop court pour déclencher l’alerte n’envoie rien du tout — pas même un message de retour à la normale.

NoteCes incidents figurent aux côtés de vos incidents de surveillance de disponibilité, de sorte que la santé des serveurs et la disponibilité des services apparaissent au même endroit.

#Si vous installez l’agent

Rien ne change concernant les seuils, durées ou notifications — vous obtenez simplement davantage de métriques sur lesquelles écrire des règles, des relevés toutes les minutes au lieu de toutes les cinq minutes, et la possibilité d’une alerte pour un serveur qui cesse totalement de remonter des données. L’agent signale également les mises à jour de sécurité en attente, si un redémarrage est nécessaire, ainsi que le CPU, la mémoire et la taille disque réels du serveur.

#Lorsqu’un service échoue, nous vous disons pourquoi

Si vous avez installé l’agent, l’onglet Services liste ce qui tourne sur la machine et place tout élément en échec en haut, avec une raison en langage clair — par exemple Ran out of memory, Stopped with an error, ou Crashed.

Si vous avez activé l’alerte de service en échec, vous serez contacté avec le nom du service et du serveur. Lorsque tous les services surveillés fonctionnent à nouveau, les mêmes destinataires reçoivent un message le confirmant.

#Ignorer un service qui ne vous intéresse pas

1. Ouvrez la page de surveillance du serveur et allez dans l’onglet Services.
2. Sous Needs attention, trouvez le service et cliquez sur Ignore.
3. Pour reprendre les alertes à son sujet plus tard, retrouvez-le sous Ignored on this server et cliquez sur Stop ignoring.

#Voir les conteneurs d’un serveur

Si un serveur exécute Docker ou Podman, l’onglet Services liste également ses conteneurs, avec depuis combien de temps chacun a démarré, combien de fois il a redémarré, et quelle quantité de mémoire il utilise. Les conteneurs sont listés par leur identifiant court plutôt que par leur nom, car l’agent ne se connecte jamais directement à Docker.

#Voir pourquoi un service a échoué, à partir du journal système

1. Ouvrez le serveur, allez dans System, et sous What the agent reads here trouvez Why a service failed, from the system log.
2. Cliquez sur How to turn it on, copiez la commande, et exécutez-la sur le serveur.
3. En moins d’une minute, la ligne indique On.

À partir de là, un service en échec affiche ses dernières lignes de journal sur sa carte de problème — masquées pour les mots de passe et les clés, et conservées pendant 30 jours. Les enregistrements de connexion et les journaux complets ne sont jamais envoyés.

#Dépannage

• Une règle apparaît grisée sur un serveur — cette métrique (mémoire, espace disque, charge moyenne) nécessite l’installation de l’agent ; elle ne peut pas être mesurée via la seule connexion de votre fournisseur.
• Quelque chose de privé est apparu dans les lignes de journal d’un service — cliquez sur Something private got through? Remove these lines en dessous et confirmez. Changez également tout mot de passe exposé.
• Vous avez supprimé le dernier jeton d’agent — le serveur revient directement aux métriques fournisseur uniquement, et toute règle que seul l’agent pouvait mesurer cesse d’être mesurée.

TipUtilisez Silence 1h (ou plus longtemps) plutôt que de désactiver une alerte lorsque vous effectuez une maintenance planifiée qui ressemblera temporairement à un problème — elle se termine d’elle-même, vous ne risquez donc pas d’oublier de la réactiver.