Bug 744262

Summary: [RFE] Request adding parent and grandparent resource name to SNMP Alerts
Product: [Other] RHQ Project Reporter: dsteigne
Component: AlertsAssignee: Larry O'Leary <loleary>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: medium Docs Contact:
Priority: high    
Version: 3.0.1, 4.1CC: asantos, hrupp, ian.springer, loleary, mazz, mbenmans, mshirley, sappleto
Target Milestone: ---Keywords: NeedsTestCase, Reopened
Target Release: JON 3.1.0   
Hardware: All   
OS: All   
See Also: https://bugzilla.redhat.com/show_bug.cgi?id=966294
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-03-14 11:06:37 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 782579    
Description Flags
Patch for the MIB change
SNMP plugin change path file none

Description dsteigne 2011-10-07 12:20:49 EDT
Description of problem:

Request ability to have the name of the JBoss instance as part of the SNMP alerts, which is in most cases the parent or the grand parent of the monitored resource.

Version-Release number of selected component (if applicable):
Comment 1 Shaun Appleton 2011-10-21 09:20:43 EDT
Assigned to Larry base on new RFE process
Comment 2 Mohamed Hamza Ben Mansour 2011-11-02 17:38:37 EDT

As for email alert, we can include the resourceHierarchy(obtained via the ResourceManager.getResourcesAncestry)  in the information sent by the SnmpTrapSender.sendSnmpTrap. 

The customer need is to directly identify the AS instance when alerts happen on resources such as MemoryPools or web connectors.

Best Regards, 
Comment 3 Mohamed Hamza Ben Mansour 2011-12-20 11:16:51 EST
Created attachment 548879 [details]
Patch for the MIB change
Comment 4 Mohamed Hamza Ben Mansour 2011-12-20 11:17:26 EST
Created attachment 548880 [details]
SNMP plugin change path file
Comment 5 Heiko W. Rupp 2011-12-21 12:20:38 EST
47086c0 in master
Comment 6 Charles Crouch 2012-01-16 23:04:54 EST
Pushing back to ONQA to understand more about how this was tested. SNMP alert notifications would be a good thing to automate the testing of
Comment 10 Mike Foley 2012-01-17 16:25:42 EST
1) Added keyword:  "NeedsTestCase"

2) Documenting existing testcases

Alert Sender SNMP Testcase:  

Email Alert Sender Testcases  (from comment #2):  

General Alert Sender Testcases
https://tcms.engineering.redhat.com/plan/2883/  ... testcases 62040 thru 62051

Sunil ... please add or update a TCMS testcase for the change in this specific BZ, and schedule a regression test of these 2 testcases:


Jeeva ... please consider adding a CLI test for this ... perhaps building on the existing developer-owned Alert CLI test named testAlerts.js located in rhq/modules/cli-tests
Comment 11 Charles Crouch 2012-01-24 11:20:11 EST
Upgrades need to be tested, such that existing customers that have SNMP alerts set  can continue to work unchanged.
Comment 12 John Mazzitelli 2012-02-17 10:13:26 EST
FYI: when I run the unit test that came with this patch ResourceManagerBeanTest.testResourceLineage (which, btw, has tabs in the source - a no-no), it succeeds the first time, but fails the second time and thereafter:

ERROR 16-02 21:20:31,611 [org.hibernate.util.JDBCExceptionReporter] (JDBCExceptionReporter.java:logExceptions:78)  -ERROR: duplicate key value violates unique constraint &quot;rhq_agent_name_unique&quot;
  Detail: Key (name)=(hamza007) already exists.

Unless I'm missing something, this test needs to be fixed.
Comment 13 John Mazzitelli 2012-02-17 10:14:44 EST
moving to ASSIGNED - as far as I can tell, the unit test is broken and needs to be fixed.
Comment 14 John Mazzitelli 2012-02-17 10:22:43 EST
ips confirms this on his box too - this test doesn't clean up after itself and fails on the 2nd attempt and thereafter.
Comment 15 Ian Springer 2012-02-22 09:59:01 EST
I fixed the unit test.
Comment 17 Marc Shirley 2012-05-22 12:24:48 EDT
Changing to Verified. 

Steps to test:

1) Start an SNMP listener (for example, run comand 'snmptrapd -Lf /tmp/snmpd.log)
2) Create alert on a resource
3) Add condition (for example, resource goes down)
3) Add SNMP notification to alert and point to the SNMP listener
4) Save alert
5) Trigger the alert (for example, cause the resource to go down)
6) Verify alert shows in history for the resource in the JON UI
7) Verify the SNMP listener received the notification (for example, check /tmp/snmpd.log)