---
sourceDocument: Gestion des opérations IT Xanadu
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/fr-FR/xanadu/it-operations-management

 Release :

    - xanadu

ft:locale :

    - fr-FR

ft:publication_title :

    - Gestion des opérations IT Xanadu

ft:clusterId :

    - itom

bundleId :

    - itom

workflow :

    - Technology


---

# Vérifications et politiques

# Vérifications et politiques {#ariaid-title1}

* Rversion finale: Xanadu
* 
* Mis à jour 1 août 2024
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes de lecture

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 {#checks-policies__section_j2b_5hb_rwb}

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.

{#checks-policies__ul_omn_1rr_rjb}

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](https://servicenow-prod.fluidtopics.net/D7SdHMbFCrrlCaFbwyxffg "Agent Client Collector Framework fournit des vérifications par défaut avec le système de base.").

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](https://servicenow-prod.fluidtopics.net/73dkFTRq3KuFFArHWhjPFw "Agent Client Collector for Monitoring fournit diverses vérifications et politiques par défaut.").

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é](https://servicenow-prod.fluidtopics.net/AmXnWeLpU2GgjdW~106epQ "Agent Client Collector pour Visibilité fournit diverses vérifications et politiques, ainsi qu’une règle métier.").

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](https://servicenow-prod.fluidtopics.net/kDrHyNwRXbT2bkzoQsnq~Q "Lorsque Agent Client Collector les vérifications consomment trop de processeur, le met en pause sa Agent Client Collector collecte de données et passe en mode de protection du processeur. L'agent passe en mode de protection du processeur lorsqu'il répond à tous les seuils configurés spécifiés dans le fichier acc.yml de l'agent. Vous pouvez modifier les seuils de ce paramètre selon vos besoins. Les agents en mode de protection du processeur apparaissent dans les journaux des agents avec la syntaxe Protection de l’agent."). 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](https://servicenow-prod.fluidtopics.net/F0iCQPtT2JPZcct5iDXtyw "Si l'utilisation du processeur sur votre serveur devient trop élevée, vous pouvez désactiver manuellement la collecte de données d'Agent Client Collector pour interrompre toutes les vérifications effectuées par l'agent, à l'exception des messages de maintien de connexion de l'agent.").  
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
{#checks-policies__ul_dfd_pwr_1pb}  
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
{#checks-policies__ul_r55_1mb_35b}

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

  {#checks-policies__ul_yzj_f2g_n4b}  
  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.

  {#checks-policies__ul_br4_4fg_n4b}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.
{#checks-policies__ul_ynm_ysy_4mb}

## Politiques {#checks-policies__section_ftj_c3b_rwb}

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](https://www.servicenow.com/docs/access?context=connection-alias&version=xanadu&pubname=xanadu-platform-security&ft:locale=en-US).  
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
{#checks-policies__ul_sc2_zds_j4b}

