Partager via

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

  • Article

Cet article explique comment résoudre les problèmes dans lesquels un agent, un serveur d’administration ou une passerelle n’est pas disponible ou grisé dans System Center Operations Manager (OpsMgr).

Version du produit d’origine : Microsoft System Center 2012 Operations Manager
Numéro de 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 Coche verte L’agent ou le serveur d’administration s’exécute normalement.
Critique Coche rouge Il existe un problème sur l’agent ou le serveur d’administration.
Inconnu Nom de l’agent gris, coche grise L’observateur des services d’intégrité sur le serveur d’administration qui observe le service d’intégrité sur l’ordinateur analysé ne reçoit plus de pulsations de la part de l’agent. L'observateur des services d'intégrité a reçu des pulsations précédemment et l'état a été signalé comme étant intègre. Cela signifie également que les serveurs d'administration ne reçoivent plus d'informations de la part de l'agent.

Ce problème peut se produire si l’ordinateur exécutant l’agent n’est pas en cours d’exécution ou s’il existe des problèmes de connectivité.
Inconnu Cercle vert, aucune coche L’état de l’élément découvert est inconnu. 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 lié aux pulsations
  • Configuration non valide
  • Échec des flux de travail du système
  • Problèmes de performances de base de données Operations Manager ou d’entrepôt de données
  • 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é est inactif

Étendue du problème

Avant de commencer à résoudre le problème grisé par l’agent, 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 signalent-ils au même serveur d’administration ?
  • À quelle fréquence les agents entrent-ils et restent-ils dans un état gris ?
  • Comment récupérez-vous généralement cette situation (par exemple, redémarrez le service d’intégrité de l’agent, effacez le cache, reposez-vous 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 pendant 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 ou à la passerelle ou au groupe d’administration ?
  • Les agents affectés sont-ils des systèmes en cluster Windows ?
  • Le dossier État du service d’intégrité est-il exclu de l’analyse antivirus ?

Stratégie de dépannage

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

  • Si les agents qui signalent à un serveur d’administration ou à une passerelle particulier 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 appareils réseau et pour les serveurs Unix et Linux, la résolution des problèmes doit démarrer 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 immédiatement au-dessus du composant indisponible.

Scénario 1

Seuls quelques agents sont affectés par le problème. Ces agents signalent à différents serveurs d’administration. Les agents restent indisponibles régulièrement. 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 du 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 concernés.
  2. Excluez le cache de l’agent de l’analyse antivirus. Pour plus d’informations, consultez Recommandations pour les exclusions 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 signalent à 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 du 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 blocage de service pour vous aider à déterminer la cause du problème. Pour plus d’informations, consultez Comment utiliser ADPlus.vbs pour résoudre les « blocages » et « plantages »

  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 l’instance « %3 » avec 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ègle(s)/moniteur(s) a échoué et a été déchargé, %3 d’entre eux a atteint la limite d’échec qui empêche le rechargement automatique. Groupe d’administration « %1 ». Il s’agit d’un événement de synthèse uniquement, reportez-vous aux autres événements avec des descriptions de règles ou de moniteurs 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 », qui s’exécute par exemple « %3 » avec id :« %2 » ne peut pas être résolu. Le workflow ne sera 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 l’instance « %3 » avec id :« %2 ». Le workflow ne sera 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 exécutant l’instance « %3 » avec id :« %2 ». Le workflow ne sera pas chargé. Groupe d’administration « %1 »

    ID d’événement : 1107
    Source de l’événement : HealthService
    Description de l’événement :
    Le profil d’identification du flux de travail « %4 », en cours d’exécution pour l’instance « %3 » avec id : « %2 » n’est pas défini. Le workflow ne sera pas chargé. Veuillez associer 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 Ce problème peut être dû au fait que le compte n’est pas configuré pour être distribué sur cet ordinateur. Pour résoudre ce problème, vous devez ouvrir le profil d'identification indiqué ci-dessous, rechercher l'entrée de compte selon son SSID, puis choisir une des options suivantes : distribuer le compte sur cet ordinateur ou modifier le paramétrage du profil, afin que l'objet cible ne fasse pas appel au compte spécifié. %n%nGroupe de gestion : %1 %nProfil d’identification : %7 %nSecureReferenceOverride Nom : %6 %nSecureReferenceOverride ID: %4 %n Nom de l’objet : %3 %n ID de l’objet : %2 %nSSID du compte : %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 d’état de l’échec de l’hôte était %1.

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

    ID d’événement : 21006
    Source d’é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 a inscrit son port d’écoute et qu’il n’existe aucun pare-feu bloquant le trafic vers la destination.

    ID d’événement : 20070
    Source d’événement : Connecteur OpsMgr
    Description de l’événement :
    Le connecteur OpsMgr 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. Consultez le journal des événements sur le serveur pour la présence de 20 000 événements, qui indique que les agents non approuvés tentent de se connecter.

    ID d’événement : 20051
    Source d’événement : Connecteur OpsMgr
    Description de l’événement :
    Le certificat spécifié n’a pas pu être chargé, car le certificat n’est pas valide actuellement. Vérifiez que l’heure système est correcte et réécrit le certificat si nécessaire%n Heure de début valide du certificat : %1%n Heure de fin valide du certificat : %2

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

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

    • Événements 1102 et 1103 : ces événements indiquent que certains workflows n’ont pas pu être chargés. S’il s’agit des workflows système de base, ces événements peuvent être à l’origine du 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 les é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 mauvaise classe 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 bloqué. Si ce problème est dû à une incompatibilité dll ou à des clés de Registre manquantes, vous pouvez peut-être résoudre le problème 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 les 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 approprié. 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 signalent à un serveur d’administration ou une passerelle particulier ne sont pas disponibles.

Résolution du 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 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 peuvent 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 dans le Résolution du scénario 2.)

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

    ID d’événement : 2115
    Source de l’événement : HealthService
    Description de l’événement :
    Une source de données Bind 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 de performances ou fonctionnel avec le workflow.%n ID de flux de travail : %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 d’intégrité local n’est pas sain. Le flux de modification de l’état d’entité est bloqué avec accusé de réception en attente. %n%nManagement Group : %2 %nManagement Group ID : %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 l’instance « %3 » avec id :« %4 » dans le groupe d’administration « %1 ».

    ID d’événement : 31551
    Source d’événement : Modules du service d’intégrité
    Description de l’événement :
    Échec du stockage des données dans l’entrepôt de données. L’opération sera retentée.%rException '%5' : %6 %n%n%nOne ou plus de flux de travail ont été affectés par cela. %n%nWorkflow name : %2 %nInstance name : %3 %nInstance ID : %4 %nManagement group : %1

    ID d’événement : 31552
    Source d’événement : Modules du service d’intégrité
    Description de l’événement :
    Échec du stockage des données dans l’entrepôt de données.%rException '%5' : %6 %n%n%nOne ou plus de flux de travail ont été affectés par cela. %n%nWorkflow name : %2 %nInstance name : %3 %nInstance ID : %4 %nManagement group : %1

    ID d’événement : 31553
    Source d’é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 de l’entrepôt de données, mais le traitement a échoué lors de l’une des opérations suivantes.%rException '%5' : %6 %n%n%nOne ou plus de flux de travail ont été affectés par cela. %n%nWorkflow name : %2 %nInstance name : %3 %nInstance ID : %4 %nManagement group : %1

    ID d’événement : 31557
    Source d’é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 la base de données Data Warehouse. L’opération sera retentée.%rException '%5' : %6 %n%n%nOne ou plus de flux de travail ont été affectés par cela. %n%nWorkflow name : %2 %nInstance name : %3 %nInstance ID : %4 %nManagement group : %1

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

Note

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

Scénarios 4

Tous les agents qui signalent à un serveur d’administration spécifique alternent par intermittence entre les états sains et gris. Ou bien, tous les agents de l’environnement alternent de manière intermittente entre les états sains et gris.

Résolution du scénario 4

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

  • Le serveur parent des agents est temporairement hors connexion.
  • Les agents inondent le serveur d’administration avec des 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é un échec de communication temporaire entre le serveur parent et les agents.
  • Les modifications apportées au pack d’administration (MP) se sont produites. Dans la console Operations Manager, ces modifications nécessitent une configuration Operations Manager et une redistribution mp vers les agents. Si la modification affecte une base d’agent plus grande, 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 à affiner 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’une rafale de mise à jour de configuration (causée par l’importation et la découverte mp), les goulots d’étranglement classiques sont, d’abord, le processeur et le deuxième, les E/S de disque d’installation Operations Manager. Le serveur d’administration est responsable du transfert de fichiers de configuration vers les agents cibles.

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

Passerelle

La passerelle est à la fois liée au processeur et aux E/S liées. Lorsque la passerelle relaye une grande quantité de données, les opérations d’UC et d’E/S peuvent afficher une utilisation élevée. La plupart 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 des agents sont stockées dans une file d’attente persistante sur le disque pour être lues et transférées 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 cumulées générées et tentées d’envoyer lorsque la passerelle était toujours hors connexion.

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

  • Version, édition et numéro de build 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é

    Note

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

  • Niveau RAID (0, , 1ou 0+1 51+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 soutenu par batterie est activé sur le contrôleur de tableau

Résolution des problèmes de performances de 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 stockage. Si la baie de stockage n’est pas à la capacité maximale d’E/S, le prochain goulot d’étranglement le plus probable est le processeur. La base de données connaîtra des ralentissements occasionnels et des tempêtes de données opérationnelles (incidence élevée des événements, des alertes et des données de performances ou des modifications d’état qui persistent pendant une durée relativement longue). Une courte rafale ne provoque généralement aucun retard significatif pendant une période prolongée.

Lors de l’insertion des données opérationnelles, les disques de la base de données sont principalement utilisés pour les écritures. L’utilisation du processeur est due à la saturation de SQL Server. Cela peut se produire lorsque vous avez des requêtes volumineuses et complexes, une insertion de données lourde et le nettoyage de grandes tables (qui, par défaut, se produit à minuit). En règle générale, le nettoyage des événements et des tables de données de performance, même de grande taille, ne consomme pas de ressources de processeur ou de disque excessives. Toutefois, le nettoyage des tables d'alertes et de changements d'état peut demander beaucoup de ressources au niveau du processeur pour les tables volumineuses.

La base de données est également sollicitée par le processeur lorsqu’elle gère les rafales de redistribution de configuration, qui sont causées par les importations MP ou par un changement d’espace d’instance volumineux. Dans ces cas, le service Config interroge la base de données pour la nouvelle configuration de l’agent. Cela entraîne généralement des pics d'activité du processeur dans la base de données avant que le service n'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 stockage. Cela se produit généralement en raison d’insertions de données opérationnelles volumineuses. Dans ces 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 les vues de création de rapports générées manuellement, car celles-ci exécutent des requêtes sur l'entrepôt de données.

L’utilisation du processeur est due à la saturation de SQL Server. Les pics d'activité du processeur peuvent se produire lors de l’activité de partitionnement intense (lorsque les tables deviennent volumineuses, puis partitionnés), 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 constamment se synchroniser.

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

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

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

  • Nombre de processeurs

  • Quantité de RAM

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

  • Indiquer si SQL Server est de 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 de SQL Server, la version 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 de 32 bits et que la RAM est de 4 Go ou plus, vérifiez si le /pae ou/3gb les commutateurs existent dans le Boot.ini. .edmx. Ces options risquent d'être configurées de manière incorrecte si le serveur a été installé à l'origine en disposant de 4 Go ou moins de RAM, et si la RAM a été mise à niveau ultérieurement.

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

    Avec un système doté de plusieurs processeurs, vérifiez le paramètre Degré maximal de parallélisme (MAXDOP) . Dans SQL Server 2008, cette option se trouve sous l’onglet Avancé dans 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. Une valeur de0 est idéale pour les serveurs qui disposent de huit processeurs ou moins. Pour les serveurs qui disposent de plus de huit processeurs, le temps que prend SQL Server pour coordonner l'utilisation de tous les processeurs peut être contre-productif. Par conséquent, pour les serveurs qui disposent de plus de huit processeurs, vous devez généralement définir le degré maximal de parallélisme sur une valeur de 8. Pour ce faire, exécutez la commande suivante dans SQL Query Analyzer :

    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 l’entrepôt de données, la base de données Operations Manager et les fichiers Tempdb

  • Si le logiciel antivirus est configuré pour exclure les données SQL et les fichiers journaux (l’analyse des fichiers de la base de données SQL Server avec un logiciel antivirus peut nuire aux 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 numéro d'unité logique utilisé par SQL Server

  • Si le pack d’administration Exchange 2007 converti est utilisé ou a déjà été utilisé : nombre de lignes de la table dans la LocalizedText base de données Operations Manager et dans la EventPublisher table de 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 performance Description
MSSQL$<instance> : Gestionnaire de mémoires tampons : Espérance de vie de page Durée de conservation des pages dans le pool de mémoires tampons. Si cette valeur est inférieure à 300 secondes, elle peut indiquer que le serveur peut utiliser plus de mémoire. Elle peut également être le résultat d'une 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 vers le disque. En règle générale, la valeur ne doit pas dépasser systématiquement 20 écritures par seconde. L'idéal serait qu’elle soit proche de zéro.
Mémoire : mégaoctets disponibles Les valeurs inférieures à 100 Mo peuvent indiquer une pression sur la mémoire. La pression sur 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 : plage 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 significativement inférieure à la valeur de Process: Private Bytes: _Total, cela indique que les processus ont une pagination trop importante. Une différence de plus de 10 % est probablement significative.

Compteurs pour identifier la pression sur le disque

Capturez ces compteurs de disques physiques 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. Toute valeur inférieure à 50 % peut indiquer un goulot d’étranglement sur le disque.

  • Longueur moyenne de file d’attente du disque : cette valeur ne doit pas dépasser le double du nombre de broches qui se trouvent sur un numéro d’unité logique. Par exemple, si un numéro d’unité logique a 25 broches, une valeur de 50 est acceptable. Toutefois, si un numéro d’unité logique a 10 broches, une valeur de 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 ensemble RAID 0

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

    • RAID 1 : la moitié des disques fonctionnent ; par conséquent, seule la moitié d'entre eux peuvent être comptabilisés vers la file d’attente de disques

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

    • RAID 10 : la moitié des disques fonctionnent ; par conséquent, seule la moitié d'entre eux peuvent être comptabilisés vers la file d’attente de disques

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

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

    • Longueur moyenne de la file d’attente< de disque= # Disques du tableau *2

    • Moyenne disque s/transfert : nombre de secondes nécessaires pour effectuer une opération d’E/S de disque

    • Moyenne disque s/lecture : durée moyenne de lecture des données à partir du disque, en secondes

    • Moyenne disque s/écriture : durée moyenne d’écriture des données sur le disque, en secondes

      Les trois derniers compteurs de cette liste doivent toujours avoir des valeurs d’environ .020 (20 ms) ou moins et ne doivent jamais dépasser .050 (50 ms). Les seuils suivants sont 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 d’E/S sérieux

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

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

    Lorsque le % du temps d’inactivité est faible (10 pour cent 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 en octets et en IOPS, respectivement. Le débit d’un lecteur SAN est très variable et dépend du nombre de broches, de la vitesse des lecteurs et de la vitesse du canal. Le mieux est de vérifier auprès du fournisseur SAN le nombre d'octets et d'IOPS que le lecteur doit prendre en charge. Si le % du temps d’inactivité est faible et que les valeurs de ces deux compteurs ne correspondent pas au débit attendu du lecteur, demandez une assistance supplémentaire au fournisseur SAN.

Le guide de résolution des problèmes de performance de SQL Server offre un aperçu plus approfondi sur la résolution des problèmes de performance du serveur SQL.

Compteurs de performances Operations Manager

Les sections suivantes décrivent les compteurs de performances que vous pouvez utiliser pour surveiller et dépanner les 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 performance
Processeur(_Total)\% de temps processeur
Memory\% Committed Bytes in Use
Performances Interface réseau(*)\Total des octets/s
LogicalDisk(*)\% Temps d’inactivité
LogicalDisk(*)\Avg. Longueur de la file d’attente du disque
Operations Manager traire les compteurs de performances génériques

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

Nom du compteur de performance Description
Process(HealthService)\% Temps processeur
Process(HealthService)\Octets privés Selon le nombre d’agents que cette passerelle gère, ce nombre peut varier et peut être de plusieurs centaines de mégaoctets
Process(HealthService)\Nombre de Threads
Process(HealthService)\Octets virtuels
Process(HealthService)\Plage de travail
Process(MonitoringHost*)\% temps processeur
Process(MonitoringHost*)\Octets privés
Process(MonitoringHost*)\Nombre de Threads
Process(MonitoringHost*)\Octets virtuels
Process(MonitoringHost*)\Plage de travail
Compteurs de performances spécifiques d’Operations Manager

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

Nom du compteur de performance Description
Service de contrôle d'intégrité\Compte de flux de travail
Groupes d’administration du service de contrôle 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 chargés sur les agents. Si cette valeur reste à un niveau élevé pendant longtemps et qu’il n’y a pas beaucoup d’importation de pack d’administration à un moment donné, ces conditions peuvent générer un problème qui affecte le transfert de fichiers.
Groupes d’administration du service de contrôle d’intégrité(*)\Pourcentage d’utilisation de la file d’attente d’envoi Taille de la file d’attente persistante. Si cette valeur reste supérieure à 10 pendant une longue période et qu’elle ne s’annule 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, autrement dit le nombre d’octets entrants avant la décompression.
Connecteur OpsMgr\Octets transmis Nombre d’octets réseau envoyés par la passerelle, autrement dit le nombre d’octets sortants après compression.
Connecteur OpsMgr\Octets de données reçus Nombre d’octets de données reçus par la passerelle, autrement dit la quantité de données entrantes après la décompression.
Connecteur OpsMgr\Octets de données transmis Nombre d’octets de données envoyés par la passerelle, autrement dit la quantité de données sortantes avant la compression.
Connecteur OpsMgr\Connexions ouvertes Nombre de connexions ouvertes sur la passerelle. Ce nombre doit être identique au nombre d’agents ou de serveurs d’administration 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 performance
Processeur(_Total)\% de temps processeur
Memory\% Committed Bytes in Use
Performances Interface réseau(*)\Total des octets/s
LogicalDisk(*)\% Temps d’inactivité
LogicalDisk(*)\Avg. Longueur de la file d’attente du disque
Operations Manager traire les compteurs de performances génériques

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

Nom du compteur de performance Description
Process(HealthService)\% Temps processeur
Process(HealthService)\Octets privés 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)\Nombre de Threads
Process(HealthService)\Octets virtuels
Process(HealthService)\Plage de travail
Process(MonitoringHost*)\% temps processeur
Process(MonitoringHost*)\Octets privés
Process(MonitoringHost*)\Nombre de Threads
Process(MonitoringHost*)\Octets virtuels
Process(MonitoringHost*)\Plage de travail
Compteurs de performances spécifiques d’Operations Manager

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

Nom du compteur de performance Description
Service de contrôle d'intégrité\Compte de flux de travail Nombre de flux de travail qui s’exécutent sur ce serveur d’administration.
Groupes d’administration du service de contrôle d’intégrité(*)\Chargements de fichiers actifs Le nombre de transferts de fichiers que ce serveur d’administration gère. Cela représente le nombre de fichiers de pack d’administration chargés sur les agents. Si cette valeur reste à un niveau élevé pendant longtemps et qu’il n’y a pas beaucoup d’importation de pack d’administration à un moment donné, ces conditions peuvent générer un problème qui affecte le transfert de fichiers.
Groupes d’administration du service de contrôle d’intégrité(*)\Pourcentage d’utilisation de la file d’attente d’envoi Taille de la file d’attente persistante. Si cette valeur reste supérieure à 10 pendant une longue période et qu’elle ne s’annule 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 hors connexion.
Groupes d'administration du service de contrôle d'intégrité(*)\Taux d'abandon des éléments de liaison de sources de données Nombre d’éléments de données annulés par le serveur d’administration pour les actions d’écriture de collecte de données de la base de données ou de collecte de données de l’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 suffisamment rapidement ou parce qu’un rafale d’élément de données se produit. Les éléments de données annulés sont renvoyés par les agents. Une fois la situation de surcharge ou de rafale terminée, ces éléments de données seront insérés dans la base de données ou dans l’entrepôt de données.
Groupes d'administration du service de contrôle d'intégrité(*)\Taux d'entrée des éléments de liaison de sources de données 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 la base de données ou de collecte de données de l’entrepôt de données.
Groupes d'administration du service de contrôle d'intégrité(*)\Taux de publication des éléments de liaison de sources de données Nombre d’éléments de données que le serveur d’administration a écrit 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, autrement dit, 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, autrement dit, la taille des octets sortants après compression.
Connecteur OpsMgr\Octets de données reçus Nombre d’octets de données reçus par le serveur d’administration , autrement dit, 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, autrement dit la taille des données sortantes avant la compression.
Connecteur OpsMgr\Connexions ouvertes Nombre de connexions ouvertes sur le serveur d’administration. Il doit être identique au nombre d’agents ou de serveur d’administration racine qui sont directement connectés à celui-ci.
Modules d’action d’écriture dans la 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, une rafale d’élément de données se produit.
Modules d’action d’écriture dans la base de données OpsMgr(*)\Temps de traitement moyen Nombre de secondes qu’un module d’action d’écriture de base de données prend pour insérer un lot dans une 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’écriture dans l’entrepôt de données OpsMgr(*)\Temps de traitement par lots moyen 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.
Module d’écriture dans l’entrepôt de données OpsMgr(*)\Taille moyenne du lot 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’écriture DW OpsMgr(*)\Lots/s Nombre de lots reçus par les modules d’action d’écriture de l’entrepôt de données par seconde.
Module d’écriture 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.
Module d’enregistreur DW OpsMgr(*)\Nombre d’éléments de données annulés Nombre d’éléments de données annulés par les modules d’action d’écriture de l’entrepôt de données.
Module d’écriture 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.