Cette analyse mesure le compteur Groupes d'administration du service de contrôle d'intégrité\Pourcentage d'utilisation de la file d'attente d'envoi du service de contrôle d'intégrité.
Cette analyse mesure le rapport Groupes d'administration du service de contrôle d'intégrité\Pourcentage d'utilisation de la file d'attente d'envoi et génère les états suivants :
État de l'analyse | Seuil Pourcentage d'utilisation de la file d'attente d'envoi |
Critique | 60 % |
Cela peut être dû à une bande passante limitée ou à une latence élevée de la connexion de ce service de contrôle d'intégrité de l'administration System Center à son serveur d'administration parent. Cela peut également s'expliquer par des règles qui collectent un nombre de données excessif par rapport au traitement que peut prendre en charge le serveur d'administration parent, en particulier lorsque le serveur d'administration parent reçoit des rapports de nombreux agents contenant un volume de données important.
Vérifiez auprès de vos administrateurs réseau si la connexion réseau du service de contrôle d'intégrité de l'administration System Center vers les serveurs d'administration parents est saturée. Le cas échéant, il se peut que vous deviez mettre à niveau vos réseaux pour améliorer le trafic.
Si vous ne parvenez pas à mettre à niveau votre réseau (par exemple, si votre service de contrôle d'intégrité de l'administration System Center ou votre serveur de passerelle se trouve dans des locaux éloignés), vous pouvez désactiver les règles de collecte inutiles. Ci-dessous, vous trouverez une liste des types de règle que vous pouvez désactiver ainsi que l'impact de leur désactivation.
Type de règle | Fonction de la règle | Impact de sa désactivation |
Collecte de performance | Collecte les données de performances dans la base de données opérationnelle, le magasin de données ou les deux. | Lorsqu'une règle de collecte de performance est désactivée, tous les affichages indiquent que les données de performances ne disposeront plus de données affichables. Si la règle collectait des données dans le magasin de données, les rapports qui dépendent de cette performance ne fourniront plus de données. |
Collecte d'événements | Collecte des données d'événement à des fins de diagnostic. Dans certains cas, il n'est pas utile qu'un événement fasse l'objet d'une alerte. L'alerte peut cependant être utile dans le cadre d'enquêtes criminelles sur le piratage ou pour des dépannages en temps quasi réel. | Lorsqu'une règle de collecte d'événements est désactivée, tous les affichages indiquent que les données d'événements ne disposeront plus de données affichables. Si la règle collectait des données dans le magasin de données, les rapports qui dépendent de cet événement ne fourniront plus de données. |
Enfin, si vous avez encore besoin de ces données, vous pouvez aussi tenter de réduire le volume de données envoyées par le réseau en utilisant des règles de collecte du compteur de performances et des règles de collecte d'événements optimisées. Le tableau ci-dessous synthétise leur avantage et explique la manière dont les données sont résumées.
Type de règle | Avantage | Comment les données sont-elles résumées ? |
Règle de collecte de performance optimisée | Envoyez l'échantillon de données de performances uniquement s'il diffère du dernier échantillon dans un certain pourcentage. Par exemple, si le dernier échantillon était 42 et que la règle a été configurée pour collecter uniquement dans un nouvel échantillon avec une tolérance de 10 %, l'échantillon suivant devra correspondre à 42 +/- 4,2 (ce qui signifie que l'échantillon suivant devra être supérieur à 46,2 ou inférieur à 37,8). | Dans la mesure où seules les données de performances qui dépassent la tolérance de configuration sont envoyées à la base de données opérationnelle ou au magasin de données, les données seront moins précises. Plus la tolérance est grande, moins la précision est fine. |
Règle de collecte d'événements consolidée | Ce type de règle de collecte d'événements envoie les données si l'un des paramètres de configuration diffère par rapport au dernier événement. Vous pouvez par exemple configurer une règle de collecte consolidée pour consolider des événements pour lesquels les éléments suivants sont identiques :
Vous pouvez ensuite configurer une période pour consolider ces événements (par exemple 10 minutes). Si les critères ci-dessus correspondent à tout événement, dans cette tranche de 10 minutes, seul un événement est envoyé avec sa propriété Nombre de répétitions incrémentée. Si cet événement se produisait fréquemment sur un seul agent, cela signifie que seulement 144 événements seraient envoyés dans une période de 24 heures, un nombre susceptible d'être bien inférieur à celui des événements effectivement enregistrés dans le journal des événements. | Vous devez connaître les paramètres et propriétés d'événements que vous consolidez. Par exemple, une configuration de la description implique que, si la description de l'événement est généralement unique (par exemple, elle contient un nom d'utilisateur), un grand nombre d'événements continuera d'être envoyé. Selon cet exemple, il serait préférable de consolider le paramètre de l'événement qui représente le champ du nom d'utilisateur. Par ailleurs, le fait de définir une période de consolidation de grande taille a deux effets :
|
Consultez l'aide produit ou accédez à l'espace de création de la console pour créer le type de règle mentionnée ci-dessus.
Target | Microsoft.SystemCenter.HealthService | ||
Parent Monitor | Microsoft.SystemCenter.HealthService.PerformanceHealthRollup | ||
Category | PerformanceHealth | ||
Enabled | True | ||
Instance Name | Health Service Management Groups | ||
Counter Name | Send Queue \% Used | ||
Frequency | 60 | ||
Alert Generate | True | ||
Alert Severity | Error | ||
Alert Priority | High | ||
Alert Auto Resolve | True | ||
Monitor Type | System.Performance.ConsecutiveSamplesThreshold | ||
Remotable | True | ||
Accessibility | Public | ||
Alert Message |
| ||
RunAs | Default |
<UnitMonitor ID="Microsoft.SystemCenter.HealthService.Performance.SendQueuePercentUsedMonitor" Accessibility="Public" Enabled="true" Target="SCLibrary!Microsoft.SystemCenter.HealthService" ParentMonitorID="Microsoft.SystemCenter.HealthService.PerformanceHealthRollup" Remotable="true" Priority="Normal" TypeID="Performance!System.Performance.ConsecutiveSamplesThreshold" ConfirmDelivery="false">
<Category>PerformanceHealth</Category>
<AlertSettings AlertMessage="Microsoft.SystemCenter.HealthService.Performance.SendQueuePercentUsedMonitor.AlertMessage">
<AlertOnState>Error</AlertOnState>
<AutoResolve>true</AutoResolve>
<AlertPriority>High</AlertPriority>
<AlertSeverity>Error</AlertSeverity>
<AlertParameters>
<AlertParameter1>$Data/Context/Value$</AlertParameter1>
</AlertParameters>
</AlertSettings>
<OperationalStates>
<OperationalState ID="BelowThreshold" MonitorTypeStateID="ConditionFalse" HealthState="Success"/>
<OperationalState ID="OverThreshold" MonitorTypeStateID="ConditionTrue" HealthState="Error"/>
</OperationalStates>
<Configuration>
<ComputerName>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>
<CounterName>Send Queue % Used</CounterName>
<ObjectName>Health Service Management Groups</ObjectName>
<InstanceName>$Target/ManagementGroup/Name$</InstanceName>
<AllInstances>false</AllInstances>
<Frequency>60</Frequency>
<Threshold>90</Threshold>
<Direction>greaterequal</Direction>
<NumSamples>5</NumSamples>
</Configuration>
</UnitMonitor>