You can use event collectors to organize events in meaningful groups for display in an event list and to show event relationships. An event collector consists of a filter that queries the event repository and displays the results in an event list in the console.

Each cell has default collectors for the console and collectors that you create. In the collector definition, you must specify the user groups that can access a collector.

For an event to be displayed in an event collector, you must specify criteria that an event must match and specify which user groups can view a collector and the events within a collector. You must define collectors by using MRL and store them in the KB.

Event collectors are dynamic or static. Nodes for dynamic event collectors are displayed in or removed from the navigation tree based on whether or not events are present that meet the criteria specified by the collectors. Nodes for static event collectors remain in the navigation tree whether events for that collector are present or not. The color of the node reflects the highest level of severity in the event list.

Events can appear in multiple collector trees in the console but not in multiple collectors within a single collector tree.

Because collectors are defined in the cell's Knowledge Base, they appear in any console that displays that cell. The cell provides default event collectors—PATROL, All Events, By Location, By Status—for the console.

How collectors are structured

Collectors are created by using MRL, defined in the collectors subdirectory of the Knowledge Base, and organized in a hierarchical structure. This type of structure means that specialized collectors appear at the lowest level of the hierarchy and are subsets of the generic collectors in the higher levels of the hierarchy. As such, collectors can be characterized by their position in the hierarchy as either a parent collector or a child collector.

Each collector tree represents a collector type, and each branch is a path that an event follows to locate matching criteria. When an event passes through a collector definition and matches the criteria set for that collector, the event is displayed within that collector group in the console.

After an event finds matching criteria, it ignores any remaining paths in the collector tree. An event continues to the end of the current path and searches for an accepting collector, with one of the following results:

• The event is stored in the first accepting collector it encounters. This is called the event's endpoint collector. For each collector tree, the event can be stored in only one endpoint collector.

• If there is no collector on the current level that accepts the event, it proceeds to the next higher level and is stored in the first accepting collector that it encounters there. This is the event's endpoint collector.

MetaCollectors

A MetaCollector is a grouping of collectors. You can create MetaCollectors to view events from several event lists. Each event list is shown as a tab in the event list pane.

The MetaCollector node represents the state of the combined events. MetaCollectors are often used to view collectors from multiple cells in the network.

Actions

Actions are a series of commands that you run on an event or data instance that are used to diagnose and remedy problems. Actions are implemented as a piece of MRL code similar to a rule or implemented in an external program. Actions can be defined in the Knowledge Base of a cell. These actions usually are launched by a user in the console but can also be triggered by rules. In both cases, the action runs in the cell's environment.

The action definition can prompt the user performing the action for arguments. Arguments can be passed to an action by rules or through user input in the console interface. An executable associated with an action can be a script or binary. The executable is run on the operating system platform on which the cell is running. Actions can be made available to a specific user, group and with specific values assigned to event slots.

Actions defined in a cell are remote actions. Remote actions are executed remotely by the cell from the console. A remote action that is implemented as an external program is called an external action. A remote action implemented as a piece of MRL code is called an internal action.

For more information about defining remote actions, see Creating remote actions on the administrator console.