PI Services

Lors de la création d’un moniteur de performance, il peut arriver qu’il soit nécessaire de superviser plusieurs instances du compteur et d’alerter lorsque n’importe laquelle de ces instances dépasse le seuil paramétré.

La solution qui vient alors immédiatement à l’esprit est alors d’utiliser les wildcard (jokers) dans le nom de l’instance :

Malheureusement, voici ce qui se produit dans ce cas :

Le moniteur détecte bien que l’instance w3wp dépasse le seuil paramétré et passe donc en Critical, mais instantanément après le moniteur détecte que l’instance w3wp#10 est elle toujours sous le seuil et il repasse donc en Healthy : la vérification se fait pour chaque instance du compteur l’une après l’autre, et si un seul d’entre eux n’est pas en critical, le moniteur repasse en vert immédiatement.

Et ce manège recommence à chaque exécution du moniteur…

Une première bonne solution consiste alors à utiliser une variable à la place d’un wildcard en tant qu’Instance.

Prenons l’exemple d’un moniteur de performance qui serait ciblé sur la classe Logical Disk.

Cette classe dispose de propriétés, dont plusieurs correspondent au nom des instances de compteurs :

On peut alors réutiliser une de ces variable dans le champ Instance de l’assistant de création du moniteur, à l’aide de la petite flèche située à sa droite :

On aura donc un moniteur pour chaque instance SCOM de la classe logical disk, ciblé uniquement sur l’instance du compteur de performance qui lui correspond.

Il arrive cependant qu’aucune classe SCOM ne dispose de propriétés utilisables en tant que variable, typiquement en reprenant le premier exemple du process w3wp.exe.

Dans ce cas, une autre solution existe : le module de détection de condition (condition detection module) System.LogicalSet.ExpressionFilter introduit dans SCOM 2007 R2 permet de déterminer quand arrêter le traitement des données provenant d’une datasource lorsque celle-ci renvoie plusieurs résultats (ce qui est le cas quand un System.Performance.DataProvider est ciblé sur plusieurs instances d’un compteur perfmon).

Autrement dit, en utilisant ce module, les valeurs de chaque instance du compteur sont analysées l’une après l’autre. Dès qu’une de ces instances dépasse le seuil défini, le moniteur passe en Critical et s’arrête sans analyser les instances suivantes, empêchant donc le moniteur de repasser en Healthy.

L’utilisation de ce module n’est toutefois pas possible directement depuis la console SCOM et nécessite de créer son propre MonitorType :

</MonitorTypeStates>

<xsd:element name="ComputerName" type="xsd:string" />

<xsd:element name="CounterName" type="xsd:string" />

<xsd:element name="ObjectName" type="xsd:string" />

<xsd:element name="InstanceName" type="xsd:string" />

<xsd:element name="AllInstances" type="xsd:boolean" />

<xsd:element name="Frequency" type="xsd:unsignedInt" />

<xsd:element name="Threshold" type="xsd:double" />

</Configuration>

</OverrideableParameters>

<ComputerName>$Config/ComputerName$</ComputerName>

<CounterName>$Config/CounterName$</CounterName>

<ObjectName>$Config/ObjectName$</ObjectName>

<InstanceName>$Config/InstanceName$</InstanceName>

<AllInstances>$Config/AllInstances$</AllInstances>

<Frequency>$Config/Frequency$</Frequency>

</DataSource>

<XPathQuery Type="Double">Value</XPathQuery>

</ValueExpression>

<Operator>LessEqual</Operator>

<Value Type="Double">$Config/Threshold$</Value>

</ValueExpression>

</SimpleExpression>

</Expression>

<EmptySet>Passthrough</EmptySet>

</ConditionDetection>

<XPathQuery Type="Double">Value</XPathQuery>

</ValueExpression>

<Operator>Greater</Operator>

<Value Type="Double">$Config/Threshold$</Value>

</ValueExpression>

</SimpleExpression>

</Expression>

<EmptySet>Block</EmptySet>

</ConditionDetection>

</MemberModules>

</Node>

</RegularDetection>

</Node>

</RegularDetection>

</RegularDetections>

</MonitorImplementation>

</UnitMonitorType>

</MonitorTypes>

</TypeDefinitions>

On constate que ce module se configure très simplement à l’aide de deux balises xml : EmptySet et SetEvaluation.

EmptySet indique le traitement à appliquer : Passthrough (on continue le traitement des données vers les modules suivants dans le workflow, c’est le mode par défaut) ou Block (qui arrête le traitement du wokflow).

SetEvaluation indique si les données de chaque instance doivent correspondre (All), ou si une seule suffit (Any).

Dans l’exemple ci-dessus, on demande donc d’arrêter le traitement (Block) dès que n’importe quelle instance du compteur (Any) passe au dessus du seuil défini.

Ne reste alors plus qu’à implémenter le Moniteur à proprement parler :

<Category>PerformanceHealth</Category>

<AlertOnState>Error</AlertOnState>

<AlertPriority>Normal</AlertPriority>

<AlertSeverity>Error</AlertSeverity>

</AlertSettings>

</OperationalStates>

<ComputerName>$Target/Host/Property[Type="MicrosoftWindowsLibrary7585010!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>

<CounterName>Private Bytes</CounterName>

<ObjectName>Process</ObjectName>

<AllInstances>false</AllInstances>

</Configuration>

</UnitMonitor>

Et cette fois-ci le moniteur ne bagotte plus, tant que n’importe laquelle des instances du compteur sera au dessus du seuil, le moniteur restera en Critical :

Pour aller plus loin : https://msdn.microsoft.com/en-us/library/hh442318.aspx?f=255&MSPPError=-2147217396

lun.	mar.	mer.	jeu.	ven.	sam.	dim.
28	29	30	31	1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	1
2	3	4	5	6	7	8

Le blog des collaborateurs de PI Services

SCOM - Moniteur de performance multi-instances

Ajouter un commentaire

Articles liés

Ajouter un commentaire