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?
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.
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.
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
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.