Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Add more flexibility to the syslog alarm northbound implementation

Description

The current implementation only allows to have a common message format and a set of destinations, for all the alarms that that match the supplied list of UEIs if exist, in order to forward the alarm as Syslog message.

I think that adding filtering capabilities, and the ability to change the message format per destination will make the syslog northbound interface more powerful and a lot more flexible.

That being said, the structure of syslog-northbounder-configuration.xml has to be changed. The idea is enhance the current structure to introduce the new features while preserving compatibility with the old structure.

We can introduce another main tag called filter. This tag is going to have the following attributes:

  1. A boolean flag to specify if the filter is enabled

  2. A name for the filter

  3. A filter rule, which should be a SPEL expression built against the NorthboundAlarm class. The incoming northbound alarms have to match the filter in order to be forwarded.

  4. An optional message-format. If it is supplied, it will be used as the format for the target message. Otherwise, the default message-format defined inside the syslog-northbounder-config will be used.

  5. A destination name, the name of the configured destination to be used as a target for the Syslog message.

With this in mind, the new configuration is completely compatible with older versions of OpenNMS, and provides the ability to be fully customizable in order to have custom filters with multiple destination and target formats.

Example:

syslog-northbounder-config.xml

<syslog-northbounder-config> <enabled>true</enabled> <nagles-delay>1000</nagles-delay> <batch-size>100</batch-size> <queue-size>300000</queue-size> <message-format>ALARM ID:${alarmId} NODE:${nodeLabel}; ${logMsg}</message-format> <destination> <destination-name>servers-syslog</destination-name> <host>192.168.1.1</host> <port>514</port> <ip-protocol>UDP</ip-protocol> <facility>LOCAL0</facility> <max-message-length>1024</max-message-length> <send-local-name>true</send-local-name> <send-local-time>true</send-local-time> <truncate-message>false</truncate-message> </destination> <destination> <destination-name>routers-syslog</destination-name> <host>192.168.1.2</host> <port>514</port> <ip-protocol>UDP</ip-protocol> <facility>LOCAL0</facility> <max-message-length>1024</max-message-length> <send-local-name>true</send-local-name> <send-local-time>true</send-local-time> <truncate-message>false</truncate-message> </destination> <destination> <destination-name>elasticsearch</destination-name> <host>192.168.100.10</host> <port>514</port> <ip-protocol>UDP</ip-protocol> <facility>LOCAL0</facility> <max-message-length>1024</max-message-length> <send-local-name>true</send-local-name> <send-local-time>true</send-local-time> <truncate-message>false</truncate-message> </destination> <filter> <name>SNMP Traps for Servers</name> <rule>foreignSource == 'Servers' and uei matches '^.*traps.*'</rule> <destination>servers-syslog</destination> </filter> <filter> <name>SNMP Traps for Routers</name> <rule>foreignSource == 'Routers' and uei matches '^.*traps.*'</rule> <destination>routers-syslog</destination> </filter> <filter enabled="false"> <name>Elastic Search</name> <rule>uei matches '.*'</rule> <destination>elasticsearch</destination> <message-format>ALARM ID:${alarmId} ForeignID:${foreignId}; ${logMsg}</message-format> </filter> </syslog-northbounder-config>

About the example:

  • There are no external UEI list, so the northbounder will match all the alarms.

  • There are 3 destination and 3 filters.

  • Each filter is associated with a particular destination.

  • The first two filters are going to share the default message format.

  • The third filter is going to have a custom format for the message (to show the functionality).

  • The third filter is disabled (to show the functionality).

  • All the rules are based on the content of a particular event parameter.

  • The incoming alarm can match multiple filters.

  • The syslog message will be sent if the filter is enabled and the rule is satisfied.

Because the filter rule will be parsed using SPEL it can be more elaborated and complex if needed.

Backword compatibility

If there are filters defined, they will determine the behavior of the syslog northbounder (even if they are disabled). Otherwise, it will work as it used to (i.e. filtering based on UEIs with multiple destination and a shared message format).

Acceptance / Success Criteria

None

Lucidchart Diagrams

Activity

Alejandro Galue April 2, 2016 at 9:07 AM

Yes

Ronny Trommer April 1, 2016 at 9:19 PM

Seems to be fixed can we delete this branch? https://github.com/OpenNMS/opennms/tree/jira/HZN-563

Alejandro Galue December 21, 2015 at 4:02 PM

Pending:

Create JUnit test to verify the registration/unregistration of the northbounders to be sure they work.

Possible Enhancement:

Check if the content of a destination was changed, and only re-register it, if the content was changed.

Alejandro Galue December 17, 2015 at 5:26 PM

Actually there are no benefits, you're right. I ended up by moving the filters inside the destination. You can still have multiple filters (which is a way to define multiple message format depending on the incoming alarm).

David Hustace December 17, 2015 at 3:52 PM

What are the benefits with it being outside of the destination? If I think about it like destination paths, that means the filters could be reused in other destinations but that additional functionality seems barely incremental.

Fixed

Details

Assignee

Reporter

Components

Fix versions

Affects versions

Priority

PagerDuty

Created December 14, 2015 at 3:53 PM
Updated June 3, 2019 at 7:23 AM
Resolved December 21, 2015 at 4:22 PM