Supervision, pourquoi OpsMgr ?

La question m'a été posée récemment et ce n'est pas la première fois : comment doit-on faire pour surveiller efficacement Windows ? Quand ce n'est pas Windows ou, de manière plus ciblée, Active Directory, ce peut être d'autres applications telles que System Center Configuration Manager (ConfigMgr) ou SQL Server et toute la panoplie des logiciels Microsoft.

Si on me pose la question, la première réponse à laquelle on est en droit de s'attendre de ma part, c'est d'utiliser System Center Operations Manager (OpsMgr). Au-delà de cette première réponse, les plus acharnés peuvent avoir envie d'une réponse différente en me pousser dans mes retranchements.

Si j'insiste en restant sur ma position d'OpsMgr, ce n'est pas par intéressement, mais parce que je considère, après avoir travaillé avec d'autres produits, qu'OpsMgr est vraiment la meilleure solution disponible sur le marché pour surveiller efficacement des applications Microsoft. Ces autres produits que je connais, aujourd'hui, forcément moins bien, évoluent, mais il arrive encore trop souvent que j'entende après un incident que le produit de supervision utilisé par les clients n'a rien vu et encore plus fréquemment, n'a rien vu venir quand le problème était sous-jacent.

Certes, il peut y avoir quelques inconvénients à utiliser OpsMgr. Le premier est celui du niveau exigé de performance et de respect des meilleures pratiques. Ce constat signifie que la mise en œuvre d'OpsMgr entraîne généralement plus de travail pour corriger les erreurs qu'un autre produit qui attend que le service ne soit plus rendu pour alerter, parfois. Le second peut être de ne pas disposer d'un véritable moteur de corrélation. Il reste, néanmoins, qu'OpsMgr permet la mise en œuvre d'une surveillance des systèmes et applications de manière la plus optimale qui soit. Les quelques lignes suivantes tenteront de détailler les raisons qui me font préférer OpsMgr aux autres solutions.

Je distingue habituellement différents niveaux de supervision. Certains sont historiques, d'autres relèvent de l'évolution des produits surveillés. OpsMgr les couvrent tous et c'est ce qui en fait une solution idéale.

Le premier niveau correspond à faire simplement un ping des machines, à surveiller si le processeur n'est pas trop occupé et si les disques et la mémoire ne sont pas trop remplis.  Si vous avez OpsMgr et que vous voulez vous contenter de ces indicateurs, pourquoi pas ! C'est dommage, mais faisable en désactivant pas mal de capteurs natifs d'OpsMgr.

Au-delà de ce niveau très basic, certains produits intègrent des compteurs de performance en quantité plus importante. Ils sont également capables d'identifier une sélection d'événements apparaissant dans les journaux d'événements ou journaux des applications. Là arrive la question de connaître la pertinence de tel ou tel compteur et son seuil associé ou de tel ou tel événement. La manière dont OpsMgr répond à cette question est de déléguer le traitement aux équipes qui conçoivent les produits à surveiller. Cette délégation a pu avoir un effet contre-productif dans le passé pas si lointain mais aujourd'hui le passage obligatoire par une vérification de la qualité des packs d'administration est une garantie de qualité.

Au-delà de la connaissance des événements et compteurs pertinents se pose la question de savoir sur quel ordinateur activer l'observation de ces éléments. Pour un cluster, par exemple, seul le nœud actif est intéressant.

Le mode de fonctionnement de la supervision basée sur le mode de démarrage des services était celui de MOM 2005 sur lequel, on peut supposer certains concurrents se basent, encore aujourd'hui, pour construire leur propre solution. Dans une grande majorité des cas, la découverte des services fonctionne encore sur cette base dans OpsMgr 2007. Il reste que d’autres critères sont également utilisés pour identifier la présence d’un composant à surveiller. C’est la raison pour laquelle les scripts de découverte sont un peu plus complexes aujourd’hui que la simple vérification du mode de démarrage des services. Sur la base des composants découverts, les règles et moniteurs se mettent en œuvre.

Dès lors que la supervision détecte un dysfonctionnement, il peut être intéressant d'avoir des informations sur le contexte dans lequel ce dysfonctionnement s'est produit. Combien de fois, les journaux d'événements ne contiennent plus les informations relatives à la période de temps où l'incident s'est produit ? Non seulement OpsMgr collecte et analyse les journaux d'événements et compteurs de performance les plus pertinents, mais, en plus, il collecte ceux permettant un diagnostic plus rapide. Il peut aussi effectuer un diagnostic à la demande ou en réaction de manière à détailler une situation spécifique.

L’évolution des versions récentes des outils de supervision tend à ne pas simplement les analyser du point de vue du système, mais de leur service rendu. Par exemple, pour un contrôleur de domaine, en faisant une demande d’authentification ou, pour un DNS, la demande d’une résolution. Ce niveau de surveillance est plus délicat à mettre en œuvre, mais plus intéressant pour traduire le ressenti des utilisateurs. Il est, en effet, possible qu’un service soit en fonctionnement, mais incapable de fournir le service attendu de sa part ou le délivre, mais avec des performances dégradées. L’analyse des messages dans les journaux d’événements peut parfois, suffire, mais il est plus utile d’aller au-delà.

Dans les critères d’ingénierie de nos produits figure l’obligation de livrer un pack d’administration dans un délai raisonnable. Il n’y a pas d’obligation à livrer l’ensemble des moyens à mettre en œuvre pour surveiller correctement le produit. Tout au plus, peut-on trouver des guides d’exploitation dans lesquels figurent quelques informations. Notre meilleure référence est celle des packs d’administration. C’est ce qui donne l’avantage à notre solution sur la concurrence et qui permet à un client de mettre en œuvre une solution optimisée beaucoup plus rapidement qu’avec les produits de la concurrence. Ce sont ces raisons qui me font préférer OpsMgr aux autres solutions de supervision.

Au passage, si vous cherchez une analyse externe d’OpsMgr sur sa capacité à rendre le service pour lequel il est conçu, je vous invite à consulter le quadrant magique du Gartner Group sur les produits de corrélation d’événements disponibles à l’emplacement suivant :
https://www.gartner.com/technology/media-products/reprints/microsoft/vol2/article5/article5.html

Pour compléter, le quadrant pour les produits de gestion du cycle de vie des PC est également disponible sur :
https://www.gartner.com/technology/media-products/reprints/microsoft/vol2/article6/article6.html

Vous y constaterez que ConfigMgr n’est pas, non plus, mal évalué !