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

Cet article explique comment résoudre les problèmes dans lesquels un agent, un serveur de gestion ou une passerelle est indisponible ou grisé dans System Center Operations Manager (Operations Manager).

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

Un agent, un serveur de gestion 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 de surveillance .

État Apparence Description
Healthy Coche verte L’agent ou le serveur d’administration s’exécute normalement.
Critique Coche rouge Il y a un problème au niveau de l’agent ou du serveur d’administration.
Inconnu Nom de l’agent gris, coche grise L’observateur de service d’intégrité sur le serveur de gestion qui surveille le service d’intégrité sur l’ordinateur analysé ne reçoit plus de pulsations de l’agent. Le service d’analyse du fonctionnement a reçu précédemment des pulsations et l’État a été signalé comme étant sain. Cela signifie également que les serveurs de gestion ne reçoivent plus aucune information 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 si des problèmes de connectivité se produisent.
Inconnu Cercle vert, aucune coche L’état de l’élément découvert est Unknown. Aucun moniteur n’est disponible pour cet élément découvert spécifique.

Causes d’un État gris

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

  • Échec de pulsation
  • Configuration incorrecte
  • Échec des flux de travail système
  • Problèmes de performances de base de données ou d’entrepôt de données Operations Manager
  • Problèmes de performances d’un serveur de gestion ou d’un 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 à dépanner le problème que l’agent a désactivé, 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 indiquent-ils le même serveur d’administration ?
  • À quelle fréquence les agents entrent-ils dans un État gris ?
  • Comment procédez-vous généralement pour résoudre ce problème (par exemple, redémarrez le service d’intégrité de l’agent, effacez le cache en fonction de la récupération automatique) ?
  • Les alertes d’échec de pulsations sont-elles générées pour ces agents ?
  • Ce problème se produit-il pendant une période spécifique du jour ?
  • Le problème persiste-t-il si vous basculez ces agents vers un autre serveur de gestion ou une autre passerelle ?
  • Quand ce problème a-t-il commencé ?
  • Y a-t-il eu des modifications apportées aux agents, aux serveurs de gestion ou à la passerelle ou au groupe d’administration ?
  • Les agents concernés sont-ils des systèmes en cluster Windows ?
  • Le dossier d’É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 est déterminée par le composant inactif, dans lequel ce composant tombe dans la topologie et l’étendue du problème. Prenez en compte les conditions suivantes :

  • Si les agents qui signalent à un serveur ou une passerelle de gestion spécifique ne sont pas disponibles, la résolution des problèmes doit commencer au niveau du serveur de gestion ou de la passerelle.
  • Si les passerelles qui signalent à un serveur de gestion spécifique sont indisponibles, la résolution des problèmes doit commencer au niveau du serveur de gestion.
  • 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 de gestion ou de la passerelle qui analyse ces objets.
  • Le dépannage commence généralement au niveau immédiatement supérieur au composant non disponible.

Scénario 1

Seuls quelques agents sont affectés par le problème. Ces agents rapportent à différents serveurs de gestion. 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 pour le scénario 1

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

  1. Appliquez le correctif approprié aux systèmes d’exploitation affectés.
  2. Exclure le cache de l’agent de l’analyse antivirus. Pour plus d’informations, consultez la rubrique 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 rapportent à différents serveurs de gestion. 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’il est en cours d’exécution sur le serveur de gestion ou sur la passerelle. Si le service d’intégrité a cessé de répondre, générez un vidage ADPlus dans un mode de blocage de service afin de déterminer la cause du problème. Pour plus d’informations, reportez-vous à la rubrique How to use ADPlus. vbs pour résoudre les problèmes de « blocage » et « crash »

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

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

    ID d’événement : 1103
    Source de l’événement : Santéintégrité
    Description de l’événement :
    Résumé : %2 Rules (s)/Monitor (s) échoué (s) et a été déchargé, %3 les ont atteint la limite d’échec qui empêche le rechargement automatique. Groupe d’administration « %1 ». Il s’agit d’un événement Résumé uniquement, reportez-vous à la rubrique autres événements avec des descriptions des/Monitor (s) de règles déchargées.

    ID d’événement : 1104
    Source de l’événement : Santéintégrité
    Description de l’événement :
    Profil RunAs dans le flux de travail « %4 », l’exécution de l’instance « %3 » avec l’ID « %2 » ne peut pas être résolue. Le flux de travail ne sera pas chargé. Groupe d’administration « %1 »

    ID d’événement : 1105
    Source de l’événement : Santéintégrité
    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 l’ID : « %2 ». Le flux de travail ne sera pas chargé. Groupe d’administration « %1 »

    ID d’événement : 1106
    Source de l’événement : Santéintégrité
    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 l’instance « %3 » avec l’ID : « %2 ». Le flux de travail ne sera pas chargé. Groupe d’administration « %1 »

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

    ID d’événement : 1108
    Source de l’événement : Santéintégrité
    Description de l’événement :
    Un compte spécifié dans le profil exécuter en tant que « %7 » ne peut pas être résolu. Plus précisément, le compte est utilisé dans la référence sécurisée remplacer « %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 exécuter en tant que spécifié ci-dessous, localiser l’entrée du compte tel qu’il est spécifié par son SSID et choisir de distribuer le compte à cet ordinateur si nécessaire, ou modifier le paramètre dans le profil de sorte que l’objet cible n’utilise pas le compte spécifié. % n% nManagement groupe : %1% nRun en tant que profil : %7% nSecureReferenceOverride de noms : %6% nSecureReferenceOverride ID : %4% nObject nom : %3% nObject ID : %2% nAccount SSID : %5

    ID d’événement : 4000
    Source de l’événement : Santéintégrité
    Description de l’événement :
    Un hôte de surveillance ne répond pas ou a cessé de répondre. Le code d’état de la défaillance de l’hôte était %1.

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

    ID d’événement : 21006
    Source de l’événement : connecteur d’Operations Manager
    Description de l’événement :
    Le connecteur d’Operations Manager 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 d’Operations Manager
    Description de l’événement :
    Le connecteur d’Operations Manager 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 la configuration. Consultez le journal des événements sur le serveur pour vérifier la présence de 20000 événements, 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 d’Operations Manager
    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éémettez le certificat si nécessaire .% n certificat heure de début valide : %1% n Certificate date de fin valide : %2

    Source de l’événement : ESE
    Catégorie d’événement : gestionnaire de transactions
    ID d’événement : 623
    Description : santéintégrité ( <PID> ) le magasin de versions de l’instance <instance> (" <name> ") a atteint sa taille maximale de <value> Mo. Il est probable qu’une transaction de longue durée empêche le nettoyage de la Banque de versions et entraîne sa génération en taille. Les mises à jour sont rejetées tant que la transaction de longue durée n’a pas été entièrement validée ou annulée. Transaction de longue durée possible :
    Session <value>
    Session-contexte : <value>
    ThreadId de contexte de session : <value> .
    Nettoyage <value>

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

    • Événements 1102 et 1103 : ces événements indiquent qu’un certain nombre de flux de travail n’ont pas pu être chargés. S’il s’agit des flux de travail 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 provoquer des événements 1102 et 1103. En règle générale, cela se produit en raison d’une exécution inconfigurée en tant que comptes. Par exemple, les comptes d’exécution en tant que 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 de Monitoringhost.exe s’est bloqué. Si ce problème est dû à une incompatibilité de DLL ou à des clés de Registre manquantes, vous pourrez 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 qu’il existe des problèmes de communication entre l’agent et le serveur d’administration. Si l’agent utilise un certificat pour l’authentification mutuelle, vérifiez que le certificat n’est pas arrivé à expiration 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 provenant de l’agent ne parviennent pas au serveur de gestion ou à la passerelle. Essayez d’établir une session Telnet vers le port 5723 de l’agent vers le serveur de gestion. De plus, exécutez une trace réseau simultanée entre l’agent et le serveur d’administration tout en reproduisant les échecs de communication. Cela peut vous aider à déterminer si les paquets atteignent le serveur de gestion et si un périphérique entre les deux composants tente d’optimiser le trafic ou de supprimer des paquets. Pour plus d’informations, consultez la rubrique collecte de données à l’aide du moniteur réseau.

    • ID d’événement 623 : cet événement se produit généralement dans un environnement grand gestionnaire d’opérations dans lequel un serveur de gestion ou un ordinateur agent gère de nombreux flux de travail. Pour plus d’informations, voir 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 ou une passerelle de gestion spécifique 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 de gestion ou la passerelle surveille. Ces charges de travail peuvent inclure des périphériques réseau, des agents multiplateforme, des transactions synthétiques, des agents Windows et des ordinateurs sans agent.

  2. Déterminez si le service d’intégrité est en cours d’exécution sur le serveur de gestion ou sur la passerelle.

  3. Déterminez si le serveur d’administration est exécuté 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 tous les é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 indiquées dans la résolution pour le scénario 2. De plus, 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 de gestion. (Reportez-vous à l’étape 3 de la 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 des problèmes de performances existent sur le serveur d’administration ou Microsoft SQL Server qui héberge la OperationsManager OperationsManagerDW base de données ou :

    ID d’événement : 2115
    Source de l’événement : Santéintégrité
    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 dans %5 secondes. Cela indique un problème de performances ou de fonctionnement avec le flux de travail .% 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 : Santéintégrité
    Description de l’événement :
    Le service d’intégrité locale n’est pas intègre. Le flux de modifications d’état d’entité est bloqué avec l’accusé de réception en attente. % n% nManagement groupe : %2% nManagement ID de groupe : %1

    ID d’événement : 4506
    Source de l’événement : Santéintégrité
    Description de l’événement : gestionnaire des opérations
    Les données ont été supprimées en raison de trop de données en suspens dans la règle « %2 » en cours d’exécution pour l’instance « %3 » avec l’ID « %4 » dans le groupe d’administration « %1 ».

    ID d’événement : 31551
    Source de l’événement : Modules de 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 réessayée .% rException' %5 ' : %6% n% aucun ou plusieurs flux de travail ont été affectés par ce. % n% nWorkflow nom : %2% nInstance : %3% nInstance de session : %4% nManagement groupe : %1

    ID d’événement : 31552
    Source de l’événement : Modules de 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% aucun ou plusieurs flux de travail ont été affectés par cette erreur. % n% nWorkflow nom : %2% nInstance : %3% nInstance de session : %4% nManagement groupe : %1

    ID d’événement : 31553
    Source de l’événement : Modules de service d’intégrité
    Description de l’événement :
    Les données ont été écrites dans la zone de transit de l’entrepôt de données, mais le traitement a échoué sur l’une des opérations suivantes .% rException' %5 ' : %6% n% aucun ou plusieurs flux de travail ont été affectés par cette erreur. % n% nWorkflow nom : %2% nInstance : %3% nInstance de session : %4% nManagement groupe : %1

    ID d’événement : 31557
    Source de l’événement : Modules de 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 réessayée .% rException' %5 ' : %6% n% aucun ou plusieurs flux de travail ont été affectés par ce. % n% nWorkflow nom : %2% nInstance : %3% nInstance de session : %4% nManagement groupe : %1

  6. Les ID d’événement 3155X peuvent également être enregistrés en raison de la configuration de l’exécution ou des autorisations manquantes pour le compte exécuter en tant que comptes.

Notes

Pour résoudre les problèmes liés aux performances de passerelle ou de serveur de gestion, ainsi que les performances SQL Server, consultez la section résolution pour le scénario 4 .

Scénarios 4

Tous les agents qui signalent à un serveur de gestion spécifique se produisent de manière intermittente entre les États sains et les États gris. Ou bien, tous les agents de l’environnement alternent de manière intermittente entre les États sains et les États 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é d’un serveur temporaire sont les suivantes :

  • Le serveur parent des agents est temporairement hors connexion.
  • Les agents submergent le serveur de gestion avec des données opérationnelles, telles que des alertes, des États, des découvertes, etc. Cela peut entraîner une augmentation de l’utilisation des ressources système sur la base de données d’Operations Manager et sur les serveurs d’Operations Manager.
  • Les pannes réseau ont entraîné un échec de communication temporaire entre le serveur parent et les agents.
  • Des modifications du pack d’administration ont eu lieu. Dans la console Operations Manager, ces modifications nécessitent une configuration d’Operations Manager et une redistribution MP vers les agents. Si la modification affecte une base d’agent plus importante, cela peut entraîner une augmentation de l’utilisation des ressources système sur la base de données d’Operations Manager et les serveurs d’Operations Manager.

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

Dépannage des performances de serveur de gestion et de passerelle

Serveur de gestion

Pendant une rafale de mise à jour de configuration (causée par l’importation et la découverte de Pack d’aide), les goulets d’étranglement classiques sont, d’abord, le processeur et le second, le disque d’installation d’Operations Manager. Le serveur de gestion est responsable de la transmission des fichiers de configuration aux agents cibles.

Pour la collecte de données opérationnelles, les goulets d’étranglement sont généralement causés par le processeur. L’e/s disque peut également se trouver à une capacité maximale, mais cela n’est pas aussi probable. Le serveur de gestion 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érationnelles. Il envoie également des accusés de réception (ACK) aux agents ou aux passerelles une fois qu’il reçoit des données opérationnelles, et utilise la mise en file d’attente de disque pour stocker temporairement ces accusés de réception sortants.

Passerelle

La passerelle est à la fois liée au processeur et aux e/s. Lorsque la passerelle relaie une grande quantité de données, les opérations d’UC et d’e/s peuvent afficher une utilisation intensive. La plus grande partie de l’utilisation du processeur est causée par la décompression, la compression, le chiffrement et le déchiffrement des données entrantes, ainsi que par le transfert de ces données. Toutes les données reçues par la passerelle et à partir des agents sont stockées dans une file d’attente permanente sur le disque, pour être lues et transmises au serveur de gestion 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 déconnectée et doit ensuite gérer les données d’agent accumulées que les agents ont générées et qu’elles essaient d’envoyer lorsque la passerelle était toujours hors connexion.

Pour résoudre le problème dans ce cas, collectez les informations suivantes pour chaque serveur de gestion ou passerelle concerné :

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

  • Nombre de processeurs

  • Quantité de RAM

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

  • Si le logiciel antivirus est configuré pour exclure le magasin de service d’intégrité

    Notes

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

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

  • Nombre de disques utilisés pour le RAID

  • Si le cache d’écriture sauvegardé sur batterie est activé sur le contrôleur de groupe

Dépannage des performances de SQL Server

Base de données opérationnelles ( OperationsManager )

Pour la OperationsManager base de données, le goulot d’étranglement le plus probable est le groupe de disques. Si la baie de disques n’a pas une capacité d’e/s maximale, le goulot d’étranglement le plus probable est le processeur. La base de données subira des ralentissements et des tempêtes de données opérationnelles (des événements élevés, des alertes et des données de performances ou des changements d’État qui persistent pendant une période relativement longue). Un petit pic ne provoque généralement pas de retard significatif pendant une période prolongée.

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

La base de données est également liée au processeur lorsqu’elle gère les rafales de redistribution de configuration, provoquées par les importations de MP ou par un changement d’espace d’instance important. Dans ce cas, le service de configuration interroge la base de données pour obtenir la nouvelle configuration de l’agent. Cela entraîne généralement des pics d’utilisation de l’UC sur 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 le groupe 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 les vues de création de rapports générées manuellement, car elles exécutent des requêtes sur l’entrepôt de données.

L’utilisation de l’UC est due à l’évolution de SQL Server. Les pics d’utilisation du processeur peuvent se produire pendant une activité de partitionnement intense (lorsque les tables deviennent volumineuses, puis partitionnées), 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 effectuer une synchronisation en permanence.

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

Pour résoudre le problème dans ce cas, collectez les informations suivantes pour chaque serveur de gestion ou passerelle concerné :

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

  • Nombre de processeurs

  • Quantité de RAM

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

  • Si SQL Server est 32 bits et qu’AWE est activé

    Vous trouverez la plupart de ces informations dans SQL Server Management Studio ou dans SQL Server Enterprise 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 comprend la version de 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 supérieure ou égale à 4 Go, vérifiez si les /pae /3gb commutateurs or existent dans le Boot.ini. txt. Ces options peuvent être configurées de manière incorrecte si le serveur a été installé à l’origine avec au moins 4 Go de RAM, et si la RAM a été mise à niveau par la suite.

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

    Sur un système multiprocesseur, vérifiez le paramètre degré maximal de parallélisme (MAXDOP) . Dans SQL Server 2008, cette option est située 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 parfait pour les serveurs qui ont au moins huit processeurs. Pour les serveurs dotés de plus de huit processeurs, le temps nécessaire pour coordonner l’utilisation de tous les processeurs par SQL Server peut être 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 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 contenant des fichiers Data Warehouse ou OPS et tempdb

  • 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 contenant les fichiers Data Warehouse ou OPS et 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 piles sur chaque LUN utilisée par SQL Server

  • Si le pack d’administration Exchange 2007 converti est utilisé ou a déjà été utilisé : nombre de lignes de la LocalizedText table dans la base de données OPS et dans la EventPublisher table de la base de données du Data Warehouse

    Pour déterminer les montants des lignes, exécutez les commandes suivantes :

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

Compteurs permettant d’identifier la pression de mémoire

  • MSSQL$\<instance>: Buffer Manager: Page life expectancy -Durée de conservation des pages dans le pool de mémoires tampon. Si cette valeur est inférieure à 300 secondes, cela peut signifier que le serveur peut utiliser davantage de mémoire. Cela peut également provenir de la fragmentation d’index.
  • MSSQL$\<instance>: Buffer Manager: Lazy writes/sec -L’enregistreur tardif libère de l’espace dans la mémoire tampon en déplacant des pages sur le disque. En règle générale, la valeur ne doit pas dépasser régulièrement 20 écritures par seconde. Idéalement, il serait proche de zéro.
  • Memory: Available Mbytes -Les valeurs inférieures à 100 Mo peuvent indiquer une pression de mémoire. La pression de mémoire est clairement présente lorsque cette quantité est inférieure à 10 Mo.
  • Process: Private Bytes: _Total: Il s’agit de la quantité de mémoire (physique et page) utilisée par tous les processus combinés.
  • Process: Working Set: _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 pour Process: Private Bytes: _Total , cela indique que les processus sont en pagination trop lourd. Une différence de plus de 10% est probablement importante.

Compteurs permettant d’identifier la pression de disque

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

  • % Temps d’inactivité: pourcentage de temps d’inactivité de disque rapporté. Tout ce qui est inférieur à 50% peut indiquer un goulot d’étranglement de disque.

  • Longueur moyenne de file d’attente du disque: cette valeur ne doit pas dépasser le deux fois le nombre de piles sur une LUN. Par exemple, si un LUN comporte 25 piles de disques, une valeur de 50 est acceptable. Toutefois, si une LUN comporte 10 piles, la valeur 25 est trop élevée. Vous pouvez utiliser les formules suivantes basées sur le niveau RAID et le nombre de disques dans la configuration RAID :

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

    • Longueur moyenne de file d’attente de disque <= # (disques dans la batterie) * 2

    • RAID 1: la moitié des disques fonctionnent ; par conséquent, une seule partie peut être comptée vers la file d’attente du disque

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

    • RAID 10: la moitié des disques sont « en activité »; par conséquent, une seule partie peut être comptée vers la file d’attente du disque

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

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

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

    • Moyenne disque s/transfert: nombre de secondes nécessaires pour effectuer une e/s disque

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

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

      Les trois derniers compteurs de cette liste doivent toujours avoir des valeurs d’environ .020 (20 ms) ou inférieures et ne doivent jamais dépasser . 050 (50 ms). Les seuils décrits dans le Guide de résolution des problèmes de performances SQL Serversont les suivants :

      • Moins de 10 ms : très bonne
      • Entre 10-20 ms : OK
      • Entre 20-50 ms : lent, nécessite une attention
      • Plus de 50 ms : goulot d’étranglement d’e/s sérieux
    • Octets disque/s: nombre d’octets transférés vers ou à partir du disque par seconde

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

    Lorsque le pourcentage 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 (disque, octets/ s et transferts disque/s) fournissent une excellente indication du débit maximal du lecteur en octets et en IOPS, respectivement. Le débit d’un lecteur SAN est très variable, en fonction du nombre de piles de disques, de la vitesse des lecteurs et de la vitesse du canal. Le meilleur résultat est de vérifier auprès du fabricant du SAN le nombre d’octets et d’IOPS que le lecteur doit prendre en charge. Si la durée d’inactivité de% est faible et que les valeurs de ces deux compteurs ne correspondent pas au débit attendu du lecteur, demandez à l’éditeur du San de résoudre les problèmes.

SQL Server performance Troubleshooting Guide pour résoudre les problèmes de performances de SQL Server.

Compteurs de performance d’Operations Manager

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

Rôle de serveur de passerelle

Compteurs de performance globaux : ces compteurs indiquent les performances globales de la passerelle :

  • Processeur (_Total) \ % temps processeur
  • Mémoire \ % octets dédiés utilisés
  • Interface réseau (*) \ total des octets/s
  • LogicalDisk (*) \ % temps d’inactivité

Disque logique (*) \Avg. de file d’attente de LengthOpsMgr de processus de traitement des compteurs de performance génériques : ces compteurs indiquent les performances globales des processus d’Operations Manager sur la passerelle :

  • Processus (Santéintégrité) \ % temps processeur
  • Processus (Santéintégrité) \private octets (en fonction du nombre d’agents que cette passerelle gère, ce nombre peut varier et peut être de plusieurs centaines de mégaoctets)
  • Processus (Santéintégrité) \Thread Count
  • Processus (Santéintégrité) \Virtual octets
  • Processus (Santéintégrité) \Working défini
  • Processus (MonitoringHost *) \ % temps processeur
  • Processus (MonitoringHost *) \private octets
  • Processus (MonitoringHost *) \Thread Count
  • Processus (MonitoringHost *) \Virtual octets

Process (MonitoringHost *) \Working SetOpsMgr des compteurs de performance spécifiques : ces compteurs sont des compteurs spécifiques d’Operations Manager qui indiquent les performances de aspects spécifiques d’Operations Manager sur la passerelle :

  • Nombre de Service\Workflow d’intégrité
  • Groupes de gestion du service d’intégrité (*) \Active de fichiers : nombre de transferts de fichiers que cette passerelle gère. Cela représente le nombre de fichiers du pack d’administration qui sont téléchargés vers les agents. Si cette valeur reste à un niveau élevé pendant une longue période 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 de gestion du service d’intégrité (*) \send file d’attente% utilisé : taille de la file d’attente permanente. Si cette valeur reste supérieure à 10 pendant une longue période et qu’elle n’est pas déplacée, cela signifie que la file d’attente est sauvegardée. Cette condition est causée par un système d’Operations surchargé, car le serveur de gestion ou la base de données est trop occupé ou hors connexion.
  • Messages d’Operations Manager Connector\Bytes reçus : nombre d’octets réseau reçus par la passerelle, c’est-à-dire le nombre d’octets entrants avant la décompression.
  • Connector\Bytes d’Operations d’Operations transmises : nombre d’octets réseau envoyés par la passerelle, c’est-à-dire le nombre d’octets sortants après compression.
  • Octets Connector\Data d’Operations Manager reçus : nombre d’octets de données reçus par la passerelle, c’est-à-dire le volume de données entrantes après la décompression.
  • Connector\Data d’Operations Manager (octets) transmis : nombre d’octets de données envoyés par la passerelle, c’est-à-dire le volume de données sortantes avant la compression.
  • Connexions Connector\Open d’Operations Manager : nombre de connexions ouvertes sur la passerelle. Ce nombre doit être le même que le nombre d’agents ou de serveurs d’administration directement connectés à la passerelle.

Rôle de serveur de gestion

Compteurs de performance globaux : ces compteurs indiquent les performances globales du serveur de gestion :

  • Processeur (_Total) \ % temps processeur
  • Mémoire \ % octets dédiés utilisés
  • Interface réseau (*) \Bytes total/s
  • LogicalDisk (*) \ % temps d’inactivité

Disque logique (*) \Avg. de file d’attente de LengthOpsMgr de processus de traitement des compteurs de performance génériques : ces compteurs indiquent les performances globales des processus d’Operations Manager sur le serveur de gestion :

  • Processus (Santéintégrité) \ % temps processeur
  • Processus (Santéintégrité) \private octets-en fonction du nombre d’agents que ce serveur de gestion gère, ce nombre peut varier et cela peut être de plusieurs centaines de mégaoctets.
  • Processus (Santéintégrité) \Thread Count
  • Processus (Santéintégrité) \Virtual octets
  • Processus (Santéintégrité) \Working défini
  • Processus (MonitoringHost *) \ % temps processeur
  • Processus (MonitoringHost *) \private octets
  • Processus (MonitoringHost *) \Thread Count
  • Processus (MonitoringHost *) \Virtual octets

Process (MonitoringHost *) \Working SetOpsMgr des compteurs de performance spécifiques : ces compteurs sont des compteurs spécifiques d’Operations Manager qui indiquent les performances de aspects spécifiques d’Operations Manager sur le serveur de gestion :

  • Compteur d’intégrité Service\Workflow : nombre de flux de travail en cours d’exécution sur ce serveur d’administration.
  • Groupes de gestion des services d’intégrité (*) \Active : nombre de transferts de fichiers que ce serveur d’administration gère. Cela représente le nombre de fichiers du pack d’administration qui sont téléchargés vers les agents. Si cette valeur reste à un niveau élevé pendant une longue période 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 de gestion des services d’intégrité (*) \send file d’attente% utilisé : taille de la file d’attente permanente. Si cette valeur reste supérieure à 10 pendant une longue période et qu’elle n’est pas déplacée, cela signifie que la file d’attente est sauvegardée. Cette condition est causée par un système d’Operations surchargé, car le système d’Operations Manager (par exemple, le serveur d’administration racine) est trop occupé ou hors connexion.
  • Groupes de gestion des services d’intégrité (*) taux de suppression des éléments de la source de données \Bind : nombre d’éléments de données qui sont déposés par le serveur de gestion pour les actions d’écriture de la base de données ou de la collection de données de Data Warehouse. Lorsque cette valeur de compteur est égale à 0, le serveur d’administration ou la base de données est surchargé car elle ne peut pas gérer suffisamment rapidement l’élément de données entrant ou une rafale d’élément de données est en cours. Les éléments de données ignorés seront renvoyés par les agents. Une fois la surcharge ou la 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 de gestion des services d’intégrité (*) taux d’entrée des éléments de la source de données \Bind : nombre d’éléments de données reçus par le serveur de gestion pour les actions d’écriture de la base de données ou de la collection de données de Data Warehouse.
  • Groupes de gestion des services d’intégrité (*) \Bind de publication des éléments de la source de données : nombre d’éléments de données que le serveur de gestion a écrit dans la base de données ou l’entrepôt de données pour les actions d’écriture de la collection de données.
  • Messages d’Operations Manager Connector\Bytes reçus : nombre d’octets réseau reçus par le serveur de gestion, c’est-à-dire la taille des octets entrants avant décompression.
  • Connector\Bytes d’Operations Manager transmis : nombre d’octets réseau envoyés par le serveur de gestion, c’est-à-dire la taille des octets sortants après compression.
  • Octets Connector\Data d’Operations Manager reçus : nombre d’octets de données reçus par le serveur de gestion (autrement dit, la taille des données entrantes après décompression)
  • Connector\Data d’Operations Manager (octets) transmis : nombre d’octets de données envoyés par le serveur de gestion (c’est-à-dire la taille des données sortantes avant compression)
  • Connexions Connector\Open d’Operations Manager : nombre de connexions ouvertes sur le serveur de gestion. Il doit être le même que le nombre d’agents ou de serveurs d’administration racines directement connectés.
  • Modules d’action écriture de base de données Operations Manager (*) \Avg. : nombre d’éléments de données ou de lots reçus par les modules d’action écriture de base de données. Si ce nombre est 5 000, une rafale d’élément de données se produit.
  • Modules d’action de création de base de données d’Operations Manager (*) \Avg. : nombre de secondes qu’un module d’action d’écriture de base de données doit 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 enregistreur du magasin de données d’Operations Manager (*) \Avg., ms : nombre de millisecondes pour l’action d’écriture dans 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 enregistreur du magasin de données d’Operations Manager (*) \Avg. : nombre moyen d’éléments de données ou de lots reçus par l’entrepôt de données Modules d’action en écriture.
  • Module enregistreur du magasin de données d’Operations Manager (*) \ lots/s : nombre de lots reçus par le Data Warehouse écriture de modules d’action par seconde.
  • Module enregistreur du magasin de données d’Operations Manager (*) \data éléments/s : le nombre d’éléments de données reçus par le Data Warehouse écriture de modules d’action par seconde.
  • Module enregistreur du magasin de données d’Operations Manager (*) \Dropped : nombre d’éléments de données supprimés par l’entrepôt de données.
  • Module enregistreur du magasin de données d’Operations Manager (*) \Total : nombre d’erreurs qui se sont produites dans un module d’action d’écriture de Data Warehouse.