Discussion: Adding node information into events

Especially since we have HELM and the alarm panel feature I was facing the issue, that I now have my alarms in Grafana which is pretty cool but with the disadvantage that I can’t click in the alarm details at the node page link (as you can do in the OpenNMS web UI) to see the node description or maybe asset information to get a clue what the VM is doing/what is running on it. So I have an alarm that is telling me something without a context.

Colleagues are complaining about that, since nobody really knows which node is affected on the basis of an IP address or a label (in my case the label is a FQDN). In my case it’s really annoying.

It took some days to find out that you can add %asset[description]% into an event definition to solve my issue. So now the alarms have this information included. Really nice!

But what next? I mean I’ve added this asset in some custom threshold alarms. But what about all other events that are node related? You may want to add it in all events. And that’s now my issue.

I wrote down the approaches that came into my mind. Some of them could work more or less.

  • adding assets into all default OpenNMS like nodeLostService or datacollectionFailed in my installation. But that will cause merge conflicts every time OpenNMS has changes in those files.
  • adding assets only in the events that usually happen in my environment? The merge conflic is the same pain but maybe with less files.
  • adding assets into the all default node related event files of OpenNMS.
    • Would that be a problem for all the users/customers?
    • Not sure if the people use the node description field. Maybe the events will never show any useful information?
    • And what information would make sense?
  • Enhancing the code in some way to add assets into events on the fly? Maybe configurable, so you can choose the UEI of an event that should be enhanced?
  • Should Grafana be able to present the node assets optional in alarms? But then you don’t have the information in OpenNMS alarms.
  • Maybe an approach that includes the MetaDSL feature?

Would really like to read your thoughts about that topic to figure out which approach would be the best for OpenNMS.