Vérifications et politiques

Une vérification combine une commande et sa configuration. La vérification est exécutée sur les Agent Client Collectorappareils de pour collecter des données à partir de ces derniers.

Vérifications

Diverses 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 vos applications. Le nom par défaut d'une vérification indique les éléments surveillés et mesurés, 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 lors de la vérification s'exécute sur l'appareil surveillé, fournissant une sortie et un état. Chaque vérification individuelle est appelée définition de vérification. Une fois 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 répondre à vos besoins. Par exemple, personnalisez l'intervalle d'exécution ou les paramètres propres à la politique, notamment 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, elle n'a aucune incidence sur 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érifications suivants sont fournis avec le système de base Gestion des événements :

• Événement : le résultat de la vérification est converti en événement Gestion des événements.
• Mesure : les valeurs du résultat de la vérification sont converties en mesures.

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

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

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

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é automatiquement lorsque le processeur d'un appareil est trop élevé. Dans ce cas, la collecte de données de l'agent est définie sur l'état Désactivé (automatique). Passez en revue les journaux des agents pour déterminer les vérifications problématiques. Vous pouvez désactiver manuellement les vérifications problématiques ou modifier les seuils du mode de protection du processeur dans le fichier acc.yml de l'agent, et reprendre manuellement la collecte de données pour l'agent. 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 la collecte d'événements d'Agent Client Collector.

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 (par exemple, MAJEURE et MINEURE) en exécutant un script personnalisé. Les états de sortie suivants indiquent ces gravités :

• 13 = MAJEURE
• 14 = MINEURE

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 les autorisations sudo. Assurez-vous que les conditions de configuration sudo suivantes sont remplies :
  • Désactiver les exigences tty et de mot de passe
  • Conserver toutes les variables d'environnement
  • Prendre en charge le chemin 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 des commandes peuvent varier. Consultez le manuel sudoers pour des considérations particulières.

  • La chaîne SETENV: permet à l'utilisateur ServiceNow de préserver les variables d'environnement.
  • La chaîne !requiretty désactive tty.
  • L'ajout de l'utilisateur ServiceNow au groupe exempt_group contourne les exigences en matière de mot de passe et active le chemin dynamique pour l'exécution des commandes sudo.

  Veillez à définir le paramètre de vérification must_sudo sur vrai dans la section des 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 disposant de 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 Agent Client Collector et des définitions de vérification qui s’exécutent sur ces CI.

Pour permettre à une seule stratégie de prendre en charge plusieurs informations d’identification, affectez un alias d’informations d’identification à la stratégie. 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 met ensuite en correspondance les informations d'identification pertinentes avec 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 à l'origine de l'alerte
• Suppression de la vérification de la politique
• Suppression de la politique
• Modification du filtre de politique qui détermine les CI surveillés