Skip to:

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

Option for poller to only generate outage if condition met, not if unreachable

Description

David replied to a message I posted in discuss which I'll post at the bottom requesting that I create a bug (more of a feature request). If possible at some point I'd like an outage to be generated from a poller only if the specific condition in the poller is met, and not generate an outage if the device is merely 'unsnmpable' or unreachable. Example in pasted email below:

---------------
Hi,

I've defined some custom pollers in poller-configuration.xml which use
the snmpmonitor to look for an oid, and an operator/operand pair, for
example:

<service name="AlarmACmains" interval="300000"
user-defined="true" status="on">
<parameter key="retry" value="2"/>
<parameter key="timeout" value="10000"/>
<parameter key="port" value="161"/>
<parameter key="oid" value=".1.3.6.1.4.1.12148.9.7.1.11.0"/>
<parameter key="operator" value="!="/>
<parameter key="operand" value="1"/>
</service>

This works okay, but if the device is actually node down or powered off,
the poller service still has an 'outage'. While I appreciate this might
be the correct behavior in some circumstances, I'd rather it only
actually give an outage if the value returned is specifically wrong
(i.e. 1) not if it just cannot receive a response to the snmp query -
otherwise I'll continually get sms'd that AC mains has gone, when there
has just been a network blip (which I might not care about). Is this
possible, or am I just misunderstanding the use of pollers? I did
notice the serviceUnresponsiveEnabled flag, but I don't think this is
what I'm looking for, as I think that'd still produce an outage if it
cannot connect to the port.

Any advice anyone?

Thanks.
Robin.

Environment

Operating System: Linux Platform: PC

Acceptance / Success Criteria

None

Lucidchart Diagrams

Activity

Martin Lärcher April 26, 2018 at 10:34 AM

temporary workaround for this issue:

add varbind matching to notification in notifications.xml to avoid a message for this behaviour:

<varbind>          <vbname>eventReason</vbname>          <vbvalue>~^(?i)(?:(?!(Unknown|SNMP poll failed)).)*$</vbvalue> </varbind>

 But this only work if parameter eventReason exists - so a reason-template must be configured in poller-configuration.xml for SnmpMonitor !

Martin Lärcher April 25, 2018 at 2:31 PM

any updates for this issue?

Martin Lärcher October 16, 2015 at 3:08 AM

This behaviour is still present in version 16.03-1.
A option like ignore-unresponsive-agent as suggested from Antonio Russo in http://issues.opennms.org/browse/NMS-4632 would be awesome.
We get a lot of these false positives....

Martin Lärcher June 27, 2012 at 9:00 AM

This also in OpenNMS version 1.10.3.
We get a lot of Service-Outages if node are reachable but snmp are down (firewall, congestion etc.) for services monitored with SNMP-Monitor.
This event logmsg appear:
<Service> outage identified on interface x.x.x.x with reason code: Unknown.

So "reason code: Unknown" should be not detected as outage.

Details

Assignee

Reporter

Labels

Components

Affects versions

Priority

PagerDuty

Created December 9, 2009 at 6:07 PM
Updated July 26, 2023 at 2:20 PM

Flag notifications