Utilisez le portail d’erreurs connues et la communauté pour vous aider à trouver des problèmes d’information.

Préférences générales

Santé personnelle

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 Gestion des événements fonctionnalités.

Remarque :

Les CI utilisés dans le service d’auto-santé 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 utilisée pour l’injection d’événement. Les règles métier écrites pour les tables d’alerte [em_alert] doivent être très efficaces, sinon elles risquent d’entraîner une dégradation des performances. Au lieu d’écrire une règle métier, demandez-vous s’il est plus approprié 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].
Mise à l’échelle	Vérifiez le temps moyen de traitement des événements avant d’augmenter le débit d’événements au démarrage initial avec Gestion des événements. Effectuez cette vérification après un premier flux d’événements et toutes les règles sont en place. Si le temps de traitement prend plus de quelques millisecondes par événement, déterminez la cause du ralentissement du traitement avant de poursuivre la mise à l’échelle. La durée de performance peut être vérifiée dans le tableau Statistiques de performances [sa_performance_statistics].
Configurer 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 multinœud dans les environnements de production et définissez les valeurs en fonction de la taille du déploiement et du taux d’événements attendu. Définissez la propriété Nombre de travaux planifiés 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 des données de clé ou de source,denœud, de type et de ressource de message.
Problèmes de latence pour la réception des événements	Vérifiez les paramètres suivants : Vérifiez que le champ Catégorie de 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 - process events* tâches existent en fonction de la configuration de la propriété Nombre de travaux planifiés 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.
Archiver les événements	Évitez de modifier la durée de conservation par défaut des événements. Pour consigner les événements pendant une période plus longue, créez une table d’archivage et une tâche qui y copie les nouveaux événements. Pour ce faire, 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énement

Interruptions SNMP

• Utilisez un outil de surveillance pour envoyer des interruptions SNMP, plutôt que de les envoyer directement à partir des 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.

Web service API

• 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 à transformer 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 spécifiques à chaque source d’événement.

CloudWatch

Utilisez des informations d’identification dédiées pour intégrer CloudWatch à ServiceNow.

E-mail

Utilisez l’e-mail uniquement si la source dispose d’un faible volume 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 :

• Rédigez des règles d’événements à appliquer au plus grand nombre d’événements possible. Des règles plus spécifiques peuvent ensuite être créées si nécessaire et doivent utiliser une valeur d’ordre inférieur.
• Si une règle plus générale peut obtenir le même résultat, évitez d’écrire des règles d’événements qui ne s’appliquent qu’à un certain sous-ensemble d’événements.
• Lorsque des règles d’événements sont appliquées à des événements, aucun changement n’est apporté à l’événement d’origine. Tout le traitement se produit en mémoire, utilisez donc le champ Notes de traitement et/ou le lien d’action d’interface utilisateur Vérifier le processus de l’événement pour résoudre le problème.
• Si vous modifiez une règle/une transformation qui a des règles de mappage existantes, vous devez l’examiner et la tester à nouveau avec des é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 additional_info champ 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 de l’interruption SNMP affiche varbinds (liaison de variables) avec des noms pointés, au lieu du nom traduit dans la MIB. La règle de mappage de champs d’événements n’est alors pas appliquée.
• Établissez une convention de dénomination cohérente. Une convention commune est : <customer acronym>.<Event Source>.<Description>. Par exemple, ACME.OEM.Normalize
• Si deux règles d’événement ont des conditions similaires définies, utilisez le champ Ordre pour contrôler quelle règle d’événement s’exécute.
• Utilisez des règles d’événements pour associer une alerte à un CI.

Paramètres supplémentaires pour la construction de règles d’événements :

Résultat souhaité	Activité requise
Déduplication efficace et mise en œuvre 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 remplissant le champ Nœud et éventuellement les identificateursCI. Liaison à l’application et/ou à l’appareil – en remplissant le champ CI Identifiers (Identificateurs de CI ) et le champ Additional information (Informations supplémentaires ).
Corrélation d’alertes, à l’aide de l’agrégation d’alertes	Renseignez les champs Resource (Ressource) et Metric Name (Nom de la mesure). Remarque : Si le CI est également lié, la corrélation des alertes est améliorée.

Champs d’événements personnalisés

Inclure les 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 plus d’informations sur l’inclusion de champs supplémentaires dans des événements, reportez-vous à la section Champs d’alerte personnalisés.

Déduplication

Paramètres de configuration pour la déduplication.

• Le champ message_key est utilisé pour la déduplication. Si des valeurs de clé de message fiables ne sont pas fournies avec l’événement source, il est important d’avoir un plan bien défini pour la construction de 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> .
• La directive consiste à demander à la source de l’événement de renseigner les champs prêts à l’emploi <Source + Node + Type + Resource + Metric Name> et de renseigner la clé de message. Cette action permet une meilleure répartition du traitement des événements entre les travailleurs et les nœuds de l’instance.
• Si l’événement source n’a pas de valeurs pour ces champs, assurez-vous de les renseigner à l’aide des règles de transformation. Cette action n’affecte pas le traitement des événements, mais est utilisée pour la déduplication. Renseignez autant de ces champs que possible avant qu’ils ne soient envoyés à l’instance. Cette action fournit une meilleure distribution des événements sur les travailleurs du processeur et, par conséquent, un débit et une échelle améliorés.

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 et ne sont pas liés à l’événement.
• Pour lier un hôte, une machine ou tout appareil avec une adresse IP, renseignez le champ Nœud de l’événement avec un nom d’hôte, un FQDN, une adresse IP ou 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 correspondance.
  Remarque :

  Le champ Nœud d’événement doit être renseigné à partir d’une règle d’événement ou renseigné avec un nom d’hôte unique 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 peut être renseigné à l’aide des règles d’événement .

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 n’est pas ignoré ou que son seuil est dépassé par une règle d’événement, 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 l’alerte est fermée manuellement.
• Une alerte est rouverte si une alerte d’ouverture ayant la même clé de message est envoyée dans le délai défini dans les propriétés (une heure par défaut).
• Si une alerte est ouverte et fermée à un rythme élevé, tel que défini dans les propriétés, il se transforme en oscillation. Lorsque ce taux d’ouverture et de fermeture s’arrête, l’alerte sort de l’état de battement.
• Si un incident est ouvert à partir d’une alerte, cette alerte reste ouverte tant que l’incident reste ouvert. Par défaut, lorsque l’incident ou l’alerte est fermé, l’autre l’est également. Ce comportement peut être configuré à l’aide de propriétés.
• Ne fermez pas une alerte lors de la création d’un incident correspondant.
• Ne pas supprimer une alerte ouverte. Fermez d’abord une alerte, puis supprimez-la.
• Utilisez Confirmer pour indiquer que l’alerte est connue et qu’elle peut être temporairement ignorée.
• N’utilisez pas l’option Confirmer pour marquer une alerte comme nécessitant une attention particulière.
• Ne créez pas d’alertes dans l’un de ces états :
  • 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 pas créer d’alertes dans l’état OK . Dans certains systèmes de surveillance, OK indique qu’un problème a été résolu, tandis que dans d’autres systèmes de surveillance, OK est utilisé pour désigner des événements qui ne sont pas importants sur le plan opérationnel. Dans le premier cas, utilisez Effacer au lieu de OK à l’aide d’une règle de mappage. Dans ce dernier cas, utilisez 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 le dépannage.
• Utilisez le champ Ordre pour contrôler la règle d’alerte qui s’exécute si deux règles d’alerte ont des conditions similaires définies.
• Utilisez des règles d’action d’alerte avec des modèles de tâches pour renseigner les valeurs statiques d’un incident. Utilisez le script populator pour affecter des valeurs dynamiques à l’incident. Le script de remplisseur peut renvoyer la valeur faux pour annuler la création d’incidents.
• Créez un utilisateur appelé Gestion des événements (ou un nom similaire). Ensuite, le champ Créé par dans un modèle de tâche (par exemple, Incident) peut être défini pour indiquer que l’utilisateur était la source de la tâche.
• Pour procéder à une affectation de valeur dynamique ou pour remplacer l’affectation de valeur dynamique OOB, utilisez l’include de script EvtMgmtCustomIncidentPopulator .

Correction

• Définissez toujours les propriétés du workflow Orchestration sur la table Tâche de rattrapage [em_remediation_task].
• Utiliser ECC Queue et Workflow > Workflow opérationnel > Tous les contextes pour obtenir des renseignements plus détaillés sur les activités de rattrapage.

Règles métier

• Les règles métier créées sur des tables d’alertes ne doivent pas prendre plus de quelques millisecondes. Au lieu d’utiliser une règle métier, demandez-vous si la même fonctionnalité peut être obtenue à 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, des modules, etc., en plusieurs efforts parallèles, plutôt qu’en série.
• Validez les formats des événements traités pour vous assurer que les données analysées sont alignées sur les résultats souhaités.
• Testez les événements de production dans un environnement de non-production. Intégrez avec des gestionnaires d’éléments et ServiceNow des instances de non-production. 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.

Analyse des mesures Journaux et fichiers du collecteur

Analyse des mesures Les journaux et les fichiers du collecteur se trouvent sous le chemin $(MID_SERVER_DIR)/agent. Utilisez ces journaux et fichiers à des fins de dépannage et de surveillance.

Analyse des mesures Les performances peuvent être vérifiées dans le Serveur MID fichier journal lorsque le mid.log.level Serveur MID paramètre est en mode de débogage.

Analyse des mesures Les numéros de performance sont disponibles dans le tableau Performance Statistics (Statistiques de performance) [sa_performance_statistics]. Pour afficher les chiffres de performance, filtrez la liste des statistiques de performances pour le collecteur de mesures.