Bug 911432

Summary:	Alerts for events do not include 'source location'
Product:	[Other] RHQ Project	Reporter:	Elias Ross <genman>
Component:	Alerts	Assignee:	Jirka Kremser <jkremser>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Mike Foley <mfoley>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	hrupp, jkremser, yak
Target Milestone:	---
Target Release:	RHQ 4.10
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-04-23 12:30:32 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Elias Ross 2013-02-15 00:52:04 UTC

For example, for an SNMP alert, I receive the following email:

Subject: [ALERT] priority of [Medium] for alert [Log Alert] on resource [SNMP recv 11162]

The resource SNMP recv 11162 has generated the following alert:

------------------------------------------

Resource Name    : SNMP recv 11162
Alert Name       : Log Alert
Alert Severity   : Medium
Alert Date/Time  : Fri Feb 15 00:34:08 UTC 2013
Conditions: 
 - Condition 1: Event With Severity [INFO]
 - Date/Time: 2013/02/15 00:33:37 UTC
 - Details: INFO, extraInfo=[snmpTrapOID: 1.3.6.1.4.1.63.2000.1.1
splLog: /data/logs/flume.log
splName: App Exception
splMsg: 2013-02-14 22:41:21,901 WARN sink.Processor: Sink failed to consume event. Attempting next sink if available.
or
-----------

Note the 'Details' contains the event that triggered the condition, with its text in extraInfo, but extra info does not include the event 'Source Location' column value, which in this case is the host name.

What I would like to see:

 - Condition 1: Event With Severity [INFO]
 - Date/Time: 2013/02/15 00:33:37 UTC
 - Details: INFO,sourceLocation=XXXXX,extraInfo=[snmpTrapOID: 1.3.6.1.4.1.63.2000.1.1
...

* The Alert tab also only includes Condition Text 'Event Detection [INFO]', which is not that helpful. Why not include some of the extra info there, like the source location?

Comment 1 Jirka Kremser 2014-03-05 17:44:17 UTC

branch:  master
link:    https://github.com/rhq-project/rhq/commit/b0199717c
time:    2014-03-05 18:42:01 +0100
commit:  b0199717c3fb85a2bfc63e9e3eefdc3eabed01ff
author:  Jirka Kremser - jkremser
message: [BZ 911432] - Alerts for events do not include 'source location' -
         adding the source location information to alert condition log.
         Column 'value' on table 'rhq_alert_condition_log' is limited by
         255 characters so if the actual message is long enough the
         source location information can be lost.

Comment 2 Michael Burman 2014-03-05 20:10:37 UTC

Hi,

While this is a lovely workaround, it's not a solution at all for Windows machines, where Source-Location is pretty important. For example, in my home machine:

Total Events in System log:

PS C:\Users\pebum_000> $allEvents = Get-EventLog System ; $allEvents.Count
13292

Out of those, over 255 chars are:

PS C:\Users\pebum_000> $events = Get-EventLog System | foreach { if($_.Message.Length -gt "255") { echo $_.Message.Length } } ; $events.Count
6934

So over 50% would be losing Source-Location. That sort of makes the SourceLocation useless since it's never there.

Comment 3 Jirka Kremser 2014-03-18 15:26:34 UTC

I hear you, I had a fix [1] prepared adding also a possibility to filter on the source location reg exp., but it was pretty invasive at the end of the day and not doable without adding additional field into AlertCondition entity.

Honestly, I don't like the way the AlertCondition entity is misused for storing multiple types of data (based on the condition type). The standard class hierarchy with some AbstractCondition and then subtypes, would be much better here, because it would require to add the field only to the EventAlertCondition (this class doesn't exist). I don't know the history of this decision (to keep everything in one class and misuse the fields). I would be happy to refactor it, but it would break/fix our REST API.

The good news is that there is a product bug 1070257 that requires the increase of the db column as well, so it should be improved soon.

[1]: https://github.com/Jiri-Kremser/rhq/commit/fd6691720775d9394380d4f784bac6b39a78606d

Comment 4 Heiko W. Rupp 2014-04-23 12:30:32 UTC

Bulk closing of 4.10 issues.

If an issue is not solved for you, please open a new BZ (or clone the existing one) with a version designator of 4.10.