Vérifications et politiques

Une vérification combine une commande et sa configuration. La vérification est exécutée sur les Agent Client Collectorpériphériques de pour collecter les données de ces périphériques.

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 système Linux. 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.

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 vérifications par défaut d'Agent Client Collector Framework, consultez la rubrique Vérifications par défaut d'Agent Client Collector Framework.

Pour en savoir plus sur les vérifications et les politiques par défaut d'Agent Client Collector for Monitoring, consultez la rubrique Vérifications et politiques par défaut d'Agent Client Collector for Monitoring.

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

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

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 :

• Dans un système Linux : autorisez l'utilisateur ServiceNow à exécuter la commande avec les autorisations sudo. Vous devez respecter les exigences de configuration sudo suivantes :
  • 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
  Par exemple, vous pouvez configurer les éléments suivants 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 de commande peuvent varier. Consultez le manuel sudoers pour les 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 qui exécute le service d’agent appartient à un groupe d’utilisateurs disposant des privilèges nécessaires pour interroger toutes les connexions TCP sur l’hôte.
• Dans un Windows système : à l’aide de la gestion des utilisateurs Windows, ajoutez l’utilisateur ServiceNow aux groupes disposant des privilèges appropriés, ce qui permet à l’utilisateur d’exécuter les commandes requises.

Politiques

Une politique est un ensemble de CI et les définitions de vérification de ces CI.

Pour activer une seule politique pour prendre en charge plusieurs informations d'identification, vous devez attribuer un alias d'informations d'identification à la politique. Par exemple, si vous disposez de serveurs MySQL pour Linux et Windows avec des informations d'identification différentes, vous devez créer des politiques distinctes pour chaque type d'informations d'identification. En revanche, si vous utilisez un alias d'informations d'identification, vous pouvez attribuer une seule politique à l'alias d'informations d'identification. L'agent met ensuite en correspondance les informations d'identification pertinentes avec l'application surveillée. Pour plus d’informations 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 événement sont automatiquement fermées lorsque la surveillance des CI s'arrête via l'une des options suivantes :

• 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