Bug 593932 - (PM-355, PRODMGT-355) Allow Trap OID for SNMP notification to be overridden per-alert definition
Allow Trap OID for SNMP notification to be overridden per-alert definition
Product: JBoss Operations Network
Classification: JBoss
Component: Monitoring - Alerts (Show other bugs)
JON 2.4.0
All All
high Severity urgent
: ER01
: JON 3.2.0
Assigned To: Thomas Segismont
Mike Foley
Depends On:
Blocks: jon3
  Show dependency treegraph
Reported: 2010-05-20 00:30 EDT by James Livingston
Modified: 2016-02-21 19:54 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-01-02 15:33:28 EST
Type: Feature Request
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker PRODMGT-355 Major Closed Allow Trap OID for SNMP notification to be overridden per-alert definition 2014-08-06 22:49:57 EDT
Red Hat Knowledge Base (Solution) 32044 None None None Never

  None (edit)
Description James Livingston 2010-05-20 00:30:27 EDT
Currently SNMP traps for alert notifications are emitted with the Trap OID from global settings, and the prefix for the variable binding OIDs is taken from the alert definition.

It would be nice you could specify a different Trap OID to be used for particular alert definitions.
Comment 3 Charles Crouch 2013-02-21 14:53:59 EST
Targeting for *consideration* for JON3.2.0, the goal being to implement PRODMGT-355. Updating severity to make sure its get triaged.
Comment 5 Charles Crouch 2013-03-08 00:03:14 EST
Here is James' summary which I mentioned in comment #1...

As discussed over the phone, the global OID setting and the per-alert OID setting are used for two different things. Amongst other parts, a SNMP trap contains a "Enterprise OID" which denotes where the trap came from, and a number of key-value pairs calling "variable bindings".

When JON raises a SNMP trap for an alert, it uses the OID set in the global JON settings for the Enterprise OID.

It also adds six pieces of data to the variable bindings, using the per-alert definition OID as a prefix for the keys.

For example if you have the global OID setting set to "" and the per-alert OID set to "", JON will raise a SNMP trap similar to the following (I haven't checked that the suffixes for the data are the right way around):

Enterprise OID =
Variable Bindings:<alert id><resource id><resource name><JON UI url>

So you can see it uses the global setting for the Enterprise OID for all alerts it raises, and the per-alert setting for as a prefix in the variable bindings.

Being able to override the Enterprise OID on a per-alert basis sounds like it could be useful (and I raised a feature request for it), but it is something that JON doesn't currently do.

Comment 7 Charles Crouch 2013-03-08 00:06:06 EST
Some things to think about during implementation:
-How to test upgrades, i.e. customers with existing snmp alerts setup, they should continue to work
-How to handle alert templates.
Comment 9 Thomas Segismont 2013-04-29 11:52:36 EDT
master - 00be4f6ba09fd8f6a1cf55a99a4fd1f6f25130d6

Snmp trap OID is set on v2c and v3 traps as the second variable binding.
In the past, users had been confused by the name of the SNMP notification parameter 'oid'. This parameter actually defines a variable binding prefix for the RHQ
Added tests for this server plugin
Added documentation to the plugin descriptor
Comment 10 Heiko W. Rupp 2013-08-08 10:02:14 EDT
This is in the latest brew build
Comment 11 Heiko W. Rupp 2013-09-06 10:54:01 EDT
Fixing milestone.

Note You need to log in before you can comment on or make changes to this bug.