Débutons par un bref rappel sémantique : dans SCOM, le terme workflow désigne l’ensemble des éléments qui constituent un moniteur, une règle, une découverte ou une tache. Un workflow peut donc être constitué d’une data source, d’une ou plusieurs probes, de condition detections, de writeactions…
La grande majorité des Management Packs contient des workflows consistant en un assemblage de modules préexistants, par exemple :
- Une datasource basée sur le module “scheduler” pour déclencher le workflow à intervalle régulier
- Une probe basée sur le module “powershell script” pour exécuter un script. C’est ce dernier qui ira effectuer des tests et en renverra le résultat dans le workflow
- Une ou plusieurs condion detections basées sur le module “Filter”, afin de détecter si le résultat du script indique un problème ou non
- Une writeaction pour déclencher l’alerte si le filtre indique un problème.
Ces modules préexistants sont la vraie fondation de tout workflow SCOM, et leur code est en général du C# contenu dans une dll : c’est ce que l’on appelle des Modules Natifs (“native modules”).
Certains Management Packs poussent ce principe encore plus loin, en intégrant des modules créés de toutes pièces et dédiés à leur utilisation au lieu d’intégrer les modules natifs dans leurs workflows : on les appelle des modules managés (managed modules).
Les raisons de ce choix sont le plus souvent :
- L’ajout de fonctionnalités irréalisables autrement
- La réutilisation de code compilé préexistant
- L’optimisation des performances des workflows : en effet, un workflow powershell tel que décrit ci-dessus permet de découvrir l’immense majorité des cas rencontrés. Cependant, il nécessite une exécution du script complète à chaque fois : chargement de powershell, chargement des modules powershell, authentification sur l’application à interroger, collecte des données puis déconnexion, déchargement de powershell etc. Un managed module reste lui en mémoire indéfiniment et peut ainsi ne boucler que sur la partie “collecte des données”, ce qui allège grandement le traitement.
Malheureusement cette technique impacte aussi fortement la lisibilité du code et la possibilité de le débugger par n’importe qui, puisque tout ou partie du workflow est maintenant “caché” dans une dll.
Prenons un exemple concret : les dernières versions du Management Pack pour SQL Server intègrent des managed modules, et il arrive parfois que l’alerte suivante se déclenche : MSSQL on Windows: Database is in offline/recovery pending/suspect/emergency state.
Pourtant, le détail de l’alerte n’est pas toujours probant puisqu’il peut n’indiquer que les informations suivantes :
- MonitoringStatus : Bad
- DatabaseState : ONLINE
- IsAccessible : false
- IsMirroringMirror : false
- IsAlwaysOnReplica : true
- ErrorCode : 0
- ErrorDescription : <vide>
Très insuffisant pour comprendre d’où vient le problème… Dans ce genre de cas, il est donc nécessaire d’aller voir comment fonctionne le moniteur d’où provient l’alerte pour tenter de comprendre son passage en échec. En remontant le fil du workflow, on constate que les tests à proprement parler sont réalisés dans une Probe nommée MSSQL on Windows: Database Status Probe Action, dont il n’est pas possible de voir le fonctionnement directement dans le code du Management Pack puisqu’elle repose sur un Managed Module :
Nous avons cependant deux informations utiles :
- Assembly : c’est le nom de la dll qui contient le code compilé du module
- Type : c’est le nom de la fonction qui produit les données utilisées par le moniteur.
La dll peut être récupérée sur n’importe quel serveur SQL disposant d’un agent SCOM dans le dossier Health Service State, ou en l’extrayant du fichier .mpb du management pack avec l’outil MPBUtil de Silect.
Elle peut ensuite être ouverte à l’aide de l’outil gratuit JetBrains dotPeek.
Une fois ouverte, on retrouve la fonction DBStatusMonitoring en suivant l’arborescence :
Un clic-droit > go to implementation permet de retrouver le code exécuté par cette fonction à proprement parler et, en particulier, une zone que l’on interprète facilement comme étant l’exécution d’une requête SQL résultant en plusieurs champs qui correspondent complètement aux détails de notre alerte d’origine :
Cependant, la requête SQL a proprement parler n’est pas visible ici. Elle est en réalité contenue dans une “Ressource” (un champ texte annexe de la dll) nommée GetDBStatuses :
Retournons donc dans l’explorateur de la dll pour ouvrir les ressources, dans laquelle nous allons rechercher GetDBStatuses. Et voilà notre requête SQL :
Vous pouvez désormais copier cette requête et l’analyser et l’exécuter manuellement pour comprendre d’où provient l’alerte!
D’autres modules managés auront un fonctionnement différent, mais le principe d’analyse restera identique… A vous de jouer!
