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 les vérifications ne sont pas en cours d’exécution sur les appareils de l’agent, celui-ci est 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 la 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.

Si les vérifications ne sont pas en cours d’exécution sur les appareils de l’agent, celui-ci est peut-être en mode de protection du processeur. Le mode de protection du processeur est activé automatiquement lorsque la consommation du processeur d’un appareil est trop élevée. Lorsque cela se produit, l’état de la collecte de données de l’agent est Désactivé (automatique). Vérifiez les journaux de l’agent pour déterminer les vérifications problématiques. Vous pouvez désactiver manuellement les vérifications problématiques, ou vous pouvez modifier les seuils de mode de protection du processeur dans le fichier de acc.yml de l’agent et reprendre manuellement la collecte de données pour l’agent. Pour plus d’informations sur les seuils de mode de protection du processeur, reportez-vous à la section Agent Client Collector Seuils de protection du processeur. Pour plus d’informations sur la désactivation manuelle de la collecte de données, reportez-vous à la section Interrompre Agent Client Collector la collecte de donné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.

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