Choisissez les alertes que vous recevez

Un guide des alertes qu'InfraNest peut vous envoyer concernant vos serveurs, et comment choisir celles que vous voulez.

Vue d'ensemble

• Les paramètres d'alerte par défaut forment une liste toute prête de tout ce qu'InfraNest peut vous signaler, chacune avec un interrupteur à côté.
• Activez ce que vous souhaitez. Chaque serveur surveillé suit le paramètre que vous choisissez, mais un serveur donné peut recevoir des valeurs différentes sans affecter les autres.
• Il n'y a rien à créer — la liste est complète, et chaque alerte démarre avec une valeur raisonnable afin que vous n'ayez pas besoin de connaître le seuil adéquat avant de l'activer.

Activer une alerte

1. Allez dans Monitoring et choisissez Alert defaults.
2. Trouvez l'alerte souhaitée et actionnez son interrupteur. C'est toute l'étape — elle s'enregistre immédiatement, et chaque serveur surveillé commence à la suivre.

La liste est regroupée en quatre questions :

• La machine est-elle en difficulté ? — CPU, mémoire, espace disque et charge moyenne.
• Quelque chose est-il cassé ? — un service en échec, un service ou conteneur qui redémarre sans cesse, un processus que le serveur a arrêté par manque de mémoire, et un serveur devenu silencieux.
• Est-ce à jour ? — mises à jour de sécurité en attente, un redémarrage que le serveur doit terminer pour finaliser les mises à jour, et un abonnement Ubuntu Pro qui ne couvre plus un serveur.
• Le trafic est-il inhabituel ? — débit réseau et disque. La plupart des gens laissent ces alertes désactivées tant qu'ils ne savent pas à quoi ressemble la normale pour un serveur donné.

Modifier une valeur

1. Trouvez le nombre dans la phrase sous le nom de l'alerte.
2. Cliquez dessus, saisissez une nouvelle valeur, puis appuyez sur Entrée ou cliquez ailleurs.

Il n'y a pas de bouton d'enregistrement ni rien à ouvrir — tout s'enregistre au fur et à mesure.

Deux valeurs par alerte :

• Le seuil — jusqu'où la mesure doit monter.
• Les minutes — combien de temps elle doit y rester avant que quelqu'un soit prévenu.

TipUne durée très courte transforme chaque pic bref en alerte, et les alertes auxquelles personne ne peut réagir sont celles que l'on finit par ignorer. Dix minutes est un bon point de départ pour la plupart des cas.

Si votre forfait enregistre les mesures moins fréquemment que la fenêtre choisie, InfraNest ne vous laissera pas définir une fenêtre trop courte pour être évaluée — la règle ne se déclencherait tout simplement jamais.

La pression CPU, mémoire et E/S mesure quelque chose que la charge ne peut pas montrer : combien de temps par minute les programmes ont passé à attendre — un processeur, de la mémoire libérée, ou le disque. La pression mémoire est souvent le premier signe qu'un serveur est sur le point de manquer de ressources, avant que quoi que ce soit ne soit arrêté ; la pression E/S révèle un disque lent avant tout autre indicateur. Ces mesures sont nouvelles, donc leurs valeurs de départ sont approximatives — ajustez-les une fois que vous avez observé ce qui est normal pour vos serveurs. Elles nécessitent la version 0.14 ou ultérieure de l'agent et un noyau Linux raisonnablement récent.

La charge est définie par cœur de CPU. La charge compte le travail en attente d'un processeur, donc le même chiffre signifie des choses différentes sur un petit et un grand serveur : 2 correspond à un serveur à deux cœurs entièrement occupé, et à un serveur à huit cœurs occupé au quart. Une limite de 1,0 par cœur signifie « chaque cœur occupé », quel que soit le serveur, donc un seul paramètre convient à toute votre flotte. InfraNest utilise le nombre de cœurs rapporté par l'agent, ou celui du forfait de votre fournisseur, et l'alerte indique les deux : « limite 8 (1 par cœur × 8 cœurs) ». Si aucun des deux n'est connu, le serveur est considéré comme n'ayant qu'un seul cœur.

Le serveur est devenu silencieux a son propre minimum, pour la raison inverse. L'agent se manifeste selon le calendrier de votre forfait, donc entre deux pointages parfaitement normaux, un serveur sain peut rester silencieux quelques minutes. La valeur la plus courte que vous puissiez définir est donc cinq minutes, ou trois pointages manqués sur un forfait qui rapporte moins souvent (quinze minutes quand il rapporte toutes les cinq minutes). Si une limite plus courte avait été définie auparavant, ou si votre forfait a changé depuis, l'alerte attend ce minimum de toute façon, et la page affiche la valeur réellement utilisée.

Un disque qui manque de fichiers plutôt que d'espace

Manque d'inodes surveille quelque chose que l'alerte d'espace disque ne peut pas voir. Chaque fichier sur un disque utilise un inode, et la plupart des disques en ont un nombre fixe. Un disque rempli de petits fichiers — files d'attente de courrier, sessions PHP, répertoires de cache — peut tous les épuiser alors qu'il reste encore des gigaoctets libres, et à partir de là il refuse tout nouveau fichier alors que le chiffre d'espace disque indique que tout va bien. Cette alerte se déclenche quand le disque le plus plein, compté en fichiers, reste au-dessus de 90 %. La carte Disque du serveur affiche ce chiffre sous un disque dès qu'il est rempli à moitié.

Certains systèmes de fichiers, comme btrfs, n'ont pas de nombre fixe d'inodes et ne manquent jamais de cette façon ; sur ceux-ci, l'alerte reste silencieuse. Elle nécessite la version 0.13 ou ultérieure de l'agent.

Un disque qui sera bientôt plein

Un disque sera bientôt plein répond à la question que le pourcentage d'espace disque ne fait que suggérer : non pas « à quel point est-il plein » mais « quand sera-t-il plein ». InfraNest observe la vitesse à laquelle chaque disque s'est rempli au cours de la dernière semaine — la même prévision qu'affiche la carte Disque du serveur — et vous prévient une fois lorsqu'un disque est en voie d'être plein dans le nombre de jours que vous avez choisi (une semaine, au départ). Un grand disque qui reste à 88 % pendant des mois reste silencieux ; un petit disque qui se remplit de quelques pourcents par jour est détecté alors qu'il reste encore le temps d'agir. Quand le disque arrête de se remplir, ou ralentit bien en deçà de votre limite, vous en êtes également informé.

Cela nécessite l'agent, qui conserve l'historique par disque dont la prévision est tirée.

Mises à jour et redémarrages

Les deux alertes sous Est-ce à jour ? fonctionnent un peu différemment des autres, car ce qu'elles surveillent peut légitimement prendre du temps.

• Des mises à jour de sécurité sont en attente est mesurée en heures : « plus de 0, pendant 24 heures » au départ, et elle se résorbe dès que le serveur est corrigé. Sur un serveur qui installe les mises à jour par lui-même, certaines sont volontairement retenues pendant quelques jours, donc dans ce cas vous n'êtes prévenu qu'une fois les mises à jour en attente depuis une semaine. Cela signifie généralement que les mises à jour automatiques elles-mêmes se sont arrêtées.
• Un redémarrage est en attente est mesurée en jours. Vous êtes prévenu une fois, quand un serveur attend un redémarrage depuis plus longtemps que le nombre de jours que vous avez choisi — une semaine, au départ. Un redémarrage survenant dans ce délai, comme le redémarrage nocturne automatique que font de nombreux serveurs Ubuntu, n'envoie rien du tout. La page du serveur affiche un redémarrage en attente dès qu'il apparaît. Si le serveur redémarre de lui-même après les mises à jour, vous êtes prévenu le lendemain matin s'il aurait dû redémarrer et ne l'a pas fait. La page du serveur montre comment c'est configuré, sous Automatic updates.

Des mises à jour de sécurité sont en attente repose sur des informations que seuls Debian et Ubuntu conservent sur eux-mêmes, donc sur d'autres systèmes elle reste silencieuse. Un redémarrage est en attente fonctionne sur tout serveur Linux avec un agent à jour, et les serveurs Windows le signalent aussi, via Windows Update. Arch fait exception : il supprime les fichiers du noyau en cours d'exécution lors d'une mise à jour, donc l'alerte y reste silencieuse.

Quand une grappe RAID perd un disque

Les serveurs dédiés conservent généralement leurs données sur deux disques à la fois (RAID 1 logiciel), afin qu'un disque puisse tomber en panne sans rien perdre. Une grappe RAID a perdu un disque vous informe quand une grappe fonctionne avec moins de disques que prévu depuis un quart d'heure, puis à nouveau quand elle est de nouveau complète. Si un disque de remplacement est déjà en cours de reconstruction, le message indique son avancement. La carte Système du serveur liste chaque grappe sous RAID.

Les serveurs sans RAID logiciel — la plupart des serveurs cloud — n'ont rien à signaler, et l'alerte reste silencieuse. Elle nécessite la version 0.14 ou ultérieure de l'agent.

Quand l'horloge d'un serveur arrête de se synchroniser

L'horloge a arrêté de se synchroniser vous informe quand un serveur dont l'horloge était maintenue synchronisée ne l'est plus depuis une demi-heure. La carte Système du serveur affiche l'état de l'horloge sous Clock.

Certains serveurs ne signalent jamais leur horloge comme synchronisée, et c'est normal — la plateforme d'hébergement maintient elle-même l'heure correcte. Cette alerte ne concerne qu'un serveur déjà vu synchronisé au moins une fois, donc ceux-là restent silencieux. Elle nécessite la version 0.14 ou ultérieure de l'agent.

Quand Ubuntu Pro cesse de couvrir un serveur

Ubuntu Pro a expiré vous informe quand un serveur qui était rattaché à Ubuntu Pro ne l'est plus. Livepatch et les mises à jour de sécurité supplémentaires (ESM) s'arrêtent à ce moment-là, et le serveur lui-même ne le signale nulle part.

Vous êtes prévenu une fois que le serveur est privé d'Ubuntu Pro depuis le nombre de minutes que vous avez choisi (une heure, au départ). Quand le serveur est à nouveau couvert, vous recevez un message de fin d'alerte. Les serveurs qui n'ont jamais eu Ubuntu Pro ne sont pas concernés.

La carte System du serveur montre la même chose : si le serveur est rattaché, et si Livepatch et ESM sont actifs. Cela nécessite la version 0.11.0 ou ultérieure de l'agent.

Quand un serveur manque de mémoire

Le serveur a manqué de mémoire vous informe quand un serveur est descendu si bas en mémoire qu'il a dû arrêter un programme pour continuer à fonctionner. Le graphique de mémoire ne peut pas montrer cela — arrêter le programme est précisément ce qui a libéré la mémoire, donc la mesure suivante paraît saine.

Vous êtes prévenu une fois, même si plusieurs programmes sont arrêtés à la suite. Quand plus rien n'a été arrêté depuis le nombre de minutes que vous avez choisi (une heure, au départ), vous recevez un message de fin d'alerte. L'e-mail vous indique la commande à exécuter sur le serveur pour voir quel était ce programme.

La carte System du serveur affiche également le nombre de programmes arrêtés de cette façon depuis le dernier démarrage du serveur. Elle nécessite la version 0.10.0 ou ultérieure de l'agent.

Quand un service redémarre sans cesse

Un service redémarre sans cesse vous informe quand un service d'un serveur plante et redémarre continuellement. Elle démarre à 3 redémarrages en 15 minutes — les deux valeurs figurent dans la phrase et vous pouvez les modifier. Seuls les redémarrages effectués par le serveur lui-même sont comptabilisés.

Vous êtes prévenu une fois, avec le nom du service et le nombre de fois qu'il a redémarré. Quand rien n'a redémarré pendant la durée de la fenêtre, vous recevez un message de fin d'alerte. Un service que vous avez choisi d'ignorer sur un serveur ne déclenche pas cette alerte.

Quand un conteneur redémarre sans cesse

Un conteneur redémarre sans cesse est la même alerte pour les conteneurs Docker et Podman, se déclenchant quand l'un d'eux redémarre 3 fois en 15 minutes, au départ. Vous pouvez modifier les deux valeurs.

L'alerte nomme le conteneur par son identifiant court plutôt que par son nom, car l'agent ne se connecte jamais à Docker lui-même. Vous êtes prévenu une fois, et recevez un message de fin d'alerte quand aucun conteneur n'a redémarré pendant la durée de la fenêtre. Les conteneurs ne peuvent pas encore être ignorés individuellement ; pour arrêter cette alerte sur un serveur, désactivez-la pour ce serveur.

Ce que surveille réellement chaque alerte

Chaque alerte activée indique à combien de serveurs elle s'applique — « On · 12 of 14 servers » — et chacune a une phrase indiquant exactement quand elle se déclenche.

NoteLes alertes marquées Needs agent surveillent quelque chose qu'aucun fournisseur cloud ne rapporte. Vous pouvez les activer pour l'organisation, mais elles ne se déclenchent que sur les serveurs où l'agent est installé. Sur un serveur qui ne l'a pas, l'alerte le signale sur la ligne et propose de l'installer immédiatement.

Modifier un seul serveur

1. Ouvrez le serveur depuis Monitoring → Servers.
2. Allez dans son onglet Alerts & rules.

Vous obtenez la même liste, montrant ce que fait réellement cette machine : Normal, Firing, ou désactivé. Un serveur qui a besoin d'un redémarrage affiche Waiting au lieu de Firing.

• Les alertes provenant de l'organisation sont marquées Org default.
• Modifiez une valeur ici et elle devient Changed here — seul ce serveur est affecté.
• Reset la remet à la valeur de l'organisation.
• Désactiver une alerte sur cette page la désactive uniquement pour ce serveur. Désactiver le paramètre par défaut la désactive partout.

Une alerte que votre organisation n'a pas du tout activée ne peut pas être activée pour un seul serveur à part — la ligne l'indique et renvoie vers ici.

Désactiver une alerte

1. Remettez l'interrupteur en position désactivée.

Rien n'est supprimé : les valeurs par serveur que vous avez définies sont conservées, et elles reprennent effet si vous réactivez l'alerte plus tard.