Détecter et résoudre les problèmes liés aux modifications de configuration fréquentes dans Operations Manager

Article
04/15/2024

Cet article explique comment détecter et résoudre les problèmes liés aux modifications de configuration fréquentes dans System Center Operations Manager.

Version d’origine du produit : Microsoft System Center 2012 Operations Manager
Numéro de la base de connaissances d’origine : 2603913

Vue d’ensemble de la configuration

Le service Configuration de la gestion de System Center est chargé de calculer la configuration de chaque service d’intégrité dans le groupe d’administration Operations Manager. La configuration d’un service d’intégrité se compose des règles, des analyses, des découvertes et des tâches pour le service d’intégrité et pour toutes les instances que le service d’intégrité surveille.

Pour calculer toutes les configurations requises pour chaque service d’intégrité, le service configuration de gestion doit avoir une liste des éléments suivants :

Toutes les instances de toutes les classes supervisées
Les relations d’hébergement entre les instances
Les règles, les analyses, les découvertes et les autres flux de travail affectés aux classes supervisées
Les services d’intégrité chargés de la surveillance des instances

En outre, le service configuration de gestion doit être en mesure de lire l’appartenance de tous les groupes instance dans le groupe d’administration. Le service de configuration de gestion doit également appliquer des remplacements pour les règles et les moniteurs ciblant ces groupes, classes ou instances individuelles.

Les objets d’un groupe d’administration sont définis en tant qu’instances de classes supervisées en fonction des données de découverte soumises par les workflows de découverte. Si une propriété clé d’un objet change, cet objet peut être ajouté en tant que nouveau instance d’une classe surveillée. Sinon, cet objet n’est plus considéré comme un instance de cette classe.

À mesure que la liste change pour les classes dont l’objet est membre, la configuration change également pour le service d’intégrité qui surveille cet objet. Ces modifications se produisent à mesure que des règles, des analyses, des découvertes, des tâches et des remplacements sont ajoutés ou supprimés de la configuration précédente.

Évolution de la configuration

Les agents peuvent ne pas pouvoir recevoir une configuration stable dans les scénarios suivants :

Une grande quantité de données de découverte est envoyée au service de configuration de gestion.
Les données de découverte sont envoyées trop rapidement pour que le service de configuration de gestion les traite avant l’envoi d’autres données de découverte. Ce scénario se produit parce que les données seront toujours en cours de calcul.

La soumission fréquente de données de découverte, également appelée évolution de la configuration, peut entraîner l’exécution de certains services d’intégrité sous d’anciennes configurations ou la configuration des serveurs d’administration. Ce comportement fait apparaître certains services d’intégrité grisés (non disponibles) dans la console Opérateur.

Les données de découverte sont envoyées par un service d’intégrité lorsqu’un workflow de découverte s’exécute. L’introduction d’un nouveau pack d’administration à un groupe d’administration peut entraîner l’exécution de plusieurs workflows de découverte sur chaque agent. Et, à mesure que de nouvelles instances sont découvertes, des découvertes supplémentaires peuvent être exécutées sur certains agents. Les modifications apportées aux groupes, aux remplacements et à d’autres flux de travail peuvent entraîner l’exécution de workflows de découverte sur les agents. De plus, l’introduction de nouveaux agents peut également entraîner la mise à jour de l’espace instance par le service configuration de gestion à l’aide de la configuration du nouvel agent.

Le service Gestion de la configuration est forcé de recalculer fréquemment la configuration du service d’intégrité dans les scénarios suivants :

Un workflow de découverte est configuré pour s’exécuter trop fréquemment.
Les propriétés découvertes par le flux de travail changent chaque fois que le workflow de découverte est exécuté.

Si ces scénarios se produisent pour de nombreux agents, ou si les serveurs d’administration sont déjà soumis à une charge de travail importante, le service Gestion de la configuration peut ne pas être en mesure de suivre le rythme des modifications et l’évolution de la configuration peut se produire.

Identifier l’évolution de la configuration à l’aide du journal des événements du serveur d’administration

Un événement qui ressemble à ce qui suit dans le journal des événements Operations Manager sur le serveur d’administration indique que la configuration du groupe d’administration a changé en raison de nouvelles données de découverte :

Nom du journal : Operations Manager
Source : Connecteur OpsMgr
ID d’événement : 21024
Niveau : Informations
Ordinateur : <Nom>
Description :
La configuration d’OpsMgr peut être obsolète pour le groupe <d’administration ManagementGroupName> et a demandé une configuration mise à jour auprès du service de configuration. Le cookie d’état actuel (obsolète) est « 3A B0 1E 5C 81 F3 12 F5 56 B7 8A EF F8 01 BA 09 86 55 06 48 »

Un événement semblable à ce qui suit indique que le service configuration de gestion a terminé le traitement des nouvelles données de découverte et a calculé les modifications nécessaires à la configuration du groupe d’administration, en fonction des nouvelles données :

Nom du journal : Operations Manager
Source : Connecteur OpsMgr
ID d’événement : 21025
Niveau : Informations
Ordinateur : <Nom>
Description :
OpsMgr a reçu une nouvelle configuration du groupe <d’administration ManagementGroupName> du service de configuration. Le nouveau cookie d’état est « 34 FA 11 61 4D B8 03 59 3D 1D 66 B7 83 F3 C0 AA 7A 6F 1A 3B »

Dans un environnement classique, chaque événement 21024 doit être suivi de l’événement 21025. Si les données de découverte n’ont pas modifié les données de configuration, l’ID d’événement est 21026 à la place. Dans un grand groupe d’administration, les paires d’événements 21024 et 21025 ou 21026 doivent se produire plusieurs fois par heure. Les chaînes longues de 21024 événements sans événement 21025 ou 21026 correspondant sont un signe d’évolution de la configuration. En outre, le journal des événements peut afficher l’événement suivant qui indique que l’activité a été détectée :

Nom du journal : Operations Manager
Source : Service de configuration OpsMgr
ID d’événement : 29202
Niveau : Avertissement
Ordinateur : <Nom>
Description :
Le service de configuration OpsMgr n’a pas pu récupérer un état cohérent de la base de données OpsMgr en raison de modifications trop fréquentes de la base de données.
Cela peut être dû à une augmentation normale et temporaire des données de découverte ; toutefois, case activée les modifications les plus récentes pour déterminer si cette augmentation est inattendue.
Modification de l’objet de surveillance la plus récente :
Instance = %1
Classe = %2
Heure de modification = %3
Modification de la relation de surveillance la plus récente :
Relation instance = %4
Source instance = %5
Instance cible = %6
RelationshipClass = %7
Heure de modification = %8

La couche d’accès aux données doit lire plusieurs tables lorsque la couche d’accès aux données demande des modifications. Si l’une des tables est modifiée après sa lecture, mais avant la lecture de toutes les tables, la couche d’accès aux données enregistre l’ID d’événement précédent 29202 et réessaye. Si une entité ou une relation instance a été lue pendant cette période, des informations sur ces instances sont incluses dans les champs d’événement. Sinon, ces champs sont laissés vides.

Identifier les causes potentielles de l’évolution de la configuration à l’aide d’Operations Manager Data Warehouse

Dans les groupes d’administration dans lesquels le composant De rapports Operations Manager a été installé, plusieurs requêtes SQL peuvent être utilisées pour identifier les workflows qui envoient des modifications fréquentes. Ces requêtes doivent être exécutées dans SQL Server Management Studio sur le Data Warehouse instance.

Nombre total de modifications soumises par les workflows de découverte au cours des dernières 24 heures :

select
   ManagedEntityTypeSystemName,
   DiscoverySystemName,
   count(*) As 'Changes'
from
   (
      select distinct
         MP.ManagementPackSystemName,
         MET.ManagedEntityTypeSystemName,
         PropertySystemName,
         D.DiscoverySystemName,
         D.DiscoveryDefaultName,
         MET1.ManagedEntityTypeSystemName As 'TargetTypeSystemName',
         MET1.ManagedEntityTypeDefaultName As 'TargetTypeDefaultName',
         ME.Path,
         ME.Name,
         C.OldValue,
         C.NewValue,
         C.ChangeDateTime
      from
         dbo.vManagedEntityPropertyChange C
         inner join
            dbo.vManagedEntity ME
            on ME.ManagedEntityRowId = C.ManagedEntityRowId
         inner join
            dbo.vManagedEntityTypeProperty METP
            on METP.PropertyGuid = C.PropertyGuid
         inner join
            dbo.vManagedEntityType MET
            on MET.ManagedEntityTypeRowId = ME.ManagedEntityTypeRowId
         inner join
            dbo.vManagementPack MP
            on MP.ManagementPackRowId = MET.ManagementPackRowId
         inner join
            dbo.vManagementPackVersion MPV
            on MPV.ManagementPackRowId = MP.ManagementPackRowId
         left join
            dbo.vDiscoveryManagementPackVersion DMP
            on DMP.ManagementPackVersionRowId = MPV.ManagementPackVersionRowId
            AND CAST(DefinitionXml.query('data(/Discovery/DiscoveryTypes/DiscoveryClass/@TypeID)') AS nvarchar(max)) like '%' + MET.ManagedEntityTypeSystemName + '%'
         left join
            dbo.vManagedEntityType MET1
            on MET1.ManagedEntityTypeRowId = DMP.TargetManagedEntityTypeRowId
         left join
            dbo.vDiscovery D
            on D.DiscoveryRowId = DMP.DiscoveryRowId
      where
         ChangeDateTime > dateadd(hh, - 24, getutcdate())
   )
   As # T
group by
   ManagedEntityTypeSystemName,
   DiscoverySystemName
order by
   count(*) DESC

Cette requête crée trois colonnes. La première colonne est la classe d’objet à laquelle le flux de travail est ciblé. La deuxième colonne indique le nom interne du workflow de découverte. La troisième colonne indique le nombre total de modifications de propriété pour toutes les instances de cette classe qui ont été soumises par le flux de travail au cours des dernières 24 heures. Le nombre total de modifications, pour toutes les classes, représente le nombre de fois où le service Gestion de la configuration doit recalculer la configuration d’un service d’intégrité de l’agent.

Le nombre de modifications pour certaines classes d’objets, même dans un environnement stable, peut ne pas jamais atteindre zéro. Toute modification, telle que l’ajout ou la suppression d’une propriété, les agents ajoutés ou désactivés, les rôles serveur ajoutés ou modifiés, etc., est reflétée dans les nombres retournés. Dans les environnements dans lesquels l’évolution de la configuration est rencontrée, un ou plusieurs flux de travail afficheront probablement une valeur plus importante que les autres flux de travail.

Propriétés modifiées au cours des dernières 24 heures :

select distinct
   MP.ManagementPackSystemName,
   MET.ManagedEntityTypeSystemName,
   PropertySystemName,
   D.DiscoverySystemName,
   D.DiscoveryDefaultName,
   MET1.ManagedEntityTypeSystemName As 'TargetTypeSystemName',
   MET1.ManagedEntityTypeDefaultName As 'TargetTypeDefaultName',
   ME.Path,
   ME.Name,
   C.OldValue,
   C.NewValue,
   C.ChangeDateTime
from
   dbo.vManagedEntityPropertyChange C
   inner join
      dbo.vManagedEntity ME
      on ME.ManagedEntityRowId = C.ManagedEntityRowId
   inner join
      dbo.vManagedEntityTypeProperty METP
      on METP.PropertyGuid = C.PropertyGuid
   inner join
      dbo.vManagedEntityType MET
      on MET.ManagedEntityTypeRowId = ME.ManagedEntityTypeRowId
   inner join
      dbo.vManagementPack MP
      on MP.ManagementPackRowId = MET.ManagementPackRowId
   inner join
      dbo.vManagementPackVersion MPV
      on MPV.ManagementPackRowId = MP.ManagementPackRowId
   left join
      dbo.vDiscoveryManagementPackVersion DMP
      on DMP.ManagementPackVersionRowId = MPV.ManagementPackVersionRowId
      AND CAST(DefinitionXml.query('data(/Discovery/DiscoveryTypes/DiscoveryClass/@TypeID)') AS nvarchar(max)) like '%' + MET.ManagedEntityTypeSystemName + '%'
   left join
      dbo.vManagedEntityType MET1
      on MET1.ManagedEntityTypeRowId = DMP.TargetManagedEntityTypeRowId
   left join
      dbo.vDiscovery D
      on D.DiscoveryRowId = DMP.DiscoveryRowId
where
   ChangeDateTime > dateadd(hh, - 24, getutcdate())
ORDER BY
   MP.ManagementPackSystemName,
   MET.ManagedEntityTypeSystemName

Cette requête peut identifier les propriétés qui ont changé au cours des dernières 24 heures. Combinée à la requête précédente, cette requête peut indiquer les anciennes et nouvelles valeurs de la propriété, les agents qui ont soumis la modification, le flux de travail qui a effectué la découverte et le pack d’administration dans lequel elle était contenue.

Réduire l’attrition de configuration

Les anciens packs d’administration introduisent des flux de travail de découverte qui soumettent trop fréquemment des modifications de propriété. Les versions actuelles de la plupart des packs d’administration ont modifié ces workflows de découverte pour envoyer des données moins fréquemment, ou les packs d’administration n’interrogent pas les propriétés volatiles qui changent fréquemment. Nous vous recommandons de mettre à niveau les packs d’administration qui contiennent des flux de travail qui se produisent fréquemment dans la requête précédente.

Si une nouvelle version du pack d’administration n’est pas disponible ou si la nouvelle version ne peut pas être déployée maintenant, l’intervalle de découverte peut être ajusté à l’aide du remplacement pour s’exécuter moins fréquemment. Parfois, la découverte responsable de l’évolution de la configuration peut être désactivée par substitution. Si la découverte est désactivée pendant plusieurs semaines, les objets découverts par le workflow peuvent être nettoyés hors de la base de données. Toutefois, la désactivation de la découverte peut fournir une solution de contournement à court terme pour éliminer l’évolution de la configuration, à condition qu’une solution permanente puisse être implémentée avant que les objets soient nettoyés à partir de la base de données. Le flux de travail peut également être activé pendant de courts intervalles pour redécouvrir les objets avant qu’ils ne soient nettoyés.

Certains flux de travail de ces anciens packs d’administration sont abordés dans Qu’est-ce que l’attrition de la configuration ?

Si le flux de travail provient d’une découverte personnalisée qui cible une propriété volatile, telle que l’espace disque libre, la découverte doit être réécrite afin qu’elle ne cible pas une propriété qui change fréquemment. Les workflows de découverte ne doivent pas cibler les instances qui ont une durée de vie courte (plusieurs semaines ou moins). Les workflows de découverte ne doivent pas collecter les propriétés de ces instances qui changent fréquemment (une ou plusieurs fois par mois). Les données volatiles ne sont pas prises en compte dans le calcul d’une configuration. Par conséquent, les données volatiles doivent être collectées par des règles de performances et non par des workflows de découverte.

Réglage supplémentaire des performances

Dans les grands groupes d’administration (plus de 1 000 agents), le serveur d’administration racine (RMS) peut être occupé par des opérations qui ne provoquent généralement pas de problème dans les groupes d’administration plus petits. Dans ce cas, même un faible taux de modifications de propriété peut entraîner une évolution fréquente en raison de la durée nécessaire au traitement des modifications. Plusieurs modifications de configuration peuvent être utilisées pour réduire la surcharge opérationnelle du RMS et lui permettre de traiter un taux classique de modifications de propriété assez rapidement pour éviter l’évolution de la configuration. Ces modifications de configuration sont décrites dans Optimisations des performances pour Operations Manager 2007 R2 et 2012.

Forcer la modification de la configuration pour le groupe d’administration

Si l’évolution de la configuration du groupe d’administration se produit constamment, les modifications visant à réduire la fréquence des flux de travail problématiques ou à désactiver les flux de travail problématiques ne seront jamais propagées aux agents. Dans ce cas, le flux des données de découverte entrantes doit être bloqué pour permettre au service System Center Configuration Management de calculer une configuration actuelle dans laquelle le flux de travail qui produit ces données est désactivé ou s’exécute moins fréquemment.

Les données de découverte sont envoyées à la OperationsManager base de données par le biais du service DAS (System Center Data Access Service). Les données sont d’abord envoyées au DAS par le service de gestion De System Center sur le RMS. RmS obtient ces données auprès d’agents ou d’autres serveurs d’administration. Vous pouvez utiliser le pare-feu Windows ou d’autres moyens de mise en réseau pour bloquer les connexions entrantes au RMS sur le port 5723. Cette procédure de blocage empêche l’envoi de données de découverte à la OperationsManager base de données suffisamment longtemps pour que le service Gestion de la configuration calcule la configuration actuelle pour les agents qui envoient les données.

Le service De gestion de System Center et le service d’accès aux données System Center sur rms ne doivent pas être arrêtés ou désactivés pendant que le service Gestion de la configuration calcule la configuration actuelle. Le service System Center Configuration Management nécessite les éléments suivants pour effectuer le calcul de la configuration du groupe d’administration :

Le service de gestion De System Center sur rms doit être en cours d’exécution et sain.
Le service d’accès aux données System Center doit être en mesure de communiquer avec la base de données.

En outre, certaines données peuvent être mises en backlog sur les agents et sur d’autres serveurs d’administration pendant que le service Gestion de la configuration calcule la configuration actuelle. Par conséquent, l’exclusion de pare-feu ou de port doit être levée dès que vous voyez l’ID d’événement 21025 dans le journal des événements Operations Manager sur rms. Cet événement indique que le service Gestion de la configuration a calculé la nouvelle configuration pour le groupe d’administration où le flux de travail est maintenant désactivé ou modifié

Identifier les causes potentielles de l’attrition de la configuration à l’aide de la création de rapports Operations Manager

De nouveaux rapports ont été introduits. Ces rapports fournissent des informations sur le volume global de données que le groupe d’administration traite. Ces rapports peuvent être utilisés pour établir une base de référence standard et identifier les opportunités de réglage des workflows de découverte d’objets. Dès que l’attrition de configuration est identifiée et traitée, ces rapports peuvent être utilisés pour la planification à long terme afin d’éviter les récurrences d’attrition.

Rapport Volume de données par pack d’administration

Le rapport Volume de données par pack d’administration compile des informations sur le volume de données généré par les packs d’administration. Le rapport répertorie le nombre d’occurrences par pack d’administration pour les types de données suivants :
- Découvertes
- Alertes
- Performances (nombre d’instances envoyées pour les compteurs de performances et collectées par le pack d’administration)
- Événements
- Changements d’état
Rapport Volume de données par workflow et instance

Le rapport Volume de données par workflow et instance compile des informations sur le volume de données généré, organisé par flux de travail (découvertes, règles, analyses, etc.) et par instances.

Il existe deux façons d’accéder à ce rapport :
- Dans le rapport Volume de données par pack d’administration , sélectionnez l’une des cellules de comptage dans le tableau en haut du rapport pour ouvrir le rapport Volume de données par workflow et instance pour les packs d’administration.
- Exécutez le rapport directement à partir de la section Rapports dans la console Opérateur. Si vous exécutez directement le rapport Volume de données par workflow et instance , vous devez définir les paramètres du rapport pour personnaliser les résultats. Ce rapport fournit des informations détaillées dans le rapport Volume de données par pack d’administration . Par conséquent, les paramètres par défaut peuvent ne pas fournir les informations que vous recherchez.