Introduction

La fonctionnalité permettant de superviser les rulesets et leur cycle de vie est disponible depuis la version 2.6.0 de MRules.

Plusieurs composants logiciels entrent en jeu :

• Un ou plusieurs MBeans, accessibles via JMX.
• Une extension permettant l’export de métriques via Micrometer.
• Le moteur de règles en lui même qui collecte les données vers les MBeans.

Cette page présente les différentes fonctionnalités disponibles nativement, leur configuration et les possibilités d’extension.

Activation

Par défaut, l’enregistrement de MBeans dans le serveur JMX est désactivé, ainsi que la collecte des données.

Pour l’activer, il est nécessaire de choisir une stratégie de collecte et de l’appliquer.

Les différentes stratégies

Stratégie « Noop »

C’est celle qui est appliquée par défaut : elle n’effectue aucune action et par conséquent désactive la fonctionnalité.

Stratégie « Globale »

Cette stratégie permet de récolter des statistiques globales à toutes les instances de moteur connues dans l’application. En d’autres termes, un seul MBean sera présent dans le serveur JMX et exposera une agrégation des données des différents rulesets.

Stratégie « Par Nom »

Cette stratégie permet de récolter les statistiques liés à une instance spécifique du moteur de règle, identifiée grâce à son nom.

Un MBean par nom unique sera enregistré dans le serveur JMX et exposera les données de l’instance ayant ce nom.

Cette stratégie implique que le nommage des rulesets soit fait de manière à éviter les collisions au sein d’un même applicatif.

Stratégie d’agrégation

Cette stratégie va permettre d’activer plusieurs sous-stratégies.

Par exemple, activer les deux stratégies « Globale » et « Par Nom » permettra d’avoir, pour N instances de rulesets, N+1 MBeans enregistrés dans le serveur JMX :

• Le MBean global agrégeant les données de tous les rulesets.
• Un MBean par nom unique.

L’auto enregistrement

Si, lors de la récolte de données sur un ruleset, le MBeans nécessaire n’existe pas, deux comportement sont possibles :

• Auto enregistrement : le MBean sera automatiquement créé et enregistré lors de sa première utilisation.
• Enregistrement manuel : l’enregistrement doit être fait explicitement (via la stratégie) pour que les données soit effectivement collectées.

Application d’une stratégie

L’application d’une stratégie en lieu et place de celle par défaut peut être faite de deux façon :

• Via la configuration globale de la solution.
• Programmatiquement.

A noter que la stratégie d’agrégation ne peut être appliquée que programmatiquement.

Via configuration

Le fichier « mrules-addons.xml » doit être créé à la racine du CLASSPATH (si non existant). Son contenu doit être le suivant :

<mrulesconfig priority="1">
  <jmx-registration-strategy class="com.massa.mrules.jmx.MRulesJmxNameRegistrationStrategy" />
</mrulesconfig>

L’exemple ci-dessus permet d’activer la stratégie « Par Nom ». Par défaut l’auto-enregistrement est activé.

Pour le désactiver :

<mrulesconfig priority="1">
  <jmx-registration-strategy class="com.massa.mrules.jmx.MRulesJmxNameRegistrationStrategy" auto-register="false" />
</mrulesconfig>

Via code

Pour changer la stratégie en cours, une simple ligne de code est suffisante. Voici l’équivalence des deux exemples précédents :

Avec auto enregistrement :

MAddonsFinder.setJmxRegistrationStrategy(new MRulesJmxNameRegistrationStrategy(), true);

Sans auto enregistrement :

MAddonsFinder.setJmxRegistrationStrategy(new MRulesJmxNameRegistrationStrategy(), false);

Egalement, voici comment activer la stratégie d’agrégation :

MAddonsFinder.setJmxRegistrationStrategy(new MRulesJmxAggregateRegistrationStrategy(
    new MRulesJmxGlobalRegistrationStrategy(), new MRulesJmxNameRegistrationStrategy()), true);

Description du MBean

Le MBean porte plusieurs responsabilités :

• La collecte d’information statistiques sur les différentes étapes du cycle de vie des rulesets.
• L’exposition d’actions.
• L’envoi de notification aux éventuels clients s’y étant abonné.

Données collectées

Pour chaque étape du cycle de vie d’un ruleset (Compilation, Optimisation et Exécution), les données suivantes sont collectées et agrégées :

• Nombre Total de [Compilation / Optimisation / Exécution]
• Nombre Total de [Compilation / Optimisation / Exécution] échouées
• Durée totale de [Compilation / Optimisation / Exécution] en Nano Seconds
• Durée de la dernière [Compilation / Optimisation / Exécution] en Nano Seconds
• Date système de la dernière [Compilation / Optimisation / Exécution] en Milli Secondes depuis POSIX time
• Date système de la dernière [Compilation / Optimisation / Exécution] échouée en Milli Secondes depuis POSIX time

Remarque : actuellement, les données collectées ne concernent pas l’étape de lecture de la configuration, à savoir le parsing et la création de l’instance non compilée, que ce soit via la grammaire XML ou fonctionnelle (MRL). Cette étape sera incluse lors d’une prochaine version de MRules.

Actions

Le MBean propose également des actions :

• « reset » : permet de réinitialiser les données à l’état initial (i.e. avant la première collecte).
• « resetCompilation » : permet de réinitialiser les données relatives à la compilation à l’état initial (i.e. avant la première collecte).
• « resetOptimisation » : permet de réinitialiser les données relatives à l’optimisation à l’état initial (i.e. avant la première collecte).
• « resetExecution » : permet de réinitialiser les données relatives à l’exécution à l’état initial (i.e. avant la première collecte).

Notifications

A la fin de chaque étape du cycle de vie d’un ruleset, le MBean enverra une notification aux clients s’y étant abonnés. La notification contient les informations suivantes :

• type : Etape du cycle de vie : « COMPILE », « OPTIMIZE » ou « EXECUTE ».
• source : Les méta data du ruleset, de type « MRuleExecutionSetMetadata ».
• duration : La durée écoulée entre le début et la fin de l’étape, en nanosecondes.
• success : « false » si l’étape s’est terminée avec une erreur, « true » si sans erreur.

Extension de monitoring

Dans un contexte industriel, il est fréquent que les données de monitoring applicative soit exportées vers une « Time Scale Database », ceci permettant de surveiller le comportement de l’application sur des tableaux de bord et de détecter les dysfonctionnement.

Dans cette optique, une extension est mise à disposition, afin de faciliter la mise en place de l’export des données disponibles via JMX vers la stack de monitoring.

L’extension est basée sur Micrometer pour la récolte les données, ce qui permet ensuite de les exporter vers un grand nombre de systèmes avals différents (par exemple Prometheus, auformat Open Metrics).

L’extension propose deux modes :

• Le mode standard : expose directement les données agrégées disponibles dans tous les MBeans connus.
• Le mode détaillé : utilise les notifications émises par les MBeans pour calculer des statistiques plus détaillées, telles qu’une distribution des temps d’exécution par exemple.

Intégration Spring

L’extension Spring permet d’autoconfigurer simplement l’extension de monitoring.

Démonstration

Le module « Batch Test » du projet exemple « Assurance santé » démontre l’utilisation de tous les composants ci-dessus.

L’exécution de ce projet exemple est détaillée dans un article « How To » dédié.

Étendre la fonctionnalité

Comme tous les composants de MRules, cette fonctionnalité est conçue pour être extensible.

Il est possible par exemple d’implémenter sa propre stratégie pour agréger différemment les statistiques sur les rulesets, par exemple par URI.

L’extension peut également être facilement enrichie avec de nouvelles statistiques.