Bug 593932 (PM-355, PRODMGT-355) - Allow Trap OID for SNMP notification to be overridden per-alert definition
Summary: Allow Trap OID for SNMP notification to be overridden per-alert definition
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: PM-355, PRODMGT-355
Product: JBoss Operations Network
Classification: JBoss
Component: Monitoring - Alerts
Version: JON 2.4.0
Hardware: All
OS: All
high
urgent
Target Milestone: ER01
: JON 3.2.0
Assignee: Thomas Segismont
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On:
Blocks: jon3
TreeView+ depends on / blocked
 
Reported: 2010-05-20 04:30 UTC by James Livingston
Modified: 2018-12-03 17:09 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-01-02 20:33:28 UTC
Type: Feature Request


Attachments (Terms of Use)


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

Description James Livingston 2010-05-20 04:30:27 UTC
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 19:53:59 UTC
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 05:03:14 UTC
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 "1.3.6.1.4.1.18016.1.1" and the per-alert OID set to "1.3.6.1.4.1.18016.2.2", 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 = 1.3.6.1.4.1.18016.1.1
Variable Bindings:
  1.3.6.1.4.1.18016.2.2.1=<alert id>
  1.3.6.1.4.1.18016.2.2.2=<resource id>
  1.3.6.1.4.1.18016.2.2.3=<resource name>
  1.3.6.1.4.1.18016.2.2.4=<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.


Regards,
  James

Comment 7 Charles Crouch 2013-03-08 05:06:06 UTC
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 15:52:36 UTC
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 14:02:14 UTC
This is in the latest brew build

Comment 11 Heiko W. Rupp 2013-09-06 14:54:01 UTC
Fixing milestone.


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