Préférences de configuration de Gestion des événements

  • Rversion finale: Zurich
  • Mis à jour 31 juil. 2025
  • 11 minutes de lecture

    • Paramètres recommandés des propriétés et configuration générale.

    Utilisez le Portail d'erreurs connues et la Communauté pour vous aider à rechercher des problèmes d'informations.

    Préférences générales

    Intégrité autonome
    Par défaut, la fonctionnalité de surveillance de l'intégrité autonome n'est pas activée. Pour l’activer, accédez à Gestion des événements > Paramètres > Propriétés et sélectionnez Oui pour la Enable Event Management self-health monitoring propriété (evt_mgmt.self_health_active). Utilisez cette fonctionnalité pour surveiller et suivre de nombreuses fonctionnalités de Gestion des événements.
    Remarque :
    les CI utilisés dans le service d'intégrité autonome sont créés dans la CMDB.
    Utilisez les paramètres suivants pour éviter la dégradation des performances.
    Sujet Détails
    Règles métier
    • Évitez d'écrire des règles métier pour les tables d'événements [em_event], car elles ne s'exécutent pas dans l'URL REST par défaut actuellement utilisée pour l'injection d'événements.
    • Les règles métier écrites pour les tables d'alertes [em_alert] doivent être hautement efficaces ; dans le cas contraire, elles risquent d'entraîner une dégradation des performances. Au lieu d'écrire une règle métier, envisagez d'écrire une tâche. Une règle métier inefficace peut entraîner l'échec de la création d'un incident pour une alerte et l'échec du calcul de l'impact de l'alerte.
    • N'écrivez pas de règles métier asynchrones pour les tables d'alertes.
    • Les règles métier ne doivent pas modifier le champ Catégorie sur les tables d'événements [em_event].
    Augmentation Vérifiez le délai de traitement moyen des événements avant d'augmenter le débit d'événements lorsque vous commencez à utiliser Gestion des événements. Effectuez cette vérification après avoir lancé un flux d'événements initial et une fois toutes les règles en place. Si le délai de traitement est supérieur à quelques millisecondes par événement, déterminez la cause du ralentissement du traitement avant de continuer à augmenter le débit. Vous pouvez vérifier la durée de performance dans la table Statistiques des performances [sa_performance_statistics].
    Configuration pour les environnements à grande échelle
    • Définissez la propriété Activer le traitement des événements multinœuds (evt_mgmt.event_processor_enable_multi_node) sur Oui.

      Activez le traitement des événements multinœuds dans les environnements de production, et définissez des valeurs en fonction de la taille du déploiement et du taux d'événements attendu.

    • Définissez la propriété Nombre de tâches planifiées traitant des événements (evt_mgmt.event_processor_job_count) sur 4.
    • Si vous envoyez des événements à partir d'une source personnalisée, vérifiez que les événements ont une clé de message ou possèdent des données sur la source, le nœud, le type et les ressources.
    Problèmes de latence pour la réception d'événements Vérifiez les paramètres suivants :
    • Vérifiez que le champ Catégorie dans la table d'événements [em_event] est défini sur une valeur supérieure à zéro (0).
    • Accédez à la Planificateur système > Travaux planifiés et recherchez - process events*.

      Vérifiez que toutes les tâches - process events* existent en fonction de la configuration de la propriété Nombre de tâches planifiées traitant des événements (event_processor_job_count). Vérifiez que l'état est Running ou Ready. Si l'état est Queued ou Error, définissez l'état de la tâche sur Ready.
    Événements d'archivage
    • Évitez de modifier le délai de conservation par défaut des événements.
    • Pour consigner les événements plus longtemps, créez une table d'archivage et une tâche permettant de copier les nouveaux événements dans cette table. Pour cela, planifiez une tâche pour sauvegarder régulièrement les événements [em_event] dans une table personnalisée.
    • N'étendez pas la rotation de table en ajoutant plus de jours.

    Intégration d'événements

    Interruptions SNMP
    • Utilisez un outil de surveillance pour envoyer des interruptions SNMP, plutôt que de les envoyer directement à partir d'appareils.
    • Pour éviter d'avoir à réécrire les règles d'événements, chargez les MIB avant de définir les règles d'événements.
    API de service Web
    • L'utilisation d'une API de service Web pour l'intégration peut réduire le nombre de règles d'événements nécessaires. Cette action évite d'avoir à convertir les événements (les données préparées sont envoyées dans un événement à l'instance).
    • Utilisez des informations d'identification dédiées pour l'intégration. Vous pouvez également désigner des informations d'identification propres à chaque source d'événement.
    CloudWatch
    Utilisez des informations d'identification dédiées pour intégrer CloudWatch à ServiceNow.
    E-mail
    Utilisez la messagerie électronique uniquement si la source a un volume faible et que d'autres options ne sont pas disponibles, telles que l'exécution d'un script ou le transfert d'une interruption SNMP.
    Règles d'événements
    Paramètres de configuration lors de la création de règles d'événements :
    • Écrivez des règles d'événements en vue de les appliquer au plus grand nombre d'événements possible. Vous pourrez ensuite créer des règles plus spécifiques si vous le souhaitez, avec une valeur d'ordre inférieur.
    • Si une règle plus générale peut produire le même résultat, évitez d'écrire des règles d'événements qui s'appliquent uniquement à un sous-ensemble d'événements spécifique.
    • Lorsque les règles d'événements sont appliquées aux événements, aucune modification n'est apportée à l'événement d'origine. Étant donné que le traitement a lieu dans la mémoire, utilisez le champ Notes de traitement et/ou le lien d'action d'interface utilisateur Vérifier le traitement de l'événement pour résoudre les problèmes.
    • Si vous modifiez une règle/une conversion qui possède des règles de mappage, vous devez examiner et tester à nouveau les événements réels ou simulés.
    • Assurez-vous que la valeur du champ De correspond exactement à une chaîne dans le JSON dans le champ additional_info d'un événement. Cette correspondance se produit lorsqu'une règle a été configurée en fonction des informations contenues dans un fichier MIB. Si le fichier MIB n'est pas chargé, le JSON pour l'interruption SNMP affiche varbinds (liaisons de variables) avec des noms en pointillés, au lieu du nom traduit dans le fichier MIB. La règle de mappage de champs d'événements n'est pas appliquée.
    • Établissez une convention d'affectation de noms cohérente. Une convention commune est <customer acronym>.<Event Source>.<Description>. Par exemple : ACME.OEM.Normalize
    • Si des conditions similaires ont été définies pour les deux règles d'événements, utilisez le champ Ordre pour contrôler quelle règle d'événement s'exécute.
    • Utilisez les règles d'événements pour associer une alerte à un CI.
    Paramètres supplémentaires pour la création de règles d'événements :
    Résultat souhaité Activité requise
    Déduplication effective et activation d'un traitement efficace des événements parallèles Renseignez les champs Source, Nœud, Type, Ressource, Nom de la mesure.
    Liaison de CI
    • Lier à l'hôte : en renseignant le champ Nœud et éventuellement le champ Identificateurs CI.
    • Liaison à l'application et/ou à l'appareil : en renseignant le champ Identificateurs CI et le champ Informations supplémentaires.
    Corrélation d'alertes, à l'aide de l'agrégation d'alertes Renseignez les champs Ressource et Nom de la mesure.
    Remarque :
    Si le CI est également lié, la corrélation d'alertes est améliorée.
    Champs d'événements personnalisés
    Inclure des champs supplémentaires dans le champ Informations supplémentaires de l'événement uniquement.
    N'ajoutez pas de champs supplémentaires à un événement en ajoutant un champ personnalisé à la table d'événements [em_event].
    N'ajoutez pas de colonnes à la table d'événements [em_event].

    Pour en savoir plus sur la façon d'inclure des champs supplémentaires dans les événements, consultez la rubrique Personnaliser les champs d'alertes.

    Déduplication
    Paramètres de configuration de la déduplication.
    • Le champ message_key est utilisé pour la déduplication. Si des valeurs de clés de message fiables ne sont pas fournies avec l'événement source, il est important de disposer d'un plan clairement défini pour créer ces identificateurs.
    • Si la clé de message n'est pas définie, la clé de message par défaut est <Source + Node + Type + Resource + Metric Name> .
    • Il est donc recommandé de configurer la source de l'événement de façon à ce qu'elle renseigne les champs <Source + Node + Type + Resource + Metric Name> prêts à l'emploi ainsi que la clé de message. Cette action permet une meilleure distribution du traitement des événements entre les agents et les nœuds d'instance.
    • Si l'événement source n'a pas de valeurs pour ces champs, assurez-vous de les renseigner à l'aide de règles de conversion. Cette action n'a pas d'incidence sur le traitement des événements, mais est utilisée pour la déduplication. Renseignez autant de champs que possible avant qu'ils ne soient envoyés à l'instance. Cette action assure une meilleure distribution des événements sur les agents de processeur, et donc un meilleur débit et une meilleure mise à l'échelle.
    Liaison de CI
    • Dans la mesure du possible, essayez toujours de lier une alerte à un CI.
      Remarque :
      bien que les règles d'événements soient définies sur les événements, les CI sont liés aux alertes qui résultent de ces événements, mais ne sont pas liés à l'événement proprement dit.
    • Pour lier un hôte, un ordinateur ou n'importe quel appareil avec une adresse IP, renseignez le champ Nœud de l'événement avec un nom d'hôte, un nom d'hôte complet, une adresse IP ou une adresse MAC unique. Si d'autres identificateurs sont nécessaires pour identifier un hôte, renseignez le champ ci_identifiers au format JSON. Le format JSON doit contenir le nom et la valeur du champ CMDB pour effectuer la mise en correspondance.
      Remarque :
      vous devez renseigner le champ Nœud de l'événement à partir d'une règle d'événement ou avec un nom d'hôte unique provenant de la source avant l'insertion de l'événement.
    • La stratégie de liaison primaire consiste à utiliser le champ Nœud. Si le champ Nœud n'est pas prérempli dans l'événement, il est possible de le renseigner à l'aide de règles d'événements.

    Paramètres d'alerte

    Cycle de vie de l'alerte
    Fonctionnalité d'alerte générale :
    • Une alerte est ouverte chaque fois qu'un événement est pris en compte ou qu'une règle d'événement dépasse son seuil, et la déduplication n'identifie pas l'événement comme appartenant à une alerte existante.
    • Une alerte est fermée lorsqu'un événement de fermeture est envoyé sur la même clé de message ou que l'alerte est fermée manuellement.
    • Une alerte est rouverte si une alerte d'ouverture possédant la même clé de message est envoyée dans le délai défini dans les propriétés (la valeur par défaut est d'une heure).
    • Si une alerte est ouverte et fermée à un taux élevé (selon les valeurs définies dans les propriétés), elle passe à l'état d'oscillation. Lorsque ce taux d'ouverture et de fermeture s'arrête, l'alerte quitte l'état d'oscillation.
    • Si un incident est ouvert à partir d'une alerte, cette alerte reste ouverte tant que l'incident reste ouvert. Par défaut, à la fermeture de l'incident ou de l'alerte, l'un ou l'autre est également fermé. Il est possible de configurer ce comportement à l'aide des propriétés.
    • Ne fermez pas une alerte lors de la création d'un incident correspondant.
    • Ne supprimez pas une alerte ouverte. Fermez l'alerte, puis supprimez-la.
    • Utilisez l'option Confirmer pour indiquer que l'alerte est connue et peut temporairement être ignorée.
    • N'utilisez pas l'option Confirmer pour marquer une alerte comme étant à surveiller.
    • Ne créez pas d'alertes dans l'un des états suivants :
      • Fermé
      • OK
      • Ouvert
    • La propriété evt_mgmt.alert_auto_close_interval ferme automatiquement les alertes après la période spécifiée. Ne spécifiez pas 0, car cette valeur désactive la fonctionnalité et peut entraîner une dégradation des performances.
    • Ne créez pas d'alertes à l'état OK. Dans certains systèmes de surveillance, l'état OK indique qu'un problème a été résolu ; dans d'autres, l'état OK désigne les événements non importants d'un point de vue opérationnel. Dans le premier cas, utilisez l'option Effacer plutôt que l'option OK à l'aide d'une règle de mappage. Dans le dernier cas, vous devez disposer d'une règle Ignorer, sauf si les événements ont une valeur spécifique.
    Règles d'action d'alerte
    • Une tâche planifiée applique des règles d'action d'alerte aux nouvelles alertes toutes les 11 secondes. Si une règle d'alerte ne démarre pas immédiatement, attendez 10 à 15 secondes avant de commencer la résolution des problèmes.
    • Utilisez le champ Ordre pour contrôler quelle règle d'alerte s'exécute si des conditions similaires ont été définies sur deux règles d'alerte.
    • Utilisez les règles d'action d'alerte avec les modèles de tâches pour renseigner les valeurs statiques dans un incident. Utilisez le script de remplissage pour affecter des valeurs dynamiques dans l'incident. Le script de remplissage peut renvoyer une valeur faux pour annuler la création d'un incident.
    • Créez un utilisateur appelé Gestion des événements (ou utilisez un nom similaire). Vous pouvez ensuite définir le champ Créé par dans un modèle de tâche (par exemple, Incident) pour indiquer que l'utilisateur était la source de la tâche.
    • Pour affecter des valeurs de façon dynamique ou remplacer l'affectation de valeurs dynamique OOB, utilisez le script Include EvtMgmtCustomIncidentPopulator.
    Correction
    • Définissez toujours les propriétés du workflow Orchestration sur la table Tâche de correction [em_remediation_task].
    • Utiliser la file d’attente ECC et Workflow > Workflow opérationnel > Tous les contextes pour trouver des informations plus détaillées sur les activités de rattrapage.

    Règles métier

    • Les règles métier créées sur les tables d'alertes ne doivent pas prendre plus de quelques millisecondes. Au lieu d'utiliser une règle métier, déterminez si vous pouvez obtenir le même résultat à l'aide d'une tâche.
    • N'utilisez pas de règles métier pour associer une alerte à un CI. Utilisez des règles d'événements pour effectuer la liaison au lieu d'utiliser des règles métier.

    Planification

    • Organisez la configuration de la source d'événement des filtres, modules, etc., en plusieurs tâches, plutôt qu'en série.
    • Validez les formats d'événements traités pour vous assurer que les données analysées correspondent aux résultats souhaités.
    • Testez les événements de production dans un environnement de non-production. Procédez à l'intégration avec des gestionnaires d'éléments de non-production et des instances ServiceNow. Si les gestionnaires d'éléments de non-production ne sont pas disponibles, envoyez les événements des gestionnaires d'éléments aux environnements de production et de non-production.

    Services et tableau de bord

    • Utilisez des groupes de services pour regrouper les services en groupes logiques afin de réduire le nombre de services affichés sur le tableau de bord Intégrité du service.
    • Importez des cartes de services créées manuellement.

    Journaux et fichiers du collecteur Analyse des mesures

    Les journaux et les fichiers du collecteur Analyse des mesures se trouvent à l'emplacement $(MID_SERVER_DIR)/agent. Utilisez ces journaux et fichiers à des fins de résolution de problèmes et de surveillance.

    Tableau 1. Emplacement des journaux et des fichiers du Analyse des mesures collecteur
    Journal ou fichier Chemin d'accès
    Fichier journal du collecteur de mesures PowerShell Logs/retrieve_metrics{connector instance ID}.log
    Fichier de sortie PowerShell work/metrics/metrics_output_{connector instance ID}.txt  
    Fichier d'entrée PowerShell work/metrics/parameters_{connector instance ID}.txt

    Vous pouvez vérifier les performances de Analyse des mesures dans le fichier journal du Serveur MID lorsque le paramètre mid.log.level Serveur MID est en mode de débogage.

    Les valeurs de performances de Analyse des mesures sont disponibles dans la table Statistiques des performances [sa_performance_statistics]. Pour afficher les valeurs de performances, filtrez la liste Statistiques des performances pour Collecteur de mesures.