1. Proposed title of this feature request Event Viewer Must Convey More Meta-Data when there are faults. 2. Who is the customer behind the request? Red Hat 3. What is the nature and description of the request? Currently, the amount of information that is conveyed in a fault detected by the event viewer is very terse. We need more information such that we can provide diagnostic services. It would be particularly helpful if the event conveyed an actual exception (e.g. java.lang.Exception). 4. Why does the customer need this? (List the business requirements here) Diagnostic services. 5. How would the customer like to achieve this? (List the functional requirements here) More data please a flow ID is not enough. We either need message IDs or a stacktrace. 6. List any affected packages or components. The Red Hat Support Plug-in for RHEV is adversely affected by the fact that the event viewer is not plug-able. 7. Would the customer be able to assist in testing this functionality if implemented? Yes.
The "Events" main tab renders org.ovirt.engine.core.common.businessentities.AuditLog business entity data, which can be passed to UI plugins. AuditLog contains correlationId that could be used to correlate given event with backend logs. AuditLog does not contain any sort of exception /stacktrace/ information. If we need possible stacktrace information associated with given event, we must do "correlationId --> stacktrace" lookup in one way or another. The question is, who should be responsible for this, i.e. plugin vs. WebAdmin/GUI infrastructure.
We don't mind being responsible for this work. Although, if we are responsible, can you tell us where/how we would be able to use the correlation id to look up the stack-trace info? Is it in the database?
Hi Spenser, here are some details and examples based on my observation of backend code and runtime behavior: AuditLog's correlationId attribute is set only when executing business commands (CommandBase extends AuditLogableBase) - in other words, AuditLog.correlationId != null only when the given AuditLog describes a logical business operation (command) triggered by Frontend and executed by Backend. I noticed that not all AuditLog entries describing command execution have correlationId != null, not sure why, though. For example, in engine.log: Following line represents AuditLog describing admin user logging into WebAdmin (no correlationId present): ... [org.ovirt.engine.core.bll.LoginAdminUserCommand] (http--0.0.0.0-8700-1) Running command: LoginAdminUserCommand internal: false. Following line represents AuditLog describing creation of new Data Center from WebAdmin (correlationId is present -> 6a586baf): ... [org.ovirt.engine.core.bll.storage.AddEmptyStoragePoolCommand] (http--0.0.0.0-8700-1) [6a586baf] Running command: AddEmptyStoragePoolCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: System Following line represents AuditLog describing deletion of existing Data Center from WebAdmin (correlationId is present -> 59d5a973): ... [org.ovirt.engine.core.bll.storage.RemoveStoragePoolCommand] (pool-8-thread-49) [59d5a973] Running command: RemoveStoragePoolCommand internal: false. Entities affected : ID: 9c6ca25e-68cc-42cb-8ed2-91e14d91021a Type: StoragePool So if correlationId is available (not null), you can parse $JBOSS_HOME/standalone/log/engine/engine.log - looking for "[<correlationId>]" and extracting logs that immediately follow the matching line, including any exception/stacktrace information. (AFAIK this is the only way to lookup possible exception/stacktrace information based on AuditLog correlationId.)
I'm going to close this BZ. I think that this shd be fixed by a combination of BZ966198 and BZ966192. If necessary will revisit after those are completed. *** This bug has been marked as a duplicate of bug 966198 ***