System Center, by Yann Gainche

J’ai récemment eu une demande d’un client qui souhaitait analyser des journaux de type texte générés par des applications.

Pour réagir à un mot clé dans un fichier texte, il suffit de créer une règle de type ‘Generic Text Log (Alert). Ce type de règle est basé sur un DataSource de type System.applicationLog.GenericLog.FilteredEventProvider.

Cette règle suffit pour réagir à une occurrence d’un mot clé, mais ce client souhaitait dans certains cas consolider des évènements et générer une alerte lors de la répétition d’un mot clé dans un laps de temps donné.

Ce cas est prévu nativement par Operations Manager, mais uniquement pour un moniteur :

Dans ce cas, un moniteur est inapproprié étant donné que l’application ne génère aucun évènement lors d’un retour à une situation normale.

L’idée est donc de créer une règle de génération d’alerte qui utilise les mêmes mécanismes que les moniteurs de type ‘Repeated Event Detection’.

Ce cas n’étant pas prévu dans la console Operations Manager, il faut donc recourir à l’Authoring Console.

Pour rappel, les éléments de supervision (règles, moniteurs, tâches, …) gérés par le service System Center Management (HealthService) sont des workflows composés de plusieurs modules.

La console Operations Manager expose des workflows prédéfinis alors que l’Authoring Console permet de créer ses propres workflows.

De base, un moniteur est composé d’un module DataSource suivi d’un module Condition Detection :

alors qu’une règle de génération d’alerte est généralement composée d’un module DataSource, suivi d’un module Condition Detection puis d’un module Write Action :

Dans le cas du moniteur de type ‘Repeated Event Detection’ pour des évènements d’un journal de type ‘texte générique’, le workflow est le suivant :

Il suffit donc de créer un type de règle personnalisé en utilisant le même principe et en ajoutant le module Write action pour générer l’alerte.

C’est en fait un peu plus complexe. En effet, le module System.ConsolidatorCondition ne fait que réagir à un nombre d’occurrences d’un flux de données identiques provenant du module DataSource en amont. Ce module de consolidation ne filtre pas les données (même s’il peut le faire sur certains champs d’un évènement d’un journal Windows).

Le filtrage des lignes d’un journal texte est effectué par le module DataSource ‘System.applicationLog.GenericLog.FilteredEventProvider’ qui est lui-même un module composite.

Ce module composite est composé d’un module DataSource ‘System.ApplicationLog.GenericLogReader’ qui prend en argument le chemin d’accès et le nom du fichier à analyser et renvoie les données issues du journal vers un module Condition Detection ‘System.ExpressionFilter’ qui permet de filtrer les évènements souhaités. Le module DataSource fournit une donnée de type ‘System.ApplicationLog.GenericLogEntryData’. Le module Condition Detection ‘System.ExpressionFilter’ est capable de traiter n’importe quel type de donnée et ne modifie pas le format. Pour faciliter le traitement de l’information, la donnée en sortie est transmise à un autre module Condition Detection de type ‘System.Event.GenericDataMapper’ afin d’être normalisée dans un format System.EventData et permettre le stockage dans la base de données Operations Manager ainsi que dans le Data Warehouse.

Le workflow d’un moniteur de type ‘Repeated Event Detection’ pour des évènements d’un journal de type ‘texte générique’ est donc finalement le suivant :

Pour créer une règle qui réagit à la répétition d’un évènement dans un journal de type texte, il faut donc reprendre le même workflow et remplacer l’étape State Change du moniteur par un module Write Action pour créer l’alerte. Le Workflow sera le suivant :

Il est possible de faire cela dans l’Authoring Console en créant directement une Custom Rule mais il vaut mieux d’abord créer des modules DataSource et Condition Detection composites afin de permettre le remplacement des paramètres par des overrides.

Exemple

Pour l’exemple, j’ai installé un Proxy Squid sur le disque D: d’une machine. Ce proxy journalise les accès Web dans le journal D:\squid\var\logs\access.log.

Nous allons pouvoir tester la répétition d’évènements en détectant un grand nombre de demandes de rafraîchissement forcées (ce qui se produit sur Internet Explorer en appuyant sur CTRL+F5) dans un court laps de temps.

Dans ce cas, Squid indique dans son journal access.log une demande de type TCP_CLIENT_REFREH_MISS :

Donc, voici comment créer une règle qui va analyser le journal access.log et générer une alerte s’il y a 10 occurrences ou plus du terme TCP_CLIENT_REFREH_MISS  dans un laps de temps de 5 minutes.

Mise en œuvre

Dans l’Authoring Console, créer un pack d’administration vide :

Dans Type Library/Module Types/DataSources, créer un nouveau DataSource composite :

Nommer le module et aller sur l’onglet Configuration Schema :

Dans l’onglet Configuration Schema, il va falloir créer les variables qui seront utilisées dans le module et dans les paramètres sur lesquels il sera possible de faire des overrides.

Le module System.applicationLog.GenericLog.FilteredEventProvider requiert plusieurs paramètres :

- Le répertoire qui contient les journaux

- Le nom du journal (peut accepter des wildcards)

- L’utilisation de l’encodage UTF8

- L’expression recherchée

- L’opérateur

Dans cet exemple, nous allons laisser le codage par défaut et fixer le type d’opérateur sur ‘Matches Regular Expression’. Il faut donc définir des variables pour les autres paramètres.

Dans Simple Configuration Schema, cliquer sur Add et ajouter la première variable :

Vérifier que le type est bien string et créer les 2 autres variables :

Aller sur l’onglet Overridable Parameters et ajouter les trois variables :

On peut noter la syntaxe pour faire appel à ces variables : $Config/[VariableName]$

Dans l’onglet Member Modules, il faut maintenant ajouter le DataSource d’origine System.applicationLog.GenericLog.FilteredEventProvider :

La boîte de dialogue de configuration du module apparaît. Afin d’éviter de saisir le code XML, il faut cliquer sur le bouton Configure. Il faut ensuite entrer le nom des variables créées à l’étape précédente dans les champs Directory et Pattern :

Il faut maintenant cliquer sur l’onglet Expression pour continuer la configuration puis cliquer sur Insert pour ajouter une expression. Dans Parameter Name, on indique Params/Param[1] qui est le seul paramètre de ce type de module et qui désigne la ligne du journal en cours de traitement. On fixe l’opérateur à Matches Regular Expression et on utilise notre variable $Config/Expression$ :

Valider ensuite la configuration et sélectionner Module Output comme module suivant :

La configuration du DataSource composite est terminée. On peut maintenant procéder à la création du module Condition Detection composite. Pour cela, il faut aller dans Type Library/Module Types/Condition Detection et créer un nouveau module composite :

Nommer le module et cliquer sur l’onglet Configuration Schema. Ici, nous allons créer les variables pour indiquer le laps de temps d’analyse et le nombre d’évènements qui constitue le seuil d’alerte. Ces variables doivent être du type Integer :

De la même façon que pour le module DataSource, il faut ajouter ces deux variables dans l’onglet Overridable Parameters :

Il faut ensuite aller dans l’onglet Member Modules et ajouter le module Condition detection System.ConsolidatorCondition :

La boîte de dialogue de configuration du module apparaît. Cliquer sur le bouton Configure et sélectionner le mode Trigger On Count, Sliding puis cliquer sur OK :

Ensuite, on peut remplacer l’intervalle et le nombre d’évènements par les variables créées à l’étape précédente :

Pour terminer ce module, il faut valider la configuration et sélectionner Module Output comme module suivant :

Avant de valider le module, aller dans l’onglet Options pour valider l’option Stateful :

Maintenant que les modules DataSource et Condition Detection sont prêts, il faut procéder à la création de la règle personnalisée.

Dans Health Model/Health Model/Rules, créer une nouvelle Custom Rule :

Nommer la règle et cibler la classe Windows Operating System. Dans Options, mettre enabled à false car on ne veut pas appliquer cette règle à tous les serveurs. Elle sera activée pour certains serveurs par un override :

Dans l’onglet Module, ajouter le module Datasource ‘Filtered Application Log DataSource’ créé précédemment :

Cliquer ensuite sur Edit pour saisir les valeurs par défaut pour les paramètres. Ces valeurs seront adaptées au contexte par un override :

On peut ensuite procéder de la même façon pour le module Condition Detection :

Enfin, on ajoute le module Write Action standard System.Health.GenerateAlert et on paramètre l’alerte (Edit puis Configure):

Dans cet exemple, j’utilise la variable $Data/Context/DataItem/Params/Param[1]$ à la place de la variable par défaut $Data/Context/DataItem/EventDescription$ qui n’a de sens que pour un évènement en provenance d’un journal structuré comme le sont par exemple les journaux Windows. Cela permet d’ajouter dans le texte de l’alerte la ligne du journal.

On peut noter que cette fois, cette variable est préfixée par /Context/DataItem. Lors de la création du DataSource, il a suffi d’indiquer Params/Param[1] dans l’écran de configuration. Dans le fichier XML, cette variable est en fait référencée sous la forme $Data/Params/Param[1]$ qui indique qu’il s’agit d’une donnée locale. Dans le cas de l’utilisation de cette même donnée pour son affichage dans la description de l’alerte, on ajoute /Context/DataItem pour préciser qu’il s’agit d’une variable en provenance du flux de données fourni par le module précédant le module Write Action.

On peut maintenant valider la création de la règle, sauvegarder le pack d’administration et l’importer dans Operations Manager :

Tests

Une fois le pack d’administration importé, il faut faire un override pour activer la règle pour le serveur concerné et indiquer les paramètres :

Dans ce cas, pour tester la règle, il suffit de paramétrer son navigateur pour qu’il utilise le proxy Squid, se rendre sur la page du meilleur moteur de recherche du monde (http://www.perdu.com) et appuyer sur CTRL-F5 plus de 20 fois en une minute.

Dans le pack d’administration en exemple, il y a une règle qui génère une alerte warning pour chaque occurrence en plus de la règle de consolidation.

Attention, si vous donnez comme paramètres 10 évènements en 20 minutes, le décompte du temps commence lors du premier évènement et se termine 20 minutes plus tard. Donc, si vous générez 15 évènements en une minute, l’alerte consolidée n’apparaîtra que 20 minutes après le premier évènement.

Ceci est lié au fait que nous utilisons la méthode de fenêtre glissante OnNewItemTestOutputRestart_OnTimerSlideByOne mais le module de consolidation comporte d’autres méthodes que vous pouvez trouver dans le document de référence des modules : Operations Manager 2007 R2 Management Pack Module Reference.

Vous pouvez télécharger le pack d’administration montré en exemple ici : RepeatedEvents.TestMP.