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 d'une balise ou d'étiquettes, puis supprimez une tag ou une étiquette critique d'un hôte cible, le système ouvrira un incident Hôte Not Reporting, car il caractérisera cet hôte comme ayant 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 automatiquement notifiées du seuil d'incident pour tout hôte correspondant aux filtres que vous avez appliqués, en fonction des préférencesincident 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 un faux incident "Host not reporting" en cas d'arrêt intentionnel des hôtes, envisagez ces stratégies :
- tag l'hôte : Ajoutez la tag
hostStatus: shutdownoutermination: expectedà l'entité hôte. En savoir plus sur la balise. - balisez l'hôte et activez le paramètre Don't trigger alerts : Ajoutez la tag
hostStatus: shutdownà votre hôte tout en cochant l'option mentionnée ci-dessus. Cela empêchera tous les incidents Host not reporting de s'ouvrir pour cet hôte, tant que cette tag est dessus, quelle que soit la version de l'agent ou le système d'exploitation. Si vous supprimez la tag, New Relic commencera à ouvrir l'incident Host not reporting.
En fonction des préférencesincident de la politique, celle-ci définira le canal de notification à utiliser lorsque le seuil Critical défini pour la condition est dépassé. Pour éviter les « faux positifs », l'hôte doit cesser de signaler pendant toute la période précédant l'ouverture d'un incident .
Example: Vous créez une condition pour ouvrir un incident lorsque l'un des hôtes filtrés cesse de signaler des données pendant seven minutes.
- Si un hôte arrête de signaler pendant cinq minutes, puis reprend le signalement, la condition does not ouvre un incident.
- Si un hôte cesse de signaler pendant sept minutes, même si les autres vont bien, la condition does ouvre un incident.
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 vérifier que vous êtes au courant et que vous assumez la responsabilité de l'incident d'alerte.
- Utilisez les liens de courrier électronique pour examiner des détails supplémentaires sur la pageIncident 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.