Introduction

A feature allowing to supervise and to monitor rulesets lifecycle has been introduced in MRules version 2.6.0.

Several software components are involved:

• One or more MBeans, accessible via JMX.
• An extension allowing to export metrics with Micrometer.
• The rule engine itself which collects data and sends it to the MBeans.

This page presents the features available out of the box, their configuration and the extension possibilities.

Activation

By defaut, MBeans registration in JMX server is deactivated, and so is data collecting.

To activate it, a registration strategy must be chosen and applied.

Les différentes stratégies

“Noop” Strategy

This strategy is the one applied by default: it takes no action and therefore deactivates the feature.

“Global” Strategy

This strategy collects statistics globally for all ruleset instances known in the application. In other words, only one MBean will be registered in the JMX server and will expose aggregated data for all rulesets.

“Per Name” Strategy

This strategy collects statistics related to a specific ruleset instance, identified by its name.

One MBean for each unique name will be registered in the JMX server and will expose data for the instance with this name.

This strategy implies naming rulesets in order to avoid name collisions inside a single app.

Aggregate Strategy

This strategy allows to activate several sub-strategies.

For instance, activating the two strategies “Global” and “Per Name” will imply, for N ruleset instances, N+1 MBeans registered in JMX server:

• The global MBean aggregating data for all rulesets.
• One MBean per unique name.

Auto register

When the data are first collected on a ruleset, if the related MBean does not exist, two different options are possible:

• Auto register: the MBean will be automatically created and registered when firstly used.
• Manual register: The MBean must be registered manually (via the strategy) for the data to be effectively collected.

Applying a strategy

Applying a strategy to replace the default one can be performed in two ways:

• Via MRules global configuration.
• Programmatically.

Please note that the aggrate strategy can only be applied via code.

Via configuration

The “mrules-addons.xml” file must be created at the CLASSPATH root (if not existing already). Its  content should be as follows:

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

The example above  activates the “Per Name strategy . By default, auto register is activated.

To deactivate it:

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

Via code

To change the current strategy, a single line of code is enough. Here’s how to reproduce the two previous examples:

With auto register:

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

Without auto register:

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

Also, here’s how to activate he aggregate strategy:

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

MBean Description

The MBean has several responsabilities :

• Collecting statistics data on the different lifecycle steps of the rulesets.
• Provide actions.
• Send notification to potential subscribers.

Collected data

For each steps in a  ruleset lifecycle (Compilation, Optimization or Execution), the following data is collected and aggregated:

• Total [Compilation / Optimisation / Execution]  Count
• Total Failed [Compilation / Optimisation / Execution] Count
• Total [Compilation / Optimisation / Execution] Time in Nano Seconds
• Last [Compilation / Optimisation / Execution] Time in Nano Seconds
• Last [Compilation / Optimisation / Execution] System Date in Milli Seconds from POSIX time
• Last Failed [Compilation / Optimisation / Execution] System Date in Milli Seconds from POSIX time

Note : currently, collected data do not cover configuration read, meaing the parsing step and the non-compiled instance creation, whether it be using the XML grammar or the business DSL (MRL). This step will be included in a next MRules version.

Actions

The MBean exposes actions:

• “reset” : reset all data to initial state (before first collected data).
• “resetCompilation” : reset compilation related data to initial state (before first collected data).
• “resetOptimisation” : reset optimization related data to initial state (before first collected data).
• “resetExecution” : reset execution related data to initial state (before first collected data).

Notifications

At the end of each lifecycle step of a ruleset, the MBean will emit a notification to the au subsribed consummers. This notification exposes the following information:

• type : lifecycle step name: “COMPILE”, “OPTIMIZE” or “EXECUTE”.
• source: Ruleset metadata, type “MRuleExecutionSetMetadata”.
• duration: Duration between the beginning and the end of the step, in nanoseconds.
• success: “false” if the step exited with error, “true” if successful.

Monitoring extension

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.

Spring Integration

The Spring extension allows to easily autoconfigure the monitoring extension.

Demonstration

The “Batch Test” module in the “Health Care insurance” demo project illustrates the use of all components above.

How to execute this demo project is detailed in a dedicated “How To”.

Extend the feature

As for all MRules components, this feature is made to be extensible.

It’s possible for instnace to implement your own registration strategy in order to aggregate differently statistics on rulesets, for example by URI.

The monitoring extension can also be easily extended with new statistics.