Batching events

Edit online

Multiple events can be grouped or "batched" together and passed to a response. The events are grouped according to the time span in which they occur. You can specify a maximum number of events that are to be grouped within the time span.

Grouping a set of events so that a response script can process them together is referred to as batching. This batching is done for the events of a condition that occur within a time interval. You can define a condition that batches events, providing a time interval (in seconds) for the batching and an optional maximum number of events that can be in a batch. The batching interval determines when the batch of events is created. When an event for a batching condition is received, a timer is set to the defined batching interval. When that timer expires, the events that have accumulated during the interval are batched together. If a timed interval has no records, batching stops, but will start again for the next event for the condition. If the maximum number of events for a batch is defined, that number of events will be in a batch, at the most. A batch of events is created when the maximum number is reached. The timed interval is reset when the maximum number is reached.

When a monitored condition is batching events, the intermediate events are saved to a file. The batched event file is sent to the responses for processing when the interval timer expires or when the maximum number of events for a batch is reached.

For a monitored condition, you can:
  • save files of batched events:
    • up to a maximum total file size. To do this, specify this persistent resource attribute in megabytes: BatchedEventMaxTotalSize.
    • until a specified retention period has passed. To do this, specify this persistent resource attribute: BatchedEventRetentionPeriod. This attribute indicates how long in hours a batched event file should be kept after all associated response scripts are run.
  • control how ERRM writes audit log records. You can use the AuditLogControl persistent resource attribute to specify that ERRM writes all audit log records (0), only error records (1), or no audit log records (2).

You can get information about a newly-saved file of batched events by monitoring the LastBatchedEventFile dynamic resource attribute. By monitoring this dynamic resource attribute, you can activate a condition without associating it with an event-response.

You can define batching-capable event-responses without actions. You can use this type of event-response to activate a condition on the command line that saves batched event files.

Responses that handle batched events must be defined as supporting batched events. A response can handle either a single event or a file of batched events. The EventBatching attribute of the IBM®.EventResponse class is used to indicate the type of event the response can handle. The response action gets control the way it does for a single event, but the ERRM environment variables are set from the last event in the batch. The ERRM_EVENT_DETAIL_FILE environment variable contains the location of the batched events file.

If there are multiple responses for a monitored, batching condition, all responses get the same batched event file. That is, the batching is by condition, not by the condition-response association. If a batched condition is monitored using one response, and this condition becomes associated with another response, the event file and interval timer are shared with the current batch. A second batch interval timer is not created. When a condition-response association becomes inactive, the batched event file is copied and sent to the response. The event batching continues as long as at least one condition-response association is active for a condition.

The batched event files are saved in the /tmp/errmbatch/ directory. When ERRM starts, it deletes all files in this directory. The individual batched event files are named: 

/tmp/errmbatch/condition_name.first_event_date.first_event_time

The batched event file consists of a header stanza followed by event stanzas, one for each event in the batch. The header stanza lists the time of the first and last event and how many events are in the file. Each event stanza lists all of the ERRM envoronment variables and their values for the event, one per line. The event stanzas are separated by a blank line and contain a header line for each event. In the event stanza, ERRM_TYPEID and ERRM_TYPE are the first two environment variables listed. Otherwise, there is no particular order of the environment variables within a stanza.

Here is an example of a header and event stanza for a batched event file: 

FIRST_EVENT_TIME=1224875454,529041
LAST_EVENT_TIME=1224875514,283748
NUM_EVENTS=34

Event 1:
ERRM_TYPEID=0
ERRM_TYPE=Event
ERRM_ATTR_NAME='Percent Total Space Used'
ERRM_ATTR_PNAME=PercentTotUsed
ERRM_COND_HANDLE='0x6004 0xffff 0x180031ae 0xe300b8db 0x10f4de7b 0x40a5c5c9'
ERRM_COND_NAME='/tmp space used'
ERRM_COND_SEVERITY=Informational
ERRM_COND_SEVERITYID=0
ERRM_DATA_TYPE=CT_INT32
ERRM_EXPR='PercentTotUsed>90' 
ERRM_NODE_NAME=c175n06.ppd.pok.ibm.com
ERRM_NODE_NAMELIST={c175n06.ppd.pok.ibm.com}
ERRM_RSRC_CLASS_NAME='File System'
ERRM_RSRC_CLASS_PNAME=IBM.FileSystem
ERRM_RSRC_HANDLE='0x6009 0xffff 0x180031ae 0xe300b8db 0x10bee2df 0x33b20837'
ERRM_RSRC_NAME=/tmp
ERRM_RSRC_TYPE=0
ERRM_TIME=1224875454,529041
ERRM_VALUE=92
ERRM_COND_BATCH=1
ERRM_MAX_BATCH=100
.
.
.
Event 2:
ERRM_TYPEID=0
ERRM_TYPE=Event

When all of the responses have completed, ERRM deletes the batched event file. If the event data needs to be kept longer, the response script saves a copy of the batched event file.