Softpanorama
(slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Debugging and Testing TEC Rules

News	See Also	Recommended Links	Prolog	TEC Rules Programming	Typical operations with the rulebase
wpostemsg, postemsg	wpostzmsg,	postzmsg	tec_agent_demo	Tracing rules	Etc

The most common problems related to rules are:

Failure to recompile, reload, and activate the rule base.
Failure to restart all Tivoli Enterprise Console processes after making changes to the rule base.
Editing rules in Windows with the editor that introduces Windows end-of-line (^M) character in a rule set. Due to weakness of the IBM design this causes unpredictable results, such as the TEC failing to start or the event console not being updated.

If rules are not working properly or as you expect the first step is to compile the rules with tracing on and look at the trace output on a subset of events that created specifically for debugging.

The first task is to create set of test events and send them to TEC. There are at least three methods of doing this:

wpostemsg, postemsg, wpostzmsg, postzmsg commands
- wpostemsg simulates an event from a TME adapter and uses Tivoli Management Framework services for communication with the event server.
- postemsg simulates an event from a non-TME adapter and does not use Tivoli Management Framework services for its communication with the event server.
- wpostzmsg -- a better more modern version of wpostemsg.
- postzmsg -- a better more modern version of postemsg.
These commands send events whose characteristics are specified as arguments. See the Tivoli Enterprise Console Reference Manual for the description of each command.
The tec_agent_demo program. Allows you to send event in a way similar to how Unix start services. The program and the files should be run on the event server host. This is definitely not the best design so expect some learning curve. Each event file should contains a single event. The events sequencing is specified in a control file, which the program uses to prompt you before sending each event. You probably should write a Perl script to generate control file automatically from the content of the folder if you want to preserve sanity. Different test scenarios are achieved by grouping events in several different control files and then specifying the control file as an argument to the program.
The SendEvents program
The SendEvents program sends events that have been retrieved from the reception log and written to a specific directory structure. The events are sent using a time interval. The interval can be used to do the following:
- Send an event every x number of seconds
- Send the events at the same interval as they were received originally

To see how the message arrived and in what format, type in wtdumprl on the TEC server. For example:

wtdumprl -o DESC | more

wtdumprl -t 'May 16 10:00:00 2006' -e 'May 10 10:30:00 2006' > tec.out

You can also create event files

From a bash or UNIX shell command line, enter the following command. The directory argument specifies the directory to write the event folders (which contain event files), events_list file, and time_list file.

wtdumprl | $BINDIR/TME/TEC/contrib/ParseEvents.pl -d directory

The event files are generated in a directory structure like the following figure. For this example, the preceding command was issued with the -d /test3 argument.

In more complex case you need tracing. Tracing is activated by option -trace in wrb -comprules command.

Here is a relevant quote from SG246614 Rule tracing and profiling :

In Tivoli Enterprise Console 3.7, the new wrb command is introduced to handle all tasks regarding rule bases. The Tivoli Enterprise Console commands of previous versions are still present for backward compatibility, but it is necessary to use only the new command set for working with rule bases in Tivoli Enterprise Console 3.7. All new architecture considerations are only supported by the new wrb command set. The CLI command to compile a rule base has the following syntax:
wrb -comprules [-profile] [-trace] <rule base name>
Where: The -trace option provides the rule trace functionality that is already known from earlier Tivoli Enterprise Console versions. Rule tracing can be activated either by using the CLI commands or the GUI. Enabling rule tracing via CLI and Enabling rule tracing via GUI describe both the CLI and GUI way to initiate rule tracing. The -profile option applies the new functionality of rule profiling to a rule base when compiling it.

See Rule profiling for more details.

Creating event files from events in the reception log

Creating event files from events in the reception log

A program is available to parse the events in the reception log for use with the tec_agent_demo or the SendEvents programs. This procedure can be a quick way for you to create events for testing rules.

To create events for testing from those in the reception log:

Ensure your Tivoli environment is initialized (for example, the setup_env.sh command has been issued).
From a bash or UNIX shell command line, enter the following command. The directory argument specifies the directory to write the event folders (which contain event files), events_list file, and time_list file.
```
wtdumprl | $BINDIR/TME/TEC/contrib/ParseEvents.pl -d directory
```
The event files are generated in a directory structure like the following figure. For this example, the preceding command was issued with the -d /test3 argument.

Each event file is within an event folder. For example, the event0001 file is within the event0001 folder. The numbering sequence is internally generated by the ParseEvents.pl program and begins with the oldest event; that is, the event in the event0001 file was received before the event in the event0002 file.

Once you have captured the events in event files, you can rename them, modify them, and move them for use with the tec_agent_demo program. Or, you can use the directory structure as it is with the SendEvents program.

Here is a tip from GulfBreeze Software :

One of the more common tasks is dumping received events from TEC to a flat file for archiving. Here is an example:

To do straight reception log dumps, consider using a script like this one that I run all the time. This script will dump all events from the reception log to a file named with the date and then perform a clear of the TEC database.

#!/bin/sh
. /etc/Tivoli/setup_env.sh
LOGFILE=/usr/local/Tivoli/custom/logs
dat=`date +"%m%d%Y" `
date=`date`
tec_date=`date +"%h %d 00:00:00 %Y"`
echo WTDUMPRL Started at $date >> $LOGFILE/tec_maint.log
`wtdumprl -t "$tec_date" >$LOGFILE/$dat.events`
echo WTDUMPRL Finished at $date >> $LOGFILE/tec_maint.log
echo STARTED TEC Event Report at $date >>$LOGFILE/tec_maint.log
echo GZIP Started at $date >> $LOGFILE/tec_maint.log
`gzip -f $LOGFILE/$dat.events`
echo GZIP Finished at $date >> $LOGFILE/tec_maint.log
echo WTDBCLEAR Started at $date >> $LOGFILE/tec_maint.log
`wtdbclear -elt 259600`
echo WTDBCLEAR Finished at $date >> $LOGFILE/tec_maint.log

Notes:

Those pages are written by people for whom English is not a native language. Some amount of grammar and spelling errors should be expected.
This is a Spartan WHYFF (We Help You For Free) site. It cannot replace the best teachers and the best books.
The site contain some obsolete pages as it develops like a living tree... Some links on older pages are broken. Please try to use Google, Open directory, etc. to find a replacement link (see HOWTO search the WEB for details). We would appreciate if you can mail us a correct link.

Search Amazon by keywords:
Open directory	Research Index

Old News ;-)

Orb-data Tips

Event Cache Demystified
Aims to demystify the event cache by explaining what it is, what it's used for and how it can or should be configured.
Troubleshooting BAROC Problems
Using a recent problem this tip illustrates an example of how you can troubleshoot BAROC Class problems, and describes what is happening during the loading of a rule base and the starting of the Event Server.

Tivoli Field Guide - The "If Then Else" of Event Flow in IBM Tivoli Enterprise Console, version 3.9

The purpose of this white paper is to educate the concerned audience about all the different stages and paths that an event can undergo on its way to the IBM Tivoli Enterprise Console Event Server (referred to as “Event Server” from here on out). Also, this document will be of great help to someone who is trying to diagnose a problem of events not being received. The flowcharts included that show the event flow will definitely help pinpoint specific areas to analyze further.

IBM Software Support Tivoli Tivoli Technical Field Guides

Tivoli Field Guide - Getting the Most out of Traces

If you have ever called Tivoli Support to get help figuring out what is wrong in your Tivoli environment, then you know how hard it is to get help regarding traces. This field guide will teach you to ensure that the trace files you send to Tivoli Support are useable. You will also learn how to produce and read your own trace files, so you may be able to resolve your own problem rather than calling Support.

IBM Redbooks Troubleshooting a Problem on Tivoli Enterprise Console to a IBM Tivoli Business Systems Manager Connection

If something goes wrong and the object is not shown at the IBM Tivoli Business Systems Manager console, we have to analyze the source of the failure:

First, check whether the conditions have been met to cause an alert at the endpoints where the monitors have been distributed. For DM classic, we use wlseng -l <enpoint_name>, and for IBM Tivoli Monitoring or DM Advanced Edition, we use wdmlseng -e <endpoint_name> -verbose.

If these monitors fire correctly and the network communications within the Tivoli Management Region are working, the next step for this event is to check the TEC. When TEC receives a recognized event, it is parsed by the rules engine. The rule that will parse and act upon classic DM events and send them to IBM Tivoli Business Systems Manager is ihstdmon.rls.

The wtdumprl command is used to display all received events and their disposition, whether they are processed or get a parsing failed status. When parsing fails, it means that either the class is not defined or there is an unknown slot (field) or an unparsable slot.

The wtdumptr command is used to display the completion of the action invoked from the TEC rules for an event. For example, the completion code of invoking the event enablement exits.

If the received event matches the profile of an event that has been slated to be sent to IBM Tivoli Business Systems Manager, a TEC exit ihstztec is invoked. This exit also is invoked when there is a change of status of this event to ACK or CLOSE. Again, we confirm this from the rule trace, if you have enabled the rule tracing from the EventServer setting.

If you examine the trace of the rules, you will see the event that matches the condition that you want and then the ihstztec exit is invoked. This formats the data and passes it onto the ITBSM Event Enablement service. This in turn sends this event to the Agent Listener. We have seen the usage of wtdumprl, wtdumptr, and the tracing of the rule base that has been used to show the data flow from within TEC. The most common problem you will see from the wtdumprl is that of an unprocessed event. If this is the case, check the classes (BAROC files) whose addition may have been missed. The most useful trace is that of the rule base, as you may have made a syntax error with the customization of a rule.

The Event Enablement engine itself also keeps log files. Four log files, two for the task server and two for event enablement, are available in the $BINDIR/TDS/EventService/log directory. You need to start tracing for event enablement to get meaningful information in the log file. Run the trace using the tserver ee_utility -t command. To format these log files, we use the ihszfmt command, which is located in the $BINDIR/TDS/EventService/bin subdirectory.

The next part of the data flow we examine is that of the Agent Listener. Verify that the Agent Listener is connected to the event enablement with the gemeeconfig command.

The next point to check is the Agent Listener log file. The amount of information logged in the log file depends on the loglevel, which can be set in the Windows registry. When the loglevel is set to 0, everything will be traced. The default loglevel setting is 2. The file is named AL + Timestamp of creation, so the file AL200211141427.log is the Agent Listener log that is created on 14 November 2002, at 14:27.

ORB Data Links

TEC Rule Tracing (Part 1)
This is the first part of a three part tip which takes a closer look at Rule Tracing. This tip describes how you can generate your own trace messages to help debug your rules
TEC Rule Tracing (Part 2)
This is the second part of a three part tip which takes a closer look at Rule Tracing. This tip describes how you can dynamically turn on and off tracing within your rulebase without having to perform a restart.
TEC Rule Tracing (Part 3)
This is the final part of a three part tip which takes a closer look at Rule Tracing. This tip describes how you can trace particular rules or actions within a rule base, thus allowing you to trace only the rules that you're currently developing.

RE [TEC] Refreshing the Rules cache

From: owner-tme10@lists.us.ibm.com
[mailto:owner-tme10@lists.us.ibm.com]On Behalf Of Blankenship, I.V.
(Contractor)
Sent: 11 March 2005 13:51
To: 'tme10@lists.us.ibm.com'
Subject: RE: [tme10] [TEC] Refreshing the Rules cache

The save_event_cache predicate dumps the event cache to a flat BAROC file.
This file is formatted similarly to a BAROC class definition file but does
have some differences.

CLASS_NAME ;
SLOT_NAME =
SLOT_VALUE;
.
.
.
END

.
.
.

The restore_event_cache predicate calls bo_parse_baroc_file/2 to read the
file and add the instances to the event cache. Both save and restore
predicates call get_config_param to read the your
$BINDIR/TME/TEC/.tec_config file for the event_cache_file parameter and will
only work if that parameter is defined. To dump your cache to an arbitrary
file you can use print_cache(FILENAME). To read from any BAROC file do
something like this:

bo_get_config_options(_old_quote,_old_parse_in,_old_parse_out),
bo_set_config_options(_old_quote,0,_old_parse_out),
bo_parse_baroc_file(FILENAME,add_to_cache),
bo_set_config_options(_old_quote,_old_parse_in,_old_parse_out),

If you wanted to "reload" the event cache I suppose you could write a
program or perl script to read from the event repository to build a BAROC
file, iterate through all instances of events in your cache and remove them
with bo_delete_instance/1 and then call bo_parse_baroc_file/2 to reload the
events.

The real question is not "can you" (there is almost always a way...) but
"why would you need to?" Are you experiencing problem where you events in
cache are out of sync with your repository as a result of forced cache
cleaning? If so you would be better off implementing better duplicate detect
rules, drop and or close irrelevant events, and increase your event cache
size.

SendingEvents

Sending a Tivoli event from a Unix script involves the following steps:
-          Define an event class
-          Generate events
-          Choose a method for closing events

Defining an event class
Every event must have an class name that identifies it to the Tivoli Enterprise Console (TEC). By convention, we will use unix_<program name> for the events sent by programs or scripts on the Unix systems, and nt_<program name> for Window NT/2000. The ESM staff will set up the event classes as requested. Put a request in the ESM-Incoming queue in TPM or send e-mail to tivoli@Princeton.EDU.

Generating events
Issue a wpostemsg command to send an event to the Tivoli Enterprise Console (TEC), which is the event correlation engine.

The format of the command is as follows:

wpostemsg [-m message] [-r severity] [hostname=<host>] [value=<value>] [probe_arg=<probe-argument>] [response_level=reset] class source

The wpostemsg command requires that the proper environment be set up. The easiest way to do this is with the “tiv” script in /var/local/Tivoli/Princeton/bin. To issue a single command, just give the tiv command followed by the command. The tiv command with no arguments will start a shell with the environment set up.

Arguments:

message is a arbitrary text message explaining the meaning of the event.
severity is one of FATAL, CRITICAL, MINOR, HARMLESS, or WARNING
class is the class defined for this event.
source is “unix” or “windows_nt”
<host> is the unqualified name of the host for which the event is to be reported.
<value> is the value (if any) associated with this event.

<probe_argument> is any qualifier associated with the event, such as the disk, network interface, etc. to which the event applies. Use this to distinguish different events of the same class coming from the same host
<response_level> is an optional argument. If it is specified as “reset”, then an open event with the same hostname, class and probe_arg values will be closed.
Examples:

wpostemsg -m ‘Percent disk’ -r WARNING hostname=isserver1 value=98 probe_arg=’/tmp space’ unix_dfwarn unix
wpostemsg -m ‘Percent inodes’ -r WARNING hostname=isserver1 value=98 probe_arg=’/tmp inodes’ unix_dfwarn unix

[June 03, 2005] Dumping data from the TEC Database with WTDUMPRL by jlsham (GulfBreeze Software)

Posted by: jlsham on Friday, June 03, 2005 - 05:40 PM

One of the more common tasks is dumping received events from TEC to a flat file for archiving. Here is an example:

To do straight reception log dumps, consider using a script like this one that I run all the time. This script will dump all events from the reception log to a file named with the date and then perform a clear of the TEC database.

#!/bin/sh
. /etc/Tivoli/setup_env.sh
LOGFILE=/usr/local/Tivoli/custom/logs
dat=`date +"%m%d%Y" `
date=`date`
tec_date=`date +"%h %d 00:00:00 %Y"`
echo WTDUMPRL Started at $date >> $LOGFILE/tec_maint.log
`wtdumprl -t "$tec_date" >$LOGFILE/$dat.events`
echo WTDUMPRL Finished at $date >> $LOGFILE/tec_maint.log
echo STARTED TEC Event Report at $date >>$LOGFILE/tec_maint.log
echo GZIP Started at $date >> $LOGFILE/tec_maint.log
`gzip -f $LOGFILE/$dat.events`
echo GZIP Finished at $date >> $LOGFILE/tec_maint.log
echo WTDBCLEAR Started at $date >> $LOGFILE/tec_maint.log
`wtdbclear -elt 259600`
echo WTDBCLEAR Finished at $date >> $LOGFILE/tec_maint.log

Sending events with the tec_agent_demo program

The tec_agent_demo program sends events you create within event files. Each event file contains only one event. The events to send are specified in a control file, which the program uses to prompt you before sending each event. You can create test scenarios for your rules by grouping events in specific control files and then specifying the control file as an argument to the program. The program and the files it uses must be run on the event server host.

Configuration prerequisites for using the tec_agent_demo program

The tec_agent_demo program reads a control file that lists the names of files containing the events to send. The control file must be named events_list. The following example shows the contents of a control file.
TEC_Start
NT_NAV_start
NT_NAV_stop
NT_Perf_Alert
TEC_Stop
Each event must be contained within a single file, referred to as an event file. The control file and event files can be in the same directory or different directories. If they're in different directories, you must specify the paths to the event files listed in the control file; for example, /test/TEC_Start.

The example on page *** shows the contents of the NT_Perf_Alert event file. The other event files are formatted similarly but contain different events for this particular test scenario. The following is the syntax for event files:

You can specify as many or as few attributes as you need for an event. Default values provided by the event server are filled in where appropriate by the event server.

The delimiter between the event class name and each attribute is a semi-colon (;).

You can use white space in an event file as needed for readability.

Single line comments can be inserted following a number sign (#) character.

Each event file must end with the END keyword.
NT_Performance_Alert;
hostname=mfoster; origin=146.84.39.103; category=0;
eventType=Information;sid=N/A;sub_source=PerfMon; id=2000;
msg='\\MFOSTER ; Object: Processor ; 
Counter: % Processor Time ; Instance: 0 ; Parent: ; 
Value: 13.586 ; Trigger: > 1.000'; 
date='Apr 29 14:36:34 2000';
sub_origin=mfoster;computer=\\MFOSTER;
END
See Creating event files from events in the reception log for information about an easy way to create event files.

Using the tec_agent_demo program

To send events:
From a bash or UNIX shell command line, enter the following command after initializing the Tivoli environment (for example, after issuing the setup_env.sh command)
export TEC_BIN_DIR=$BINDIR/TME/TEC 
Enter the following command to send the events listed in the control file:
$TEC_BIN_DIR/tec_agent_demo -data /control_file_dir
The control_file_dir is the directory where the control file is located. The control file must be named events_list. The program displays each event that it is ready to send.
Press Enter to send each event. The event is sent to the event server for processing. To exit the simulator program before all of the events listed in the control file are sent, press Ctrl+c.

Tivoli Global User Group Community Newsletter, February 2005

Hints and Tips - Tivoli Monitoring Tivoli Ideas:

To enhance the monitoring of your Tivoli infrastructure, consider the following examples:

I know my endpoints, gateways, Tivoli Servers are running because:

I count Heartbeats received from each endpoint every 15 minutes.

I monitor Tivoli Servers via SNMP every 30 minutes for up/down status.

I use one Tivoli environment to monitor the other.

I monitor capacity for the Tivoli environment.

I periodically run Tivoli health check utilities on Tivoli components.

I periodically restore my Tivoli database backup to a test environment and perform verification tests.

I regularly observe Gateway Fail-over and know it to be reliable.

I put Tivoli Servers on High Availability server environments with fail-over.

I run TEC Rules that create a Trouble Ticket if Endpoint Heartbeats are missed.

I know my Resource Models are working properly because:

I monitor Tivoli Error Logs

I have a Resource Model that checks the status of the other Resource Models every 30 minutes.

I thoroughly test Resource Models before deployment.

I randomly take servers out of production, run load simulations, and verify the monitors go off as expected.

I know my Error Log forwarding is working because:

Application owners periodically audit their error logs against Help Desk tickets, to be sure they are forwarding the correct entries.

Tivoli utilities allow ad hoc testing of the event forwarding mechanism with test messages.

You'll find 65 technical Tivoli Field Guides on the Support Web Site. Download Tivoli Field Guides from: http://www- 306.ibm.com/software/sysmgmt/products/support/Field_ Guides_Technical.html

Recommended Links

In case of broken links please try to use Google search. If you find the page please notify us about new location

IBM Tivoli Enterprise Console Rule Developer's Guide, SC32-1234 Describes how to develop rules and integrate them for event correlation and automated event management.
IBM Tivoli Enterprise Console: Rule Set Reference, SC32-1282 Provides reference information about the IBM Tivoli Enterprise Console rule sets.

ORB Data Links

TEC Rule Tracing (Part 1)
This is the first part of a three part tip which takes a closer look at Rule Tracing. This tip describes how you can generate your own trace messages to help debug your rules
TEC Rule Tracing (Part 2)
This is the second part of a three part tip which takes a closer look at Rule Tracing. This tip describes how you can dynamically turn on and off tracing within your rulebase without having to perform a restart.
TEC Rule Tracing (Part 3)
This is the final part of a three part tip which takes a closer look at Rule Tracing. This tip describes how you can trace particular rules or actions within a rule base, thus allowing you to trace only the rules that you're currently developing.
Common Event Cache Problems
Describes some common problems associated with the Event Cache, and also some utility rules for dumping and counting the events in the EventCache.
Event Cache Demystified
Aims to demystify the event cache by explaining what it is, what it's used for and how it can or should be configured.
Troubleshooting BAROC Problems
Using a recent problem this tip illustrates an example of how you can troubleshoot BAROC Class problems, and describes what is happening during the loading of a rule base and the starting of the Event Server.

Rule Builder's Guide/Table of Contents

Testing and Debugging New Rules

Event Simulator

Debugging Rules
Debugging Information

Rule Debugging Example

Troubleshooting Tivoli Using the Latest Features

This IBM Redbook is an update of the existing Tivoli Enterprise Internals and Problem Determination, SG24-2034 redbook. The material is revised and updated for Tivoli Management Framework and applications post Version 3.6. Some of the applications that are covered from the troubleshooting point of view in this redbook are:

Tivoli Management Framework and related concepts
Tivoli Enterprise Console
IBM Tivoli Monitoring
Tivoli Business Systems Manager
Tivoli Enterprise Data Warehouse
Tivoli Workload Scheduler
IBM Tivoli Configuration Manager
Tivoli Remote Control
IBM Tivoli Access Manager for Operating Systems

Another subject that is associated with troubleshooting is proper maintenance of your Tivoli environment, because proper Tivoli maintenance procedures eliminate many potential Tivoli problems. In addition to the troubleshooting information, this redbook briefly touches on some best practices information for maintaining your Tivoli environment, mostly from the troubleshooting perspective. Table of Contents
Part 1. Introduction, pter 14. Tivoli Enterprise Console

Information about an easy way to create event files.

IBM Redbooks TEC Implementation Examples

SG246614 Tivoli Enterprise Console

This chapter provides information for troubleshooting Tivoli Enterprise Console (TEC) 3.7 and 3.7.1. There was a major architectural change in the product from Tivoli Enterprise Console 3.6 to Tivoli Enterprise Console 3.7, and in this chapter, we will focus on Tivoli Enterprise Console 3.7.X.
Important: There are a number of important fixes that are included in Tivoli Enterprise Console 3.7.1, so if you are working with Tivoli Enterprise Console 3.7 level, we strongly suggest you upgrade to Tivoli Enterprise Console 3.7.1.
We will refer the product name as Tivoli Enterprise Console 3.7, but the discussion is also relevant for Tivoli Enterprise Console 3.7.1. We will pinpoint a few places where Tivoli Enterprise Console 3.7.1 troubleshooting differs from Tivoli Enterprise Console 3.7.

This chapter will cover the following:
Section 14.1, Tivoli Enterprise Console architecture
Section 14.2, Installation debugging

Section 14.3, Tivoli Enterprise Console 3.7 tracing and logging

Section 14.4, RIM tracing

Section 14.5, Rule tracing, profiling, logging, and reporting

Section 14.6, TEC Java Console 3.7 debugging

Section 14.7, TEC Sample Event Information 3.7: Spider daemon

Section 14.8, Tivoli Enterprise Console 3.7 Windows Event Log Adapter debugging

Sending events with the tec_agent_demo program
The tec_agent_demo program sends events you create within event files. Each event file contains only one event. The events to send are specified in a control file, which the program uses to prompt you before sending each event. You can create test scenarios for your rules by grouping events in specific control files and then specifying the control file as an argument to the program. The program and the files it uses must be run on the event server host.

The tec_agent_demo program reads a control file that lists the names of files containing the events to send. The control file must be named events_list. The following example shows the contents of a control file.
TEC_Start
NT_NAV_start
NT_NAV_stop
NT_Perf_Alert
TEC_Stop
Each event must be contained within a single file, referred to as an event file. The control file and event files can be in the same directory or different directories. If they're in different directories, you must specify the paths to the event files listed in the control file; for example, /test/TEC_Start.

The example on page *** shows the contents of the NT_Perf_Alert event file. The other event files are formatted similarly but contain different events for this particular test scenario. The following is the syntax for event files:

You can specify as many or as few attributes as you need for an event. Default values provided by the event server are filled in where appropriate by the event server.

The delimiter between the event class name and each attribute is a semi-colon (;).

You can use white space in an event file as needed for readability.

Single line comments can be inserted following a number sign (#) character.

Each event file must end with the END keyword.
NT_Performance_Alert;
hostname=mfoster; origin=146.84.39.103; category=0;
eventType=Information;sid=N/A;sub_source=PerfMon; id=2000;
msg='\\MFOSTER ; Object: Processor ; 
Counter: % Processor Time ; Instance: 0 ; Parent: ; 
Value: 13.586 ; Trigger: > 1.000'; 
date='Apr 29 14:36:34 2000';
sub_origin=mfoster;computer=\\MFOSTER;
END
See Creating event files from events in the reception log for information about an easy way to create event files.

Using the tec_agent_demo program

To send events:
From a bash or UNIX shell command line, enter the following command after initializing the Tivoli environment (for example, after issuing the setup_env.sh command)
export TEC_BIN_DIR=$BINDIR/TME/TEC 
Enter the following command to send the events listed in the control file:
$TEC_BIN_DIR/tec_agent_demo -data /control_file_dir
The control_file_dir is the directory where the control file is located. The control file must be named events_list. The program displays each event that it is ready to send.
Press Enter to send each event. The event is sent to the event server for processing. To exit the simulator program before all of the events listed in the control file are sent, press Ctrl+c.
Etc

In addition, both tracing and profiling has been enhanced to allow a more rule specific debugging. This is described in Enhanced rule tracing and profiling.
Event Activity Reports

Event Activity Reports represent a textual listing of event activities in the rule engine. The following items can be specified to report and can be dynamically changed during reporting:

How often to write the report

The file and path name for the report

Events to exclude from the report

Attribute criteria to include in the report

Counter threshold (for example, "do not include counts of less than 5 in the report")

The relevant parts of the im.rls file are shown Example 14-35. The im_configure rule includes the initial configuration settings to create an Event Activity Report (the editable parts are shown in bold):

Example 14-35 Event Activity Report
----------------------------------------------------------------
% NAME - IM Configuration.
% This rule is used to configure the IM rule behavior.
% Event activity reporting, event filtering, maintenance mode,
% heartbeat, thresholding and event correlation can be activated.
%---------------------------------------------------------------- 
rule:  im_configure : (
  event: _event of_class  'TEC_Start'
    where [],
   reception_action: im_parameters: (
   ...
      %----------------------------------------------
      % Activate rule functionality (active/inactive)
      %----------------------------------------------
      record(event_activity,inactive),
      ...
      %------------------------------------------------------------------
      % Event activity
      % This section allows the event activity report to be customized.
      % The name of the report file, the reporting frequency, 
      % event reporting threshold, events to exclude from the report and 
      % attribute criteria to include in the report can be specified.
      %------------------------------------------------------------------
      ( recorded(event_activity,active) ->
         _reporting_frequency is 20,                     % Write statistics this often (in seconds)
         init_event_activity('/tmp/event_activity',      % Store report in this file  
                              ['TEC_Heartbeat',          % Do not report these events
                               'TEC_Maintenance'],
                              [ source,                  % Attribute reporting criteria
                                hostname,                % Can be count of single attribute
                                severity,
                                status,
                                [hostname,severity],     % Or multiple attributes
                                [class,hostname]         % use class key word to report by class name
                               ],
                               5                          % Do not report counts less than this 
                              ),
         first_instance(event:_ev of_class 'TEC_Tick' where [ ]),
         set_timer(_ev, _reporting_frequency, 'Event Activity Report')
      ;
        true
      ),
   ...
).
To enable Event Activity Reporting, change the line:
record(event_activity,inactive),
to:
record(event_activity,active),
In the Event activity section, all settings for what should be reported can be applied. The _reporting_frequency can be specified as well as the initial event activity settings, such as:
init_event_activity(	output_file_name,
	event_exclusion_list,
	attribute_reporting_criteria,
	reporting_threshold)
The Event Activity rules provided with the im.rls file in the default rule base are shown Example 14-36.

Example 14-36 Event Activity rules
%-----------------------------------------------------------------------------------------
% Collect event activity statistics:
% This rule is used to collect event activity statistics. It is activated when statistics are turned on in the initialization rule.
%-----------------------------------------------------------------------------------------
rule: update_event_activity: (
  event: _event of_class _class
    where [],
  reception_action: update_activity: ( 
     recorded(event_activity,active),   
     update_event_activity(_event)
  )
). 
%-----------------------------------------------------------------------------------------
% Print Event Activity Report:
% This periodic call prints the event activity report. Report properties are set in the initialization rule. After the report is printed, all statistics are reset.
%-----------------------------------------------------------------------------------------
timer_rule: reset_event_activity: (
  event: _event of_class _class
    where [],
  timer_info: equals 'Event Activity Report',
  timer_duration: _rep_freq,
  action: reset_activity: ( 
     recorded(event_activity,active),
     print_event_activity,
     reset_event_activity,     
     set_timer(_event,_rep_freq,'Event Activity Report')
  )
).
Copyright © 1996-2008 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

Standard disclaimer: The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: June 02, 2008