The device field is a free-form text field that allows up to 128 characters. Zenoss accepts any value for this field, including devices that are not in the database. If the device field contains an IP address, then Zenoss queries the database for devices with a matching address. If it finds a match, it changes the device field to the found device name.

The ipAddress field is a free-form text field that allows up to 15 characters. This field is not required. If Zenoss cannot successfully locate a device based on the event's device field content, it attempts to find the device based the event ipAddress field content, if present.

Zenoss automatically adds information to incoming events that match a device in its database. Fields added are:

For more information about these fields, refer to the chapters titled "Production States and Maintenance Windows" and "Organizers and Path Navigation."

The eventState field defines the current state of the event. This field is often updated after an event has been created. Values for this numeric field are 0-2, defined as follows:

The severity field defines the severity of the event. Values for this numeric field are 0-5, defined as follows:

The summary and message fields are free-form text fields. The summary field allows up to 128 characters. The message field allows up to 65535 characters. These fields usually contain similar data.

Zenoss handles these fields differently, depending on whether one or both are present on an incoming event:

As a result, data loss is possible only if the message or summary content exceeds 65535 characters, or if both fields are present and the summary content exceeds 128 characters.

To ensure that enough detail can be contained within the 128-character summary field limit, avoid reproducing information in the summary that exists on other fields (such as device, component, or severity).

The evid field is the event identifier, or event ID. It is a 36-character, unique identifier for every event that comes into the system. An incoming event should never have an evid assigned to it, because Zenoss creates it immediately before the event is inserted into the database. If an incoming event does have an assigned evid, then Zenoss ignores it and replaces it with a generated evid.

You can sort events that appear in the event console by:

To sort events by a category, click a column header. Clicking the header toggles between ascending and descending sort order.

You can filter the list of events that appear in the list by:

The list of events automatically refreshes according to the value specified next to the Stop button (located at the top of the events list). Change this value (by default, 60 seconds) to refresh more or less frequently. To stop auto-refresh, click Stop. Click this button again to restart auto-refresh.

You can view details for any event in the system. To view details, click the magnifying glass in the right-most column of an event row. The Event Detail window appears, showing the Fields tab.

#

Figure 7.4. Event Details

To select one or more events in the list, you can:

#

Figure 7.5. Selecting Events

You can manage events from the event console. After selecting one or more events, you can:

These standard daemons are responsible for generating events in Zenoss. They automatically perform appropriate de-duplication and auto-clearing.

Captured events are those events that Zenoss does not specifically know will occur in advance. De-duplication is performed on these events, but in some cases may need to be tuned. By default, no auto-clearing is done on captured events. Event transforms must be used to create the auto-clear correlations.

These standard daemons are responsible for collecting captured events:

There are a number of APIs available for submitting events into Zenoss. For more information, see the Zenoss Developer's Guide.

Any ZenPacks you install may optionally include their own daemons. For more information, see Zenoss Extended Monitoring.

To create events manually through the user interface:

To send events from the command line, use the zensendevent script, in this format:

zensendevent Options summary

Common options include:

zensendevent -d router1.example.com -s Critical -c /Status/Ping "Router down"

Just as device classes and devices have zProperties, so do event classes and event class mappings. zProperties are applied hierarchically, with the most specific zProperty being applied.

The following zProperties are available on event classes and even class mappings.

A good example of how Zenoss uses the event class zProperties is found in the /Change event class. Within the /Change event class' zProperties, zEventAction is set to drop and zEventSeverity is set to Info. This configuration causes all of the changes in your environment to be stored as info severity events in the history table.

For more information about event manipulation techniques, see the section titled "Mapping and Transformation."

There are two primary ways to view the event class mappings that exist in the system. The first is to go to Events in the navigation menu and click on the Mappings tab. This allows you to see all event class mappings in a single location. The EventClass column shows which event class the mapping is in. The other way to view the existing event class mappings is to go to the Classes tab of any event class. This shows you only event class mappings related to the current event class.

You can create event class mappings directly from the event classes, but this requires that you know the eventClassKey. A simpler way to create event class mappings is through the event console. Find an event that you want to match, select it, and then choose Map Events to Class. Choose the event class that you want the event to be mapped to, and then click OK. This will automatically create the event class mapping with the correct eventClassKey, and example text against which you potentially can developer your regular expression.

From the Edit tab of an event class mapping, you can control which events it will match, as well as other properties:

The sequence tab of an event class mapping allows you to handle situations where you need to provide more than one possible mapping for the same eventClassKey. In this case, the sequence is evaluated in ascending order until a full (rule or regex) match is found.

Mappings have the same zProperties as event classes. Any zProperty set locally on a mapping will override the same property set on the event class. This works in the same hierarchical, most specific match, concept that device class and device zProperties work.

When a captured event (see the section titled "Event Sources") occurs, it will not have an event class pre-defined. For this type of event, you must create an event class mapping if you want to affect the event. If a captured event occurs and none of the event class mappings in the system match it, its event class will be set to /Unknown, and it will retain all of the default properties that it began with.

The next step of evaluation for events without an event class is to check on the eventClassKey field. This is the first and most important field that controls which event class mapping the event will match. If the event has a blank eventClassKey, or its eventClassKey does not match any event class mappings in the system, the special “defaultmapping” eventClassKey is searched for instead. This provides for a way to map events even if they have a blank or unpredictable eventClassKey.

When a generated event occurs, it has an event class assigned to it. This causes the event class mapping step to be skipped. The only way to affect the fields of one of these events is through the event class’ zProperties and transform.

To access the transform for an event class:

The objects available in this Python context are evt (the event); and, if the event matches a device that exists in the Zenoss database, a device object.

#Example

The following example shows how you can validate that a device object exists before using it to drop events from a particular location.

if device and "Hawaii" in device.getLocationName(): evt._action = "drop"

From the event manager, you can set up automatic aging of certain events from the status table to the history table. This allows you to have lower severity events that do not reoccur for a specified length of time to be automatically archived to the history table.

Event manager properties that control this behavior are:

With the default settings, Debug, Info, and Warning events that do not occur for four hours are automatically moved into the history table.

You can set up automatic purging of events from the history table from the event manager. When events are purged from the history table, they can be recovered only from Zenoss backups. For this reason, the default setting is 0, which specifies that events are never automatically purged from history.

The event manager property that controls this behavior is Delete Historical Events Older Than (days).

To create or edit event commands, go to the Commands tab of the event manager. From here, you can adjust these properties:

ZenMail serves as an SMTP server that you can bind to a specific TCP port. You can then configure your embedded system to send mail to the Zenoss server explicitly by using the Zenoss server's IP address as the relay.

ZenMail supports these configuration directives:

ZenPop allows you to retrieve event email from a POP server. ZenPop supports these configuration directives:

Zenoss translates various message elements to the event, as follows: