Introduction

TEC Event Groups are an invaluable tool for the TEC Console user, restricting the Events displayed to those of interest to the specific operator. Event Groups are generally defined by a senior Tivoli Administrator, the TEC 3.9 Java Console facilitating this definition process.

To understand how to create an event group to filter on an extended attribute, it is first necessary to understand how the TEC Database is structure with respect to the "event repository".

The Event Repository

The event repository is the section of the TEC database used for storage of events that persist after processing by the rules engine, it consists of two key tables, named tec_t_event_rep and tec_t_slots_ev.

The table tec_t_event_rep is populated with the event attributes that are common to all events, based on attributes defined within the "root" event class, for example, the hostname and severity attributes. Each event is represented by a single row within the table.

The table tec_t_slots_ev stores the extended attributes for events, i.e. attributes that are not within the root event class, are are potentially unique to a specific event class. This table includes a row for each extended attribute within an event, for example, if an event class has two extended attributes named disk_label and disk_free_space, then these attributes will be stored in two distinct rows within the table tec_t_slots_ev.

So how are the details within each table correlated? Each event is uniquely identified by three attributes server handle, event handle and reception date. Columns for these attributes are present in both tables, facilitating an SQL "join" of the two tables to correlate the information.

A further abstraction within the database is used for attributes of an enumerated data type. This data type indicates that the attribute value is represented by an integer. This method of attribute definition increases the rule-base performance where conditional statements are dependent on the enumerated attributes. For example, the severity attribute is enumerated. Enumerated data types are defined within the BAROC files, and also in the database table tec_t_enumeration. This tables enables the translation of the enumerated attribute during database queries.

The diagram below demonstrates the relationship between the different tables:

Event Group Queries

By default the Event Group filter will query the TEC database view titled tec_v_console_list. This database view displays a limited number of fields from the tec_t_event_rep table, i.e. the table containing the base event attributes. Hence, a standard Event Group query can only filter on these base attributes. To filter on an event class attribute not defined within the view tec_v_console_list, it is necessary to include an additional select statement within the filter to query the extended attribute table, tec_t_slots_ev.

The basic form of the additional query is:

(select <column_name> from <table_name> where <column_name>=<value>)

As previously stated, the table tec_t_slots_ev stores each extended attribute for an event within a dedicated row. The attribute name is identified within the database field slot_name and the attribute value is identified within the field short_slot_value or long_slot_value. Hence, for example, to filter on the events that include the ITM attribute profilename with a value of "ITM.unix", requires the where clause within the additional query to include:

slot_name = 'profilename' AND short_slot_value like 'ITM.unix'

The extended attributes returned by the additional query must be correlated to their parent event returned from the query of the view tec_v_console_list. This is achieved by using an SQL join on the fields that uniquely identify the event, the fields server handle, event handle and reception date. These fields are represented in both the view and table with the field names server_hndl, event_hndl and date_reception, respectively. To correlate these results from each query requires two steps:
1. The three fields in each table must be concatenated
2. The concatenated fields must be compared

The SQL syntax required for the Event Group for this extended query is as follows:

server_hndl+event_hndl+date_reception in ( select server_hndl+event_hndl+date_reception from tec_t_slots_evt where slot_name = 'attribute_name' AND short_slot_value like 'attribute_value' )

The text highlighted in red indicates the where clause for the query of the view tec_v_console_list, the text in blue represents the query of the table tec_t_slots_ev.

For example, to filter on the value of the ITM Event attribute profilename where the attribute starts with "ITM.unix" use the following SQL statement within the event group filter SQL query:

server_hndl+event_hndl+date_reception in ( select server_hndl+event_hndl+date_reception from tec_t_slots_evt where slot_name = 'profilename' AND short_slot_value like 'ITM.unix%' )

Note that slight adjustment to the syntax will be required for Oracle Database systems where the concatenation operator "||" (a double vertical bar) must be substituted for the "+".

The TEC command "wconsole" can be used form the Tivoli CLI to update a TEC operator with such an event group. The required stpes are:

1. Create the new Event Group, using the syntax
wconsole -crteg -n <event_group_name> -D <description>

For example:
wconsole -crteg -n UNIX.eg -D "Event Group to Display UNIX ITM Events"

2. Add the filter to the event group
wconsole -addegflt -E <EventGroupName> -n <FilterName> -D <Description> -S <SQLQuery>

For example:
wconsole -addegflt -E UNIX.eg -n unix.filter -D "Filter on the ITM profilename attribute" -S "server_hndl+event_hndl+date_reception in ( select server_hndl+event_hndl+date_reception from tec_t_slots_evt where slot_name = 'profilename' AND short_slot_value like 'ITM.unix%' )"

3. Assign the event group to an operator, sing the syntax:
wconsole -assigneg -C <ConsoleName> -E <EventGroupName> -r <rule1:role2:...>

For example, assuming the Console named "UnixConsole" already exists:
wconsole -assigneg -C UnixConsole -E UNIX.eg -r admin:senior

Summary

Creating event Groups to filter the events displayed to the TEC Console operator is an important role for the Tivoli administrator. Events should be limited to those that require user response to prevent unneeded information distracting from the key alerts. The above query provides a simple, but powerful tool for filtering the events displayed to TEC Console users, increasing the usability of the console.