Conseil
Le mode guidé des conditions NRQL offre une expérience organisée pour la création de conditions NRQL d'infrastructure « hôte ne signalant pas » (HNR). Il s'agit de l'alternative préférée à la création de conditions d'infrastructure « aucun rapport d'hôte ».
Utilisez monitoring infrastructurela Host not reporting condition de pour vous avertir lorsque nous avons cessé de recevoir des données d'un infrastructure agent . Cette fonctionnalité vous permet d'alerter dynamiquement des groupes d'hôtes, de configurer la fenêtre de temps de cinq à 60 minutes et de profiter pleinement de la notification .
Caractéristiques
Vous pouvez définir des conditions basées sur les ensembles d'hôtes les plus importants pour vous et configurer un seuil approprié pour chaque ensemble d'hôtes filtré. L'événement Host not reporting se déclenche lorsque les données de l'agent d'infrastructure n'atteignent pas notre collecteur dans le délai que vous spécifiez.
Prudence
Si vous avez filtré votre condition Host Not Reporting à l'aide de tags ou d'étiquettes et que vous supprimez ensuite un tag ou une étiquette critique d'un hôte ciblé, le système ouvrira un événement d'alerte Host Not Reporting, car il considérera que cet hôte a perdu sa connexion.
La flexibilité de cette fonctionnalité vous permet de personnaliser facilement ce que vous souhaitez monitorer et quand notifier les personnes ou les équipes sélectionnées. De plus, la notification par courrier électronique comprend des liens pour vous aider à résoudre rapidement la situation.
Host not reporting condition | Features |
|---|---|
Que monitorer | Vous pouvez utiliser la barre de filtre d'entité pour sélectionner les hôtes que vous souhaitez monitorer avec la condition d'alerte. La condition s'appliquera également automatiquement à tous les hôtes que vous ajouterez à l'avenir et qui correspondent à ces filtres. |
Comment notifier | Les conditions sont contenues dans les politiques. Vous pouvez sélectionner une politique existante ou créer une nouvelle politique avec des notifications par e-mail à partir de l'UI de monitoring de l'infrastructure. Si vous souhaitez créer une nouvelle politique avec d’autres types de canal de notification, utilisez l’ UI. |
Quand notifier | Les adresses e-mail (identifiées dans la politique) seront notifiées automatiquement des événements d'alerte de seuil pour tout hôte correspondant aux filtres que vous avez appliqués, selon les préférences d'événement d'alerte de la politique. |
Où résoudre les problèmes | Le lien en haut de la notification par e-mail vous amènera à la page d'infrastructure Events centrée sur le moment où l'hôte s'est déconnecté. Des liens supplémentaires dans l'e-mail vous mèneront à des détails supplémentaires. |
Créer une condition « hôte ne signalant pas »
Pour définir les critères de condition Host not reporting :
- Créer une condition d'infrastructure.
- Pour le Alert type, sélectionnez Host not reporting.
- Définissez le seuil Critical de déclenchement d'une notification : entre 5 et 60 minutes de non-réponse de l'hôte.
- (Facultatif) Activez l'option Don't trigger alerts for hosts that perform a clean shutdown pour empêcher les fausses alertes lorsque les hôtes sont intentionnellement arrêtés via la ligne de commande. Cette option est actuellement prise en charge sur les systèmes Windows et Linux basés sur systemd.
Conseil
Pour éviter de faux événements d'alerte "Host not reporting" concernant des hôtes arrêtés intentionnellement, envisagez les stratégies suivantes :
- tag l'hôte : Ajoutez la tag
hostStatus: shutdownoutermination: expectedà l'entité hôte. En savoir plus sur la balise. - Taguez l'hôte et activez le paramètre Don't trigger alerts : ajoutez le tag
hostStatus: shutdownà votre hôte et cochez l'option mentionnée ci-dessus. Cela empêchera l'ouverture de tous les événements d'alerte Host not reporting pour cet hôte, tant que ce tag y est présent, indépendamment de la version de l'Agent ou de l'OS. Si vous supprimez l'étiquette, New Relic commencera à ouvrir des événements d'alerte Host not reporting.
Selon les préférences d'événement d'alerte de la politique, elle définit les canaux de notification à utiliser lorsque le seuil Critical défini pour la condition est franchi. Pour éviter les "faux positifs", l'hôte doit cesser d'émettre pendant toute la période précédant l'ouverture d'un événement d'alerte.
Example: Vous créez une condition pour ouvrir un événement d'alerte lorsque l'un des hôtes de l'ensemble filtré cesse de signaler des données pendant seven minutes.
- Si un hôte cesse d'émettre pendant cinq minutes, puis recommence à émettre, la condition does not ouvrir un événement d'alerte.
- Si un hôte cesse d'émettre pendant sept minutes, même si les autres sont opérationnels, la condition does ouvre un événement d'alerte.
Enquêter sur le problème
Pour analyser plus en détail pourquoi un hôte ne signale pas de données :
- Consultez les détails dans la notification par e-mail.
- Utilisez le lien de la notification par e-mail pour monitorer les modifications en cours dans votre environnement à partir de la page Events dans notre interface utilisateur d'infrastructure. Par exemple, utilisez la page Events pour déterminer si un hôte s'est déconnecté juste après qu'un utilisateur root a apporté une modification de configuration à l'hôte.
- Facultatif : utilisez le lienAcknowledge de la notification par e-mail pour confirmer que vous avez pris connaissance de l'événement d'alerte et que vous le prenez en charge.
- Utilisez les liens de l'e-mail pour consulter des détails supplémentaires sur la pageAlert event details .
Pannes intentionnelles
Nous pouvons faire la distinction entre les situations inattendues et les situations planifiées avec l'option Don't trigger alerts for hosts that perform a clean shutdown. Utilisez cette option dans des situations telles que :
- L'hôte a été mis hors ligne intentionnellement.
- L'Hôte a prévu des temps d'arrêt pour l'entretien.
- L'Hôte a été fermé ou mis hors service.
- Mise à l'échelle automatique des hôtes ou arrêt de l'instance dans une console cloud .
Nous nous appuyons sur les signaux d’arrêt de Linux et de Windows pour signaler un arrêt propre.
Nous avons confirmé que ces scénarios sont détectés par l'agent :
- Événement de mise à l'échelle automatique AWS avec des instances EC2 qui utilisent systemd (Amazon Linux, CentOs/RedHat 7 et plus récent, Ubuntu 16 et plus récent, Suse 12 et plus récent, Debian 9 et plus récent)
- arrêt du système Windows initié par l'utilisateur
- arrêt initié par l'utilisateur du système Linux qui utilise systemd (Amazon Linux, CentOs/RedHat 7 et plus récent, Ubuntu 16 et plus récent, Suse 12 et plus récent, Debian 9 et plus récent)
Nous savons que ces scénarios ne sont pas détectés par l'agent :
- arrêt initié par l'utilisateur du système Linux qui n'utilise pas systemd (CentOs/RedHat 6 et antérieurs, Ubuntu 14, Debian 8). Cela inclut d'autres systèmes Linux modernes qui utilisent encore le système d'initialisation Upstart ou SysV.
- Événement de mise à l'échelle automatique AWS avec des instances EC2 qui n'utilisent pas systemd (CentOs/RedHat 6 et antérieurs, Ubuntu 14, Debian 8). Cela inclut d'autres systèmes Linux plus modernes qui utilisent toujours le système d'initialisation Upstart ou SysV.