Partager via

Résoudre les problèmes d’état d’agent gris dans System Center Operations Manager

  • Article

Cet article explique comment résoudre les problèmes liés à l’indisponibilité ou à la grisée d’un agent, d’un serveur d’administration ou d’une passerelle dans System Center Operations Manager (OpsMgr).

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

Un agent, un serveur d’administration ou une passerelle peut avoir l’un des états suivants, comme indiqué par la couleur du nom et de l’icône de l’agent dans le volet Surveillance .

État Apparence Description
Healthy Marque case activée verte L’agent ou le serveur d’administration s’exécute normalement.
Critique Marque case activée rouge Un problème se produit sur l’agent ou le serveur d’administration.
Inconnu Nom de l’agent gris, marque case activée grise L’observateur du service d’intégrité sur le serveur d’administration qui surveille le service d’intégrité sur l’ordinateur surveillé ne reçoit plus de pulsations de l’agent. L’observateur du service d’intégrité avait reçu des pulsations précédemment et l’état a été signalé comme sain. Cela signifie également que les serveurs d’administration ne reçoivent plus d’informations de l’agent.

Ce problème peut se produire si l’ordinateur qui exécute l’agent n’est pas en cours d’exécution ou s’il existe des problèmes de connectivité.
Inconnu Cercle vert, aucune marque case activée La status de l’élément découvert est inconnue. Aucun moniteur n’est disponible pour cet élément découvert spécifique.

Causes d’un état gris

Un agent, un serveur d’administration ou une passerelle peut devenir indisponible pour l’une des raisons suivantes :

  • Échec de pulsation
  • Configuration non valide
  • Échec des workflows système
  • Problèmes de performances de base de données ou d’entrepôt de données Operations Manager
  • Problèmes de performances du serveur d’administration ou du serveur de passerelle
  • Problèmes de réseau ou d’authentification
  • Le service d’intégrité n’est pas en cours d’exécution

Étendue du problème

Avant de commencer à résoudre le problème de l’agent grisé, vous devez d’abord comprendre la topologie Operations Manager, puis définir l’étendue du problème. Les questions suivantes peuvent vous aider à définir l’étendue du problème :

  • Combien d’agents sont affectés ?
  • Les agents rencontrent-ils le problème dans le même segment réseau ?
  • Les agents relèvent-ils du même serveur d’administration ?
  • À quelle fréquence les agents entrent et restent-ils dans un état gris ?
  • Comment pouvez-vous généralement récupérer après cette situation (par exemple, redémarrer le service d’intégrité de l’agent, effacer le cache, compter sur la récupération automatique) ?
  • Les alertes d’échec de pulsation sont-elles générées pour ces agents ?
  • Ce problème se produit-il à une heure spécifique de la journée ?
  • Ce problème persiste-t-il si vous basculez ces agents vers un autre serveur d’administration ou une autre passerelle ?
  • Quand ce problème a-t-il commencé ?
  • Des modifications ont-elles été apportées aux agents, aux serveurs d’administration, à la passerelle ou au groupe d’administration ?
  • Les agents affectés sont-ils des systèmes windows en cluster ?
  • Le dossier État du service d’intégrité est-il exclu de l’analyse antivirus ?

Stratégie de résolution des problèmes

Votre stratégie de résolution des problèmes sera dictée par le composant inactif, l’emplacement où ce composant se trouve dans la topologie et l’ampleur du problème. Tenez compte des conditions suivantes :

  • Si les agents qui relèvent d’un serveur d’administration ou d’une passerelle particulière ne sont pas disponibles, la résolution des problèmes doit commencer au niveau du serveur d’administration ou de la passerelle.
  • Si les passerelles qui signalent un serveur d’administration particulier ne sont pas disponibles, la résolution des problèmes doit commencer au niveau du serveur d’administration.
  • Pour les systèmes sans agent, pour les périphériques réseau et pour les serveurs Unix et Linux, la résolution des problèmes doit commencer au niveau de l’agent, du serveur d’administration ou de la passerelle qui surveille ces objets.
  • La résolution des problèmes commence généralement au niveau situé immédiatement au-dessus du composant indisponible.

Scénario 1

Seuls quelques agents sont affectés par le problème. Ces agents rapportent à différents serveurs d’administration. Les agents restent régulièrement indisponibles. Bien que vous puissiez effacer le cache de l’agent pour vous aider à résoudre le problème temporairement, le problème se répète après quelques jours.

Résolution pour le scénario 1

Pour résoudre le problème dans ce scénario, procédez comme suit :

  1. Appliquez le correctif logiciel approprié aux systèmes d’exploitation affectés.
  2. Excluez le cache de l’agent de l’analyse antivirus. Pour plus d’informations, consultez Recommandations pour les exclusions d’antivirus liées à Operations Manager.
  3. Arrêtez le service d’intégrité.
  4. Effacez le cache de l’agent.
  5. Démarrez le service d’intégrité.

Scénario 2

Seuls quelques agents sont affectés par le problème. Ces agents rapportent à différents serveurs d’administration. Les agents restent inactifs en permanence. Bien que vous puissiez effacer le cache de l’agent, cela ne résout pas le problème.

Résolution pour le scénario 2

Pour résoudre le problème dans ce scénario, procédez comme suit :

  1. Déterminez si le service d’intégrité est activé et s’exécute actuellement sur le serveur d’administration ou la passerelle. Si le service d’intégrité a cessé de répondre, générez un vidage ADPlus en mode de blocage du service pour vous aider à déterminer la cause du problème. Pour plus d’informations, consultez Comment utiliser ADPlus.vbs pour résoudre les problèmes de blocage et de plantage.

  2. Examinez le journal des événements Operations Manager sur l’agent pour rechercher l’un des événements suivants :

    ID d’événement : 1102
    Source de l’événement : HealthService
    Description de l’événement :
    La règle/moniteur « %4 » en cours d’exécution pour instance « %3 » avec l’ID : « %2 » ne peut pas être initialisée et ne sera pas chargée. Groupe d’administration « %1 »

    ID d’événement : 1103
    Source de l’événement : HealthService
    Description de l’événement :
    Résumé : %2 règles/moniteurs ont échoué et ont été déchargés, %3 d’entre eux ont atteint la limite d’échec qui empêche le rechargement automatique. Groupe d’administration « %1 ». Il s’agit d’un événement récapitulative uniquement. Consultez les autres événements avec des descriptions de règle(s)/moniteur(s) déchargé(s).

    ID d’événement : 1104
    Source de l’événement : HealthService
    Description de l’événement :
    Le profil RunAs dans le flux de travail « %4 », exécuté pour instance « %3 » avec id : « %2 » ne peut pas être résolu. Le flux de travail n’est pas chargé. Groupe d’administration « %1 »

    ID d’événement : 1105
    Source de l’événement : HealthService
    Description de l’événement :
    Incompatibilité de type pour le profil RunAs dans le flux de travail « %4 », en cours d’exécution pour instance « %3 » avec id : « %2 ». Le flux de travail n’est pas chargé. Groupe d’administration « %1 »

    ID d’événement : 1106
    Source de l’événement : HealthService
    Description de l’événement :
    Impossible d’accéder au profil RunAs en texte brut dans le flux de travail « %4 », en cours d’exécution pour instance « %3 » avec l’ID : « %2 ». Le flux de travail n’est pas chargé. Groupe d’administration « %1 »

    ID d’événement : 1107
    Source de l’événement : HealthService
    Description de l’événement :
    Compte pour le profil d’identification dans le flux de travail « %4 », en cours d’exécution pour instance « %3 » avec id : « %2 » n’est pas défini. Le flux de travail n’est pas chargé. Associez un compte au profil. Groupe d’administration « %1 »

    ID d’événement : 1108
    Source de l’événement : HealthService
    Description de l’événement :
    Un compte spécifié dans le profil d’identification « %7 » ne peut pas être résolu. Plus précisément, le compte est utilisé dans le remplacement de référence sécurisé « %6 ». %n%n Cette condition peut s’être produite, car le compte n’est pas configuré pour être distribué à cet ordinateur. Pour résoudre ce problème, vous devez ouvrir le profil d’identification spécifié ci-dessous, localiser l’entrée Compte comme spécifié par son SSID, puis choisir de distribuer le compte à cet ordinateur le cas échéant, ou modifier le paramètre dans le profil afin que l’objet cible n’utilise pas le compte spécifié. %n%nGroupe de gestion : %1 %nExécuter en tant que profil : %7 %nSecureReferenceOverride name : %6 %nSecureReferenceOverride ID : %4 %nNom de l’objet : %3 %nID de l’objet : %2 %nAccount SSID : %5

    ID d’événement : 4000
    Source de l’événement : HealthService
    Description de l’événement :
    Un hôte de surveillance ne répond pas ou s’est bloqué. Le code status de l’échec de l’hôte était %1.

    ID d’événement : 21016
    Source de l’événement : Connecteur OpsMgr
    Description de l’événement :
    OpsMgr n’a pas pu configurer un canal de communication sur %1 et il n’y a pas d’hôtes de basculement. La communication reprend lorsque %1 est disponible et que la communication à partir de cet ordinateur est autorisée.

    ID d’événement : 21006
    Source de l’événement : Connecteur OpsMgr
    Description de l’événement :
    Le connecteur OpsMgr n’a pas pu se connecter à %1 :%2. Le code d’erreur est %3(%4). Vérifiez qu’il existe une connectivité réseau, que le serveur est en cours d’exécution et qu’il a inscrit son port d’écoute, et qu’aucun pare-feu ne bloque le trafic vers la destination.

    ID d’événement : 20070
    Source de l’événement : Connecteur OpsMgr
    Description de l’événement :
    Le connecteur OpsMgr s’est connecté à %1, mais la connexion a été fermée immédiatement après l’authentification. La cause la plus probable de cette erreur est que l’agent n’est pas autorisé à communiquer avec le serveur ou que le serveur n’a pas reçu de configuration. Vérifiez la présence de 20 000 événements dans le journal des événements sur le serveur, indiquant que les agents qui ne sont pas approuvés tentent de se connecter.

    ID d’événement : 20051
    Source de l’événement : Connecteur OpsMgr
    Description de l’événement :
    Impossible de charger le certificat spécifié, car il n’est pas valide actuellement. Vérifiez que l’heure système est correcte et réexédiez le certificat si nécessaire%n Heure de début valide du certificat : %1%n Heure de fin valide du certificat : %2

    Source de l’événement : ESE
    Catégorie d’événement : Gestionnaire de transactions
    ID d’événement : 623
    Description : HealthService (<PID>) Le magasin de versions pour instance <instance>(« <name> ») a atteint sa taille maximale de <valeur> Mo. Il est probable qu’une transaction de longue durée empêche le nettoyage du magasin de versions et provoque son augmentation de la taille. Mises à jour seront rejetées jusqu’à ce que la transaction de longue durée ait été entièrement validée ou restaurée. Transaction de longue durée possible :
    SessionId : <valeur>
    Contexte de session : <valeur>
    ThreadId de contexte de session : <valeur>.
    Nettoyage : <valeur>

  3. Si vous localisez les événements spécifiques suivants, suivez ces instructions :

    • Événements 1102 et 1103 : ces événements indiquent que certains flux de travail n’ont pas pu être chargés. S’il s’agit des flux de travail système principaux, ces événements peuvent provoquer le problème. Dans ce cas, concentrez-vous sur la résolution de ces événements.

    • Événements 1104, 1105, 1106, 1107 et 1108 : ces événements peuvent entraîner la survenue des événements 1102 et 1103. En règle générale, cela se produit en raison de comptes d’identification mal configurés. Par exemple, les comptes d’identification sont configurés pour être utilisés avec la classe incorrecte ou ne sont pas configurés pour être distribués à l’agent.

    • Événement 4000 : cet événement indique que le processus Monitoringhost.exe s’est arrêté. Si ce problème est dû à une incompatibilité de DLL ou à des clés de Registre manquantes, vous pourrez peut-être le résoudre en réinstallant l’agent. Si le problème persiste, essayez de le résoudre à l’aide des méthodes suivantes :

    • ID d’événement 21006 : cet événement indique que des problèmes de communication existent entre l’agent et le serveur d’administration. Si l’agent utilise un certificat pour l’authentification mutuelle, vérifiez que le certificat n’a pas expiré et que l’agent utilise le certificat correct. Si Kerberos est utilisé, vérifiez que l’agent peut communiquer avec Active Directory. Si l’authentification fonctionne correctement, cela peut signifier que les paquets de l’agent n’atteignent pas le serveur d’administration ou la passerelle. Essayez d’établir un telnet vers le port 5723 de l’agent vers le serveur d’administration. En outre, exécutez une trace réseau simultanée entre l’agent et le serveur d’administration pendant que vous reproduisez les échecs de communication. Cela peut vous aider à déterminer si les paquets atteignent le serveur d’administration et si un appareil entre les deux composants tente d’optimiser le trafic ou supprime certains paquets. Pour plus d’informations, consultez Collecter des données à l’aide du Moniteur réseau.

    • ID d’événement 623 : cet événement se produit généralement dans un environnement Operations Manager volumineux dans lequel un serveur d’administration ou un ordinateur agent gère de nombreux flux de travail. Pour plus d’informations, consultez Un ou plusieurs serveurs d’administration et leurs appareils gérés sont grisés dans la console Operations Manager.

Scénario 3

Tous les agents qui relèvent d’un serveur d’administration ou d’une passerelle particulière ne sont pas disponibles.

Résolution pour le scénario 3

Pour résoudre le problème dans ce scénario, procédez comme suit :

  1. Essayez de déterminer le type de charges de travail que le serveur d’administration ou la passerelle surveille. Ces charges de travail peuvent inclure des appareils réseau, des agents multiplateformes, des transactions synthétiques, des agents Windows et des ordinateurs sans agent.

  2. Déterminez si le service d’intégrité s’exécute sur le serveur d’administration ou la passerelle.

  3. Déterminez si le serveur d’administration s’exécute en mode maintenance. Si nécessaire, supprimez le serveur du mode maintenance.

  4. Examinez le journal des événements Operations Manager sur l’agent pour rechercher l’un des événements répertoriés dans le scénario 2. S’il existe un ID d’événement 21006, suivez les mêmes instructions que celles mentionnées dans Résolution pour le scénario 2. En outre, dans ce cas, cet événement indique que le serveur d’administration ou la passerelle ne peut pas communiquer avec son serveur parent. Pour une passerelle, le serveur parent peut être n’importe quel serveur d’administration. (Reportez-vous à l’étape 3 de la résolution pour le scénario 2.)

  5. Examinez les événements suivants dans le journal des événements Operations Manager. Ces événements indiquent généralement que des problèmes de performances existent sur le serveur d’administration ou microsoft SQL Server qui héberge la OperationsManager base de données ou OperationsManagerDW :

    ID d’événement : 2115
    Source de l’événement : HealthService
    Description de l’événement :
    Une source de données de liaison dans le groupe d’administration %1 a publié des éléments dans le flux de travail, mais n’a pas reçu de réponse en %5 secondes. Cela indique un problème fonctionnel ou de performances avec le flux de travail.%n ID de workflow : %2%n Instance : %3%n Id d’instance : %4%n

    ID d’événement : 5300
    Source de l’événement : HealthService
    Description de l’événement :
    Le service de santé local n’est pas sain. Le flux de modification de l’état de l’entité est bloqué avec l’accusé de réception en attente. %n%n Groupe de gestion : %2 %nID du groupe de gestion : %1

    ID d’événement : 4506
    Source de l’événement : HealthService
    Description de l’événement : Operations Manager
    Les données ont été supprimées en raison d’un trop grand nombre de données en attente dans la règle « %2 » exécutée pour instance « %3 » avec id : « %4 » dans le groupe d’administration « %1 ».

    ID d’événement : 31551
    Source de l’événement : Modules du service d’intégrité
    Description de l’événement :
    Échec du stockage des données dans le Data Warehouse. L’opération fera l’objet d’une nouvelle tentative.%rException « %5 » : %6 %n%nUne ou plusieurs workflows ont été affectés par cela. %n%nNom du flux de travail : %2 %nNom de l’instance : %3 %nID d’instance : %4 %n Groupe de gestion : %1

    ID d’événement : 31552
    Source de l’événement : Modules du service d’intégrité
    Description de l’événement :
    Échec du stockage des données dans le Data Warehouse.%rException « %5 » : %6 %n%nUne ou plusieurs workflows ont été affectés par cela. %n%nNom du flux de travail : %2 %nNom de l’instance : %3 %nID d’instance : %4 %n Groupe de gestion : %1

    ID d’événement : 31553
    Source de l’événement : Modules du service d’intégrité
    Description de l’événement :
    Les données ont été écrites dans la zone de préproduction Data Warehouse, mais le traitement a échoué sur l’une des opérations suivantes.%rException '%5' : %6 %n%nUne ou plusieurs workflows ont été affectés par cela. %n%nNom du flux de travail : %2 %nNom de l’instance : %3 %nID d’instance : %4 %n Groupe de gestion : %1

    ID d’événement : 31557
    Source de l’événement : Modules du service d’intégrité
    Description de l’événement :
    Échec de l’obtention des informations d’état du processus de synchronisation à partir de Data Warehouse base de données. L’opération fera l’objet d’une nouvelle tentative.%rException « %5 » : %6 %n%nUne ou plusieurs workflows ont été affectés par cela. %n%nNom du flux de travail : %2 %nNom de l’instance : %3 %nID d’instance : %4 %n Groupe de gestion : %1

  6. L’ID d’événement 3155X peut également être journalisé en raison de configurations de compte d’identification incorrectes ou d’autorisations manquantes pour les comptes d’identification.

Remarque

Pour résoudre les problèmes de performances du serveur ou de la passerelle d’administration et SQL Server performances, consultez la section Résolution du scénario 4.

Scénarios 4

Tous les agents qui relèvent d’un serveur d’administration spécifique alternent par intermittence entre les états sains et gris. Ou, tous les agents de l’environnement alternent par intermittence entre les états sains et gris.

Résolution pour le scénario 4

Pour résoudre le problème, déterminez d’abord la cause du problème. Les causes courantes de l’indisponibilité temporaire du serveur sont les suivantes :

  • Le serveur parent des agents est temporairement hors connexion.
  • Les agents inondent le serveur d’administration de données opérationnelles, telles que des alertes, des états, des découvertes, etc. Cela peut entraîner une utilisation accrue des ressources système sur la base de données Operations Manager et sur les serveurs Operations Manager.
  • Les pannes réseau ont provoqué une défaillance temporaire de la communication entre le serveur parent et les agents.
  • Des modifications du pack d’administration (MP) se sont produites. Dans la console Operations Manager, ces modifications nécessitent une configuration Operations Manager et une redistribution mp aux agents. Si la modification affecte une base d’agent plus importante, cela peut entraîner une utilisation accrue des ressources système sur la base de données Operations Manager et les serveurs Operations Manager.

La clé de la résolution des problèmes dans ces scénarios consiste à comprendre la durée de l’indisponibilité du serveur et l’heure de la journée pendant laquelle elle s’est produite. Cela vous aidera à limiter rapidement l’étendue du problème.

Résolution des problèmes de performances du serveur d’administration et de la passerelle

Serveur d’administration

Lors d’un pic de mise à jour de configuration (provoqué par l’importation et la découverte mp), les goulots d’étranglement classiques sont, d’abord, le processeur et, deuxièmement, les E/S du disque d’installation d’Operations Manager. Le serveur d’administration est chargé de transférer les fichiers de configuration aux agents cibles.

Pour la collecte de données opérationnelles, les goulots d’étranglement sont généralement causés par le processeur. Les E/S disque peuvent également être à la capacité maximale, mais ce n’est pas aussi probable. Le serveur d’administration est chargé de décompresser et de déchiffrer les données opérationnelles entrantes et de les insérer dans la base de données opérationnelle. Il renvoie également des accusés de réception (ACL) aux agents ou aux passerelles après avoir reçu des données opérationnelles et utilise la file d’attente de disque pour stocker temporairement ces clés ACK sortantes.

Passerelle

La passerelle est à la fois liée au processeur et à l’E/S. Lorsque la passerelle relaie une grande quantité de données, les opérations d’uc et d’E/S peuvent présenter une utilisation élevée. La majeure partie de l’utilisation du processeur est due à la décompression, à la compression, au chiffrement et au déchiffrement des données entrantes, ainsi qu’au transfert de ces données. Toutes les données reçues par la passerelle et par les agents sont stockées dans une file d’attente persistante sur le disque, à lire et à transférer au serveur d’administration par le service d’intégrité de la passerelle. Cela peut entraîner une utilisation intensive du disque. Cette utilisation peut être importante lorsque la passerelle est temporairement hors connexion et doit ensuite gérer les données d’agent accumulées que les agents ont générées et ont essayé d’envoyer lorsque la passerelle était encore hors connexion.

Pour résoudre le problème dans cette situation, collectez les informations suivantes pour chaque serveur d’administration ou passerelle affecté :

  • Version, édition et numéro de build de Windows exacts

  • Nombre de processeurs

  • Quantité de RAM

  • Lecteur qui contient le dossier État du service d’intégrité

  • Indique si le logiciel antivirus est configuré pour exclure le magasin du service d’intégrité

    Remarque

    Pour plus d’informations, consultez Recommandations pour les exclusions d’antivirus liées à Operations Manager.

  • Niveau RAID (0, , 510+1 ou 1+0) pour le lecteur utilisé par l’état du service d’intégrité

  • Nombre de disques utilisés pour le RAID

  • Indique si le cache d’écriture avec batterie est activé sur le contrôleur de tableau

Résolution des problèmes de performances SQL Server

Base de données opérationnelle (OperationsManager)

Pour la OperationsManager base de données, le goulot d’étranglement le plus probable est la baie de disques. Si la baie de disques n’a pas la capacité maximale d’E/S, le goulot d’étranglement le plus probable suivant est le processeur. La base de données subira des ralentissements occasionnels et des tempêtes de données opérationnelles (incidence élevée d’événements, d’alertes et de données de performances ou de changements d’état qui persistent pendant une période relativement longue). Une rafale courte n’entraîne généralement pas de retard significatif pendant une période prolongée.

Lors de l’insertion de données opérationnelles, les disques de base de données sont principalement utilisés pour les écritures. L’utilisation du processeur est due à SQL Server attrition. Cela peut se produire lorsque vous avez des requêtes volumineuses et complexes, une insertion de données intensive et le nettoyage de tables volumineuses (qui, par défaut, se produit à minuit). En règle générale, le nettoyage d’événements même volumineux et de tables de données de performances ne consomme pas de ressources de processeur ou de disque excessives. Toutefois, le nettoyage des tables d’alerte et de changement d’état peut être gourmand en ressources processeur pour les tables volumineuses.

La base de données est également liée au processeur lorsqu’elle gère les rafales de redistribution de configuration, qui sont provoquées par des importations mp ou par une modification importante de l’espace instance. Dans ce cas, le service config interroge la base de données pour obtenir la nouvelle configuration de l’agent. Cela provoque généralement des pics de processeur sur la base de données avant que le service envoie les mises à jour de configuration aux agents.

Entrepôt de données (OperationsManagerDW)

Pour la OperationsManagerDW base de données, le goulot d’étranglement le plus probable est la baie de disques. Cela se produit généralement en raison d’insertions de données opérationnelles volumineuses. Dans ce cas, les disques sont principalement occupés à effectuer des écritures. En règle générale, les disques effectuent peu de lectures, sauf pour gérer manuellement les vues de création de rapports, car elles exécutent des requêtes sur l’entrepôt de données.

L’utilisation du processeur est due à SQL Server attrition. Des pics de processeur peuvent se produire lors d’une activité de partitionnement important (lorsque les tables deviennent volumineuses et sont ensuite partitionnée), de la génération de rapports complexes et de grandes quantités d’alertes dans la base de données, avec lesquelles l’entrepôt de données doit se synchroniser en permanence.

Résolution des problèmes généraux

Pour résoudre le problème dans cette situation, collectez les informations suivantes pour chaque serveur d’administration ou passerelle affecté :

  • Version, édition et numéro de build de Windows exacts

  • Nombre de processeurs

  • Quantité de RAM

  • Quantité de mémoire allouée à SQL Server

  • Indique si SQL Server est 32 bits et si AWE est activé

    Vous trouverez la plupart de ces informations dans SQL Server Management Studio ou dans SQL Server Entreprise Manager. Pour ce faire, ouvrez la fenêtre Propriétés du serveur, puis sélectionnez les onglets Général et Mémoire . L’onglet Général inclut la version SQL Server, la version De Windows, la plateforme, la quantité de RAM et le nombre de processeurs. L’onglet Mémoire inclut la mémoire allouée à SQL Server. Dans Microsoft SQL Server 2008, l’onglet Mémoire inclut également l’option AWE.

    Si le système d’exploitation est 32 bits et que la RAM est de 4 Go ou plus, case activée si les /pae commutateurs ou /3gb existent dans le Boot.ini. le fichier. Ces options peuvent être configurées de manière incorrecte si le serveur a été installé à l’origine avec 4 Go ou moins de RAM et si la RAM a été mise à niveau ultérieurement.

    Pour les serveurs 32 bits qui ont 4 Go de RAM, le /3gb commutateur dans Boot.ini augmente la quantité de mémoire que SQL Server pouvez traiter (de 2 Go à 3 Go). Pour les serveurs 32 bits qui ont plus de 4 Go de RAM, le /3gb commutateur dans Boot.ini peut en fait limiter la quantité de mémoire que SQL Server pouvez traiter. Pour ces systèmes, ajoutez le /pae commutateur à Boot.ini, puis activez AWE dans SQL Server.

    Sur un système multiprocesseur, case activée le paramètre Max Degree of Parallelism (MAXDOP). Dans SQL Server 2008, cette option se trouve sous l’onglet Avancé de la boîte de dialogue Propriétés du serveur.

    La valeur par défaut est 0, ce qui signifie que tous les processeurs disponibles seront utilisés. Un paramètre de 0 est correct pour les serveurs qui ont huit processeurs ou moins. Pour les serveurs qui ont plus de huit processeurs, le temps nécessaire SQL Server pour coordonner l’utilisation de tous les processeurs peut être contre-productif. Par conséquent, pour les serveurs qui ont plus de huit processeurs, vous devez généralement définir le degré maximal de parallélisme sur la valeur 8. Pour ce faire, exécutez la commande suivante dans l’Analyseur de requêtes SQL :

    sp_configure 'show advanced options', 1
GO
RECONFIGURE WITH OVERRIDE
GO
sp_configure 'max degree of parallelism', 8
GO
RECONFIGURE WITH OVERRIDE
GO

  • Lettres de lecteur qui contiennent des fichiers d’entrepôt de données, de base de données Operations Manager et tempdb

  • Indique si le logiciel antivirus est configuré pour exclure les données SQL et les fichiers journaux (l’analyse des fichiers de base de données SQL Server avec un logiciel antivirus peut dégrader les performances.)

  • Quantité d’espace libre sur les lecteurs qui contiennent l’entrepôt de données, la base de données Operations Manager et les fichiers Tempdb

  • Type de stockage (SAN ou local)

  • Niveau RAID (0, 1, 5, 0+1 ou 1+0) pour les lecteurs utilisés par SQL Server

  • Si le stockage SAN est utilisé : nombre de broches sur chaque lun utilisé par SQL Server

  • Si le pack d’administration Exchange 2007 converti est utilisé ou a déjà été utilisé : nombre de lignes dans la table dans la LocalizedText base de données Operations Manager et dans la EventPublisher table dans la base de données de l’entrepôt de données

    Pour déterminer les quantités de lignes, exécutez les commandes suivantes :

    USE OperationsManager SELECT COUNT(*) FROM LocalizedText
USE OperationsManagerDW SELECT COUNT(*) FROM EventPublisher

Compteurs pour identifier la pression de la mémoire

Nom du compteur de performances Description
MSSQL$<instance> : Gestionnaire de mémoires tampons : espérance de vie des pages Durée de conservation des pages dans le pool de mémoires tampons. Si cette valeur est inférieure à 300 secondes, cela peut indiquer que le serveur peut utiliser plus de mémoire. Elle peut également résulter de la fragmentation de l’index.
MSSQL$<instance> : Gestionnaire de mémoires tampons : écritures différées/s L’enregistreur différé libère de l’espace dans la mémoire tampon en déplaçant les pages sur le disque. En règle générale, la valeur ne doit pas dépasser systématiquement 20 écritures par seconde. Dans l’idéal, il serait proche de zéro.
Mémoire : Mooctets disponibles Les valeurs inférieures à 100 Mo peuvent indiquer une sollicitation de la mémoire. La sollicitation de la mémoire est clairement présente lorsque cette quantité est inférieure à 10 Mo.
Processus : Octets privés : _Total Il s’agit de la quantité de mémoire (physique et page) utilisée par tous les processus combinés.
Processus : Ensemble de travail : _Total Il s’agit de la quantité de mémoire physique utilisée par tous les processus combinés. Si la valeur de ce compteur est nettement inférieure à la valeur de Process: Private Bytes: _Total, cela indique que les processus paginent trop fortement. Une différence de plus de 10 % est probablement significative.

Compteurs pour identifier la pression du disque

Capturez ces compteurs de disque physique pour tous les lecteurs qui contiennent des données SQL ou des fichiers journaux :

  • % de temps d’inactivité : durée d’inactivité du disque signalée. Tout élément inférieur à 50 % peut indiquer un goulot d’étranglement du disque.

  • Longueur moyenne de la file d’attente du disque : cette valeur ne doit pas dépasser le double du nombre de broches sur un numéro d’unité logique. Par exemple, si un numéro d’unité logique a 25 broches, la valeur 50 est acceptable. Toutefois, si un numéro d’unité logique a 10 broches, la valeur 25 est trop élevée. Vous pouvez utiliser les formules suivantes en fonction du niveau RAID et du nombre de disques dans la configuration RAID :

    • RAID 0 : tous les disques fonctionnent dans un jeu RAID 0

    • Longueur <moyenne de la file d’attente de disque= # (Disques dans le tableau) *2

    • RAID 1 : la moitié des disques font du travail ; par conséquent, seule la moitié d’entre eux peuvent être comptés dans la file d’attente de disque

    • Longueur <moyenne de la file d’attente de disque= # (Disques dans le tableau/2) *2

    • RAID 10 : la moitié des disques « font du travail » ; par conséquent, seule la moitié d’entre eux peuvent être comptés dans la file d’attente de disque

    • Longueur <moyenne de la file d’attente de disque= # (Disques dans le tableau/2) *2

    • RAID 5 : tous les disques fonctionnent dans un jeu RAID 5

    • Longueur <moyenne de la file d’attente de disque= nombre de disques dans le tableau *2

    • Moy. Disk sec/Transfer : nombre de secondes nécessaires pour effectuer une E/S disque

    • Moyenne s disque/lecture : temps moyen, en secondes, pour lire les données à partir du disque

    • Moy. Disque s/écriture : temps moyen, en secondes, pour écrire des données sur le disque

      Les trois derniers compteurs de cette liste doivent avoir systématiquement des valeurs d’environ 0,020 (20 ms) ou inférieures et ne doivent jamais dépasser 0,050 (50 ms). Voici les seuils documentés dans le guide de résolution des problèmes de performances SQL Server :

      • Moins de 10 ms : très bon
      • Entre 10 et 20 ms : ok
      • Entre 20 et 50 ms : lent, a besoin d’attention
      • Supérieur à 50 ms : goulot d’étranglement grave d’E/S

    • Octets de disque/s : nombre d’octets transférés vers ou depuis le disque par seconde

    • Transferts de disque/s : nombre d’opérations d’entrée et de sortie par seconde (IOPS)

    Lorsque % de temps d’inactivité est faible (10 % ou moins), cela signifie que le disque est entièrement utilisé. Dans ce cas, les deux derniers compteurs de cette liste (Octets disque/s et Transferts de disque/s) fournissent une bonne indication du débit maximal du lecteur, respectivement en octets et en IOPS. Le débit d’un lecteur SAN est très variable, en fonction du nombre de broches, de la vitesse des lecteurs et de la vitesse du canal. Le meilleur choix consiste à case activée avec le fournisseur SAN pour déterminer le nombre d’octets et d’IOPS que le lecteur doit prendre en charge. Si % de temps d’inactivité est faible et que les valeurs de ces deux compteurs ne répondent pas au débit attendu du lecteur, demandez au fournisseur SAN de résoudre les problèmes.

SQL Server guide de résolution des problèmes de performances fournit des informations plus détaillées sur la résolution des problèmes SQL Server performances.

Compteurs de performances Operations Manager

Les sections suivantes décrivent les compteurs de performances que vous pouvez utiliser pour surveiller et résoudre les problèmes de performances d’Operations Manager.

Rôle serveur de passerelle

Compteurs de performances globaux

Ces compteurs indiquent les performances globales de la passerelle :

Nom du compteur de performances
Processor(_Total)\% Processor Time
Mémoire\% octets validés en cours d’utilisation
Interface réseau(*)\Nombre total d’octets/s
LogicalDisk(*)\% temps d’inactivité
LogicalDisk(*)\Avg. Disk Queue Length
Compteurs de performances génériques de processus Operations Manager

Ces compteurs indiquent les performances globales des processus Operations Manager sur la passerelle :

Nom du compteur de performances Description
Process(HealthService)\% Temps processeur
Process(HealthService)\Private Bytes Selon le nombre d’agents gérés par cette passerelle, ce nombre peut varier et peut être de plusieurs centaines de mégaoctets.
Process(HealthService)\Thread Count
Process(HealthService)\Virtual Bytes
Process(HealthService)\Working Set
Process(MonitoringHost*)\% Temps processeur
Process(MonitoringHost*)\Private Bytes
Process(MonitoringHost*)\Thread Count
Process(MonitoringHost*)\Virtual Bytes
Process(MonitoringHost*)\Working Set
Compteurs de performances spécifiques à Operations Manager

Ces compteurs sont des compteurs spécifiques à Operations Manager qui indiquent les performances d’aspects spécifiques d’Operations Manager sur la passerelle :

Nom du compteur de performances Description
Service d’intégrité\Nombre de flux de travail
Groupes d’administration du service d’intégrité(*)\Chargements de fichiers actifs Nombre de transferts de fichiers gérés par cette passerelle. Cela représente le nombre de fichiers de pack d’administration qui sont chargés sur les agents. Si cette valeur reste à un niveau élevé pendant une longue période et qu’il n’y a pas beaucoup de pack d’administration importé à un moment donné, ces conditions peuvent générer un problème qui affecte le transfert de fichiers.
Groupes d’administration du service d’intégrité(*)\% de file d’attente d’envoi utilisé Taille de la file d’attente persistante. Si cette valeur reste supérieure à 10 pendant une longue période et qu’elle ne diminue pas, cela indique que la file d’attente est sauvegardée. Cette condition est due à un système Operations Manager surchargé, car le serveur d’administration ou la base de données est trop occupé ou hors connexion.
Connecteur OpsMgr\Octets reçus Nombre d’octets réseau reçus par la passerelle, c’est-à-dire le nombre d’octets entrants avant la décompression.
Connecteur OpsMgr\Octets transmis Nombre d’octets réseau envoyés par la passerelle, c’est-à-dire le nombre d’octets sortants après la compression.
Connecteur OpsMgr\Octets de données reçus Nombre d’octets de données reçus par la passerelle, c’est-à-dire la quantité de données entrantes après décompression.
Connecteur OpsMgr\Octets de données transmis Nombre d’octets de données envoyés par la passerelle, c’est-à-dire la quantité de données sortantes avant la compression.
Connecteur OpsMgr\Ouvrir Connections Nombre de connexions ouvertes sur la passerelle. Ce nombre doit être identique au nombre d’agents ou de serveurs d’administration qui sont directement connectés à la passerelle.

Rôle serveur d’administration

Compteurs de performances globaux

Ces compteurs indiquent les performances globales du serveur d’administration :

Nom du compteur de performances
Processor(_Total)\% Processor Time
Mémoire\% octets validés en cours d’utilisation
Interface réseau(*)\Nombre total d’octets/s
LogicalDisk(*)\% temps d’inactivité
LogicalDisk(*)\Avg. Disk Queue Length
Compteurs de performances génériques de processus Operations Manager

Ces compteurs indiquent les performances globales des processus Operations Manager sur le serveur d’administration :

Nom du compteur de performances Description
Process(HealthService)\% Temps processeur
Process(HealthService)\Private Bytes Selon le nombre d’agents gérés par ce serveur d’administration, ce nombre peut varier et il peut s’agir de plusieurs centaines de mégaoctets.
Process(HealthService)\Thread Count
Process(HealthService)\Virtual Bytes
Process(HealthService)\Working Set
Process(MonitoringHost*)\% Temps processeur
Process(MonitoringHost*)\Private Bytes
Process(MonitoringHost*)\Thread Count
Process(MonitoringHost*)\Virtual Bytes
Process(MonitoringHost*)\Working Set
Compteurs de performances spécifiques à Operations Manager

Ces compteurs sont des compteurs spécifiques à Operations Manager qui indiquent les performances d’aspects spécifiques d’Operations Manager sur le serveur d’administration :

Nom du compteur de performances Description
Service d’intégrité\Nombre de flux de travail Nombre de workflows en cours d’exécution sur ce serveur d’administration.
Groupes d’administration du service d’intégrité(*)\Chargements de fichiers actifs Nombre de transferts de fichiers gérés par ce serveur d’administration. Cela représente le nombre de fichiers de pack d’administration qui sont chargés sur les agents. Si cette valeur reste à un niveau élevé pendant une longue période et qu’il n’y a pas beaucoup de pack d’administration importé à un moment donné, ces conditions peuvent générer un problème qui affecte le transfert de fichiers.
Groupes d’administration du service d’intégrité(*)\% de file d’attente d’envoi utilisé Taille de la file d’attente persistante. Si cette valeur reste supérieure à 10 pendant une longue période et qu’elle ne diminue pas, cela indique que la file d’attente est sauvegardée. Cette condition est due à un système Operations Manager surchargé, car le système Operations Manager (par exemple, le serveur d’administration racine) est trop occupé ou est hors connexion.
Groupes d’administration du service d’intégrité(*)\Taux de suppression des éléments de source de données de liaison Nombre d’éléments de données supprimés par le serveur d’administration pour les actions d’écriture de collecte de données de base de données ou d’entrepôt de données. Lorsque cette valeur de compteur n’est pas 0, le serveur d’administration ou la base de données est surchargé, car il ne peut pas gérer l’élément de données entrant assez rapidement ou parce qu’un burst d’élément de données se produit. Les éléments de données supprimés seront renvoyés par les agents. Une fois la surcharge ou la situation de rafale terminée, ces éléments de données sont insérés dans la base de données ou dans l’entrepôt de données.
Groupes d’administration du service d’intégrité(*)\Taux d’entrée entrant de l’élément source de données de liaison Nombre d’éléments de données reçus par le serveur d’administration pour les actions d’écriture de collecte de données de base de données ou d’entrepôt de données.
Groupes d’administration du service d’intégrité(*)\Taux de publication des éléments de source de données de liaison Nombre d’éléments de données que le serveur d’administration a écrits dans la base de données ou l’entrepôt de données pour les actions d’écriture de collecte de données.
Connecteur OpsMgr\Octets reçus Nombre d’octets réseau reçus par le serveur d’administration, c’est-à-dire la taille des octets entrants avant la décompression.
Connecteur OpsMgr\Octets transmis Nombre d’octets réseau envoyés par le serveur d’administration, c’est-à-dire la taille des octets sortants après la compression.
Connecteur OpsMgr\Octets de données reçus Nombre d’octets de données reçus par le serveur d’administration, c’est-à-dire la taille des données entrantes après décompression.
Connecteur OpsMgr\Octets de données transmis Nombre d’octets de données envoyés par le serveur d’administration, c’est-à-dire la taille des données sortantes avant compression.
Connecteur OpsMgr\Ouvrir Connections Nombre de connexions ouvertes sur le serveur d’administration. Il doit être identique au nombre d’agents ou de serveurs d’administration racine qui y sont directement connectés.
Modules d’action d’écriture de base de données OpsMgr(*)\Taille moyenne du lot Nombre d’éléments de données ou de lots reçus par les modules d’action d’écriture de base de données. Si ce nombre est de 5 000, un burst d’élément de données se produit.
Modules d’action d’écriture de base de données OpsMgr(*)\Temps de traitement moyen Nombre de secondes pendant lesquelles un module d’action d’écriture de base de données prend pour insérer un lot dans la base de données. Si ce nombre est souvent supérieur à 60, un problème de performances d’insertion de base de données se produit.
Module d’enregistreur DW OpsMgr(*)\Durée moyenne de traitement par lots, ms Nombre de millisecondes pour l’action d’écriture de l’entrepôt de données pour insérer un lot d’éléments de données dans un entrepôt de données.
OpsMgr DW Writer Module(*)\Avg. Batch Size Nombre moyen d’éléments de données ou de lots reçus par les modules d’action d’écriture de l’entrepôt de données.
Module d’enregistreur DW OpsMgr(*)\Batches/s Nombre de lots reçus par les modules d’action d’écriture de l’entrepôt de données par seconde.
Module d’enregistreur DW OpsMgr(*)\Éléments de données/s Nombre d’éléments de données reçus par les modules d’action d’écriture de l’entrepôt de données par seconde.
OpsMgr DW Writer Module(*)\Nombre d’éléments de données supprimés Nombre d’éléments de données supprimés par les modules d’action d’écriture de l’entrepôt de données.
Module d’enregistreur DW OpsMgr(*)\Nombre total d’erreurs Nombre d’erreurs qui se sont produites dans un module d’action d’écriture de l’entrepôt de données.