Le blog technique

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 :

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 :

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

Après le déploiement d’une tâche de reboot via SCCM (un simple de shutdown /r à intervalle planifiée sur une collection de serveurs), je me suis rendu compte que quelques serveurs rebootaient en boucle toutes les 5h.

Après mal de questionnement et d’analyse de log, je me suis aperçu que l’agent SCCM se réinstallait à la même fréquence, ce qui expliquait la répétition de la tâche de reboot étant donné son paramétrage assez « souple » (pas de maintenance window…).

Restait à identifier la raison de cette réinstallation… Ni les logs, ni la console SCCM ne contenaient d’information utile.

Pire, même en désactivant le service de l’agent (bloquant ainsi toute communication avec le serveur), il continuait à se réinstaller (et donc à se réactiver) !

La solution est finalement venue comme souvent d’une recherche sur internet, après avoir trouvé les bons mots-clés… Et le coupable s’avère être une tâche planifiée créée par CCMSETUP lors du premier déploiement de l’agent SCCM, dans le dossier Microsoft/Configuration Manager/Microsoft/Configuration Manager (oui, deux fois !) :

Cette dernière est paramétrée pour se relancer toutes les 5h et sert normalement lorsque CCMSETUP n’arrive pas à contacter le serveur SCCM, afin de reprendre le déploiement de l’agent ultérieurement.

Sauf que pour une raison quelconque (la répétition de l’arborescence Microsoft/Configuration Manager) peut faire penser à un bug qui créerait la tâche au mauvais endroit), il arrive que cette tâche planifiée ne soit jamais supprimée, et l’agent se réinstalle donc en boucle indéfiniment…

La solution est alors toute trouvée : il suffit de supprimer (ou au minimum de désactiver) cette tâche planifiée et tout rentre dans l’ordre!