Enable extraction of match groups from regex matches in Event.Mask.Varbind.Vbvalue

Description

Currently there's no way to extract the value of a match group from a regular expression in a vbvalue tag of an eventconf XML. We're increasingly getting requests for this functionality from customers. For example, F5 traps mostly lack a well-defined structure and need extraction from mid-value to get at the relevant portion of a resource name.
Here's an example varbind value from an actual F5 trap:

Node /Common/10.129.1.30 address 10.129.1.30 monitor status down. [ /Common/icmp_default: down ] [ was up for 0hr:1min:10sec ] (slot1)

In a better world, F5 would break up the various valuable bits of information into separate varbinds, but we don't live in that world. So I would like to be able to write an eventconf definition to pull that varbind apart. One way I imagine to do this is by using named-capturing groups in regex:

The result of this regex hitting would be the implicit creation of the following event parameters, in addition to the ones created by Trapd whose names are the numeric OIDs of the trap varbinds:

These parameters must be available in time for subsequent use in a <parameter> tag, e.g.:

<parameter name="whatToDo" value="Go find %nodelabel% and whack slot %parm[slotNum]% with a rubber mallet" expand="true" />

Acceptance / Success Criteria

None

Lucidchart Diagrams

Activity

Show:

Jesse White April 26, 2019 at 2:10 PM

Jeff Gehlbach April 22, 2019 at 4:21 PM
Edited

I like this proposal for its hygiene, but it poses serious problems for the use case that motivated this enhancement request, which is the opennms-omi-plugin project. In summary, that plugin parses event-matching rules in the proprietary syntax of another NMS, translating them to OpenNMS event definitions. It's straightforward to translate the other platform's mechanism for subpatten extraction to regex named-capturing groups, but separating the parameter assignment from the matching would require the plugin to understand what each part of the matching regex does.

A compromise that would still let the OMi plugin do its thing would be if we could put the named-capturing groups in the <vbvalue> and preserve the Matcher that spawned each intrinsic parameter for use in the "inferred" parameter processing phase, where a syntax like the one proposed above could conjure the derived parameters' values. This might look something like:

Jesse White April 22, 2019 at 3:49 PM

Looking at this closer now, I don't think it's a good approach to add the parameter extraction logic within the matching code of the varbinds - these are used to determine whether or not a particular event definition should match, and should not modify the underlying event (i.e. by adding parameters) when performing the match.

Instead, I propose that we enrich the %parm[]% placeholder syntax to support substring extraction via regex. The syntax could look something like %parm[<name>~<regex>]%

In the example given above, we could achieve the desired behavior by adding the following parameters to the event:

Jesse White April 2, 2019 at 8:49 PM

The proposed method should work.

There's no easy way of getting the named capture groups of the regex though, so we'd need to resort to parsing the regex itself using something like what's proposed here: https://stackoverflow.com/questions/15588903/get-group-names-in-java-regex

Fixed

Details

Assignee

Reporter

Components

Sprint

Fix versions

Affects versions

Priority

PagerDuty

Created March 25, 2019 at 9:09 PM
Updated May 16, 2019 at 2:18 PM
Resolved May 16, 2019 at 2:18 PM