Vérifications et politiques

Une vérification est une combinaison d’une commande et de sa configuration. La vérification est exécutée sur les Agent Client Collector appareils de pour collecter des données à partir de ces appareils.

Vérifications

Les vérifications sont fournies avec le système de base et leurs commandes exécutent des scripts qui fournissent des données de surveillance pour vos systèmes d’exploitation et applications. Le nom par défaut d’une vérification indique ce qui est surveillé et mesuré, l’entité et les données de surveillance. Par exemple, une vérification nommée os.linux.check-system-cpu vérifie les données du processeur sur un Linux système. La commande identifiée dans la vérification s’exécute sur l’appareil surveillé et fournit une sortie et un état. Chaque vérification individuelle est appelée définition de vérification. Après avoir été associées à des politiques, les définitions de vérification sont appelées instances de vérification.

Vous pouvez personnaliser les instances de vérification pour qu’elles répondent à vos besoins. Par exemple, personnalisez l’intervalle d’exécution ou les paramètres spécifiques à la stratégie, tels que les informations d’identification de connexion pour accéder à une base de données MySQL. La personnalisation d’une instance de vérification prend effet uniquement sur l’instance de vérification associée à la politique, ce qui n’affecte pas la définition de vérification d’origine ou les instances de vérification déjà créées dans d’autres politiques.

Les types de vérification suivants sont fournis avec le système de Gestion des événements base :

• Événement : le résultat du chèque est transformé en Gestion des événements événement.
• Mesure : les valeurs du résultat de la vérification sont transformées en mesures.

Pour en savoir plus sur les Cadre de travail d'Agent Client Collector contrôles par défaut, reportez-vous à la section Agent Client Collector Vérifications par défaut du cadre de travail.

Pour en savoir plus sur les contrôles et les Surveillance d'Agent Client Collector politiques par défaut, reportez-vous à la section Surveillance d'Agent Client Collector Vérifications et politiques par défaut.

Pour en savoir plus sur les contrôles et les Agent Client Collector pour Visibilité - Contenu politiques par défaut, reportez-vous à la section Agent Client Collector pour Visibilité - Contenu Vérifications et politiques par défaut.

Si des vérifications ne sont pas en cours d'exécution sur les appareils de l'agent, votre agent peut être en mode de protection du processeur. Le mode de protection du processeur est activé lorsque la consommation du processeur d’un appareil est trop élevée. Pour afficher une liste de toutes les vérifications désactivées liées à l’agent, accédez à l’enregistrement de l’agent sur la page Agent Client Collectors (Tous > Agent Client Collector > Agents), sélectionnez un agent et sélectionnez l’onglet Vérifications désactivées en bas de la page.

Dans le fichier de configuration acc.yml , vous pouvez modifier les seuils de mode de protection du processeur qui déterminent quand une vérification est désactivée. Pour réactiver une vérification, sélectionnez la vérification, puis sélectionnez Réactiver la vérification désactivée dans la liste déroulante Actions sur les lignes sélectionnées... Pour en savoir plus sur les seuils du mode de protection du processeur, consultez la rubrique Seuils de protection du processeur d'Agent Client Collector. Pour en savoir plus sur la désactivation manuelle de la collecte de données, consultez la rubrique Interrompre Agent Client Collector la collecte de données.

Configurez la propriété cpu_protection_behavior pour déterminer si toutes les vérifications entrent en mode de protection du processeur, ou uniquement la vérification qui croise la valeur de cpu_percentage_limit configurée avec l’utilisation de processeur la plus élevée pendant l’intervalle de surveillance. Pour plus de détails, voir Seuils de protection du processeur d'Agent Client Collector.

Une vérification est marquée comme périmée si elle n’est plus associée à une politique. Pour supprimer un chèque périmé, réactivez-le en cochant la case à côté du chèque et en sélectionnant Réactiver les contrôles désactivés dans la cellule Actions sur les lignes sélectionnées...

Dans le système de base, l'état de sortie de l'événement indique sa gravité, comme suit :

• 0 = OK
• 1 = AVERTISSEMENT
• 2 = CRITIQUE

Vous pouvez ajouter des gravités supplémentaires (telles que MAJOR et MINOR) en exécutant un script personnalisé. Les statuts de sortie suivants indiquent ces sévérités :

• 13 = MAJEUR
• 14 = MINEUR

Privilèges pour l’exécution des commandes de vérification

Si l’utilisateur du système de base ServiceNow ne dispose pas des privilèges nécessaires pour exécuter des commandes de vérification spécifiques, procédez comme suit pour les systèmes d’exploitation concernés :

• Dans un système Linux : Autorisez l’utilisateur ServiceNow à exécuter la commande avec des autorisations sudo . Assurez-vous que les conditions requises de configuration sudo suivantes sont remplies :
  • Désactiver les exigences de tty et de mot de passe
  • Conserver toutes les variables d’environnement
  • Prendre en charge le chemin d’accès dynamique pour l’exécution des commandes
  Exemple de configuration dans le fichier /etc/sudoers :

  Cmnd_Alias ACC_F = /usr/sbin/dmidecode -s baseboard-serial-number, /usr/sbin/dmidecode -s chassis-serial-number, /usr/sbin/dmidecode -s system-serial-number, /usr/sbin/dmidecode -s system-uuid, /usr/sbin/ss -tanp 
  servicenow ALL=(root) SETENV: /var/cache/servicenow/agent-client-collector/osquery/bin/osqueryi *, ACC_F
  Defaults:servicenow !requiretty
  Defaults exempt_group += servicenow
  

  Remarque :

  Les chemins d’accès aux commandes peuvent varier. Consultez le manuel sudoers pour des considérations particulières.

  • La chaîne SETENV : permet à l’utilisateur ServiceNow de conserver les variables environnementales.
  • La chaîne !requiretty désactive tty.
  • L’ajout de l’utilisateur ServiceNow au exempt_group contourne les exigences de mot de passe et active PATH dynamique pour l’exécution des commandes sudo.

  Assurez-vous de configurer le must_sudo paramètre de vérification avec la valeur vrai dans la section Paramètres de commande de vérification de la définition de vérification.

• Dans un MacOS système : assurez-vous que l’utilisateur exécutant le service d’agent appartient à un groupe d’utilisateurs avec des privilèges pour interroger toutes les connexions TCP sur l’hôte.
• Dans un Windows système : à l’aide Windows de Gestion des utilisateurs, ajoutez l’utilisateur ServiceNow aux groupes disposant des privilèges appropriés, ce qui lui permet d’exécuter les commandes requises.

Exécution des vérifications dont l’heure d’exécution a manqué

Une vérification ne s’exécute pas si l’ordinateur portable ou l’agent est en panne pendant l’heure d’exécution planifiée. Lorsque cela se produit, le comportement du système dépend de l’exécution précédente de la vérification.

• Vérification qui n’a jamais été exécutée : la vérification s’exécute à l’heure de reconnexion de l’agent + X (où X = 0-60 minutes), et il s’agit de la durée d’exécution permanente de la vérification.

  Par exemple : la politique X a été synchronisée avec un agent. La case A de la politique n’a jamais été exécutée auparavant et devait s’exécuter à 2 heures du matin. Cependant, l’ordinateur portable dormait à ce moment-là. L’ordinateur portable se réveille à 9h09. Une fois l’agent restauré, il remarque que la vérification A ne s’est jamais exécutée. La vérification A est planifiée entre 9 h 09 et 10 h 09 et finit par s’exécuter à 9 h 54. L’intervalle de vérification A est toutes les 24 heures, la vérification A est donc maintenant planifiée pour s’exécuter quotidiennement à 9h54.

• Vérification qui a manqué une heure d’exécution existante : la vérification exécutée précédemment s’exécute à l’heure de reconnexion de l’agent + X (où X = 0-60 minutes), mais à l’avenir, la vérification revient à l’heure d’exécution initialement planifiée.

  Par exemple : Check A s’exécute une fois par jour et est programmé pour s’exécuter quotidiennement à 9h54. L’ordinateur portable dormait ou l’agent n’était pas connecté de 9h à 13h. À 13h17, l’ordinateur portable est réveillé et l’agent démarre et se connecte. L’agent a remarqué que la vérification A ne s’est pas exécutée à 9h54 et la prévoit entre 13h17 et 14h17. Le chèque finit par s’exécuter à 13h37. Cependant, la prochaine fois que la vérification A s’exécute est à 9h54, son heure initialement prévue.

  Ce scénario ne prend effet que pour les vérifications s’exécutant toutes les 60 minutes ou plus fréquemment. Les vérifications qui s’exécutent moins de toutes les 60 minutes s’exécutent à leur intervalle précédent.

Politiques

Une politique est une combinaison des CI surveillés par et Agent Client Collector des définitions de vérification qui s’exécutent sur ces CI.

Pour permettre à une seule politique de prendre en charge plusieurs informations d’identification, affectez un alias d’informations d’identification à la politique. Par exemple, si vous avez des serveurs MySQL pour les deux Linux et Windows avec des informations d’identification différentes, vous devez créer des stratégies distinctes pour chaque type d’informations d’identification. Toutefois, si vous utilisez un alias d’informations d’identification, vous pouvez affecter une seule politique à l’alias. L’agent fait ensuite correspondre les informations d’identification pertinentes à l’application surveillée. Pour en savoir plus sur les alias d’informations d’identification, consultez Créer un alias de connexion et d’informations d’identification.

Les alertes générées par les politiques avec une vérification de type d’événement sont automatiquement fermées lorsque la surveillance des CI s’arrête en raison de l’un des éléments suivants :

• Désactivation de la politique
• Désactivation de la vérification ayant provoqué l’alerte
• Suppression du chèque de la politique
• Suppression de la politique
• Modification du filtre de politique qui détermine les CI surveillés