Throughout the course of this book, we've interacted with event attributes in many different contexts. As you might guess, these attributes define the details of an event in Zenoss Core. However, not all attributes are applicable to each event. The most obvious place to witness the event attributes and how they are applied is in the event log, which we covered in Chapter 6, Core Event Management. Also in Chapter 6, Core Event Management we reviewed event views, which determine how events show up in the event console—all predicated on the event attributes listed in this appendix.
We can also use the event attributes to process events in relation to:
Event transformations
Event mappings
Event commands
ZenPack programming
Your programming context determines how you access the event attributes. We can substitute the event attributes in our Python statements via TALES expressions, as we saw with the discussion of event commands in Chapter 6, Core Event Management.
An example of a TALES expression to access an event attribute looks like this:
${evt/attribute}
The attribute can be any of the event fields defined in the following table. So if we wanted to write a TALES expression to access the message body of an event, the expression would look like this: ${evt/message}
. Python evaluates the expression and substitutes the value into the current Python statement.
In other programming contexts where you might not use TALES, you would use the following syntax to access the event attribute:
evt.attribute
The following table lists the available event attributes in Zenoss Core.
Event Attribute |
Description |
---|---|
|
Identifies the event so that Zenoss can deduplicate events. Takes the form of device, component, eventClass, eventKey, and severity. |
|
A unique identifier for the event. |
|
Specifies the device attached to the event. |
|
The Zenoss daemon reporting the event. |
|
The event class that the event maps to. |
|
A user-defined way to map events. Event keys can be sequenced to aid the event class mapping of events from a common source to different event classes. |
|
Summary of the event. |
|
Message body for the event. May be the same as summary. |
|
A Numeric representation of the event:
|
|
Numeric representation of the event state:
|
|
Maps the event to an event class. |
|
Event source group: For example, syslog, process, and ping. |
|
Time stamp when the event state changed. |
|
Time stamp when the event first occurred. |
|
Time stamp when the event last occurred. |
|
The total number of times the event has occurred based on the |
|
The production state of the device. The Zenoss defaults are:
|
|
If the event is suppressed, this is the ID of the suppressing event. |
|
The fully qualified domain name of the event collector that generated the event. |
|
Reports the Zenoss daemon responsible for generating the event. |
|
The device class. |
|
The location organizer assigned to the device. |
|
The system organizer assigned to the device. |
|
The group organizer assigned to the device. |
|
The IP address of the device. |
|
The syslog subsystem that generated the event (for example, cron, mail, lpr, auth, authpriv, daemon, ftp, kern, mark, news, syslog, user, uucp, local0 through local7). |
|
The priority of the syslog event. |
|
The Event ID field of the Windows NT event log. |
|
The ID number of the event owner. |
|
The ID number of the event that cleared this event. |
|
The priority as assigned in the device's Edit page:
|
|
The event class mapping used to evaluate and map the event. |