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 and filter events that appear in the event console to customize your view.

You can sort events by any column that appears in the event console. To sort events, click a column header. Clicking the header toggles between ascending and descending sort order.

Filter options appear below each column header.

#

Figure 7.4. Event Console Filter Options

You can filter the events that appear in the list in several ways, depending on the field type. Date fields (such as First Seen and Last Seen) allow you to enter a value or use a date selection tool to limit the list. For other fields, such as Device, Component, and Event Class, enter a match value to limit the list.

The Count field allows you to filter the list when compared to a value:

To clear filters, select Configure > Clear filters.

You can save your custom event console view by bookmarking it for quick access later. To do this:

You can refresh the list of events manually or specify that they refresh automatically. To manually refresh the view, click Refresh. You can manually refresh at any time, even if you have an automatic refresh increment specified.

To set up automatic refresh, select one of the time increments from the Refresh list.

#

Figure 7.6. Automatic Refresh Selections

You can view details for any event in the system. To view details, double-click an event row.

Tip: Be sure not to click other links in the row. These go to other pages.

The Event Details area appears.

#

Figure 7.7. Event Details

To see more information about the event, click Show more details. To display the event information in a new window, click the icon located at the top right.

You can use the Log area to add specific information about the event. Enter details, and then click Add.

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

You may want to mark an event as "acknowledged" to indicate, for example, that you have taken action to remedy a problem. To mark events as acknowledged:

You may want to return a previously acknowledged event to "new" status (revoke its "acknowledged" status). To do this:

Classifying events lets you associate one or more events with a specific event class. To classify events:

You can export data from the event console to a comma-separated value (.csv) or XML file. To do this, select Export > CSV or Export > XML. By default, the exported file is named events.Extension.

When you no longer want to actively monitor event (such as after you acknowledge it, for example), you can move it to history. To do this:

To view events in history, click the Event History link (located at the bottom left of the Event Console page).

You can return events that have been moved to history to active status. When you do this, the events reappear in the event console.

To return events in history to active status:

To create events from the event console, click .

For more information about manual event creation, see the section titled "Creating Events Manually."

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 click Classify. 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: