22. 11. 2023 Attilio Broglio NetEye, Unified Monitoring

Improve Tornado Rules with a Mapping Modifier

Some years ago, one of my colleagues wrote an article about how to “Avoid Tornado Rules Repetition with a Map Post-modifier”. He presented an interesting and very useful way for creating Tornado rules without rewriting them. The core of his approach was based on the Mapping modifier, a functionality in the previous Tornado GUI that was a sort of hidden feature. In order to enable it, users needed to edit the rules in an “advanced” mode, adding the mapping modifier part inside the JSON configuration.

    "modifiers_post": [
      {
        "type": "Lowercase"
      },
      {
        "type": "Map",
        "mapping": {
          "high": "my-template-1",
          "medium": "my-template-2",
          "low": "my-template-3"
        },
        "default_value": null
      }
    ]

Beginning with NetEye 4.32, Wuerth Phoenix introduced a new tornado GUI that provides an easier configurator. So let’s see two use cases that we can simplify by using this modifier.

First use case

Suppose Tornado receives an event with an alarm-status-value of event.payload.alarm_status, and we want to set the exit status and exit_value for a smart_monitoring action. Using the with section with the mapping modifier, we can write 1 rule instead of 4. Let’s further assume that the alarm_status of the event can have one of the values (“clear”, “warn”, “fatal”, “unknown”), and from this we want to set the exit status to the Icinga value/label (0/”OK”, 1/”WARNING”, 2/”CRITICAL”, 3/”UNKNOWN”). Using the new dashboard we can add a “WITH” variable definition and click on the “+” button in modifier, choosing the “Map” options.

So we can perform this action for the two new variables exit_value and exit_label that can be used, for example, in the smart_monitoring_action linked to this rule:

Second use case

Tornado receives events from some devices with several fields, but only the IP address (in event.payload.address) can be used to identify the event source. These devices are kept in Icinga with a human friendly ID (i.e. FQDN ) rather than the IP address. When the user tries to add/remove a comment or change the status of the Host, it can’t link the event with the Icinga object because of the different keys.

A user can certainly write N rules (with an ad-hoc filter) that map in a hard-coded way the Hostname whenever the event has a particular IP, or instead they can use a mapping and write 1 single rule. In order to perform this, they can define a variable in the “WITH” section and then create a “look-up” table in the Mapping section.

Conclusion

This early feature available in the new Tornado GUI allows us to reduce the complexity of rules and to keep them maintainable and performance-friendly. Working this way can solve a lot of the problems surrounding scaling up and maintaining Tornado rules.

These Solutions are Engineered by Humans

Did you find this article interesting? Does it match your skill set? Programming is at the heart of how we develop customized solutions. In fact, we’re currently hiring for roles just like this and others here at Würth Phoenix.