In a nutshell: use the ‘eventcreate‘

I had an issue with ITM Windows Agent creating events which I was then sending out email alerts via a UNIX script.

The simple problem was backslashes in windows paths where the “Take Action” notification script was literalizing characters which might be part of the EventLog Description

For example:

"c:\Damned these\nagging\slashes\argh"

became

c:\Damned these
agging\slashesrgh

Yes, simply quoting my string would have solved most of my problem, IT DID HOWEVER lead me to a handy windows command for testing, called ‘eventcreateid‘

Example : eventcreate /ID 101 /SO FooBar /D “Test Message for ITM” /T ERROR /L Application

Obtaining Product Codes for IBM Tivoli Monitoring (ITM v6)

Local method:

Parse the proddsc.tbl file on a UNIX/Linux system to get the list by doing this:

UNIX
awk -F\| '/^[^*#]/ {print $1,$2}' ${CANDLEHOME}/registry/proddsc.tbl | sort | uniq


Or, IBM’s site http://www-01.ibm.com/support/docview.wss?rs=2366&context=SSZ8F3&dc=DB520&dc=DB560&uid=swg21265222&loc=en_US&cs=UTF-8&lang=en&rss=ct2366tivoli

Synopsis

A nice feature which isn’t publicized too much in ITM for Linux and Unix agents is the ping capability.

They’re refrerred to as “Host Availability” for Linux and “Ping Attributes” for Unix

Both will accept an input file containing a list of servers to “ping”, and both will return status and response time.

Enabling the ping hosts file

Linux

$CANDLEHOME/config/lz.ini: KLZ_PINGHOSTLIST=<path_to_list>
# e.g. KLZ_PINGHOSTLIST=$CANDLEHOME/config/my_hostlist
# Add this to the lz.config if you want to avoid having to reconfig the agent

Unix

$CANDLEHOME/config/ux.ini: KUX_PINGHOSTLIST=<path_to_list>
# e.g. KUX_PINGHOSTLIST=$CANDLEHOME/config/my_hostlist
# Add this to the lz.config if you want to avoid having to reconfig the agent

Extra feature difference

One minor, but important, difference is that the Linux component will only ping servers in the list, while the Unix component has the additional feature using a situation to ping any target host from any managed system.

This makes every managed system (agent) a ping source to target critical servers.

Attribute Group: UNIX Ping
Situation Definitions: System_Name == $NODE$, Target_Host == webserver1

Reference: http://help.mosso.com/article.php?id=180

Your script is calling for the “REMOTE_ADDR” and receives the IP of a server in front of one of our back-end servers. The web facing server is then passing the scripts output without giving the expected REMOTE_ADDR of the visitor. In order for your scripts to recognize that they are on a cluster and log the correct IP of your visitors, you will need to replace and add the code below.

For PHP:
Locate any lines of code that are similar to this snippet of code,
$_SERVER['REMOTE_ADDR'];
And replace it with this snippet of code,
$_SERVER['HTTP_X_CLUSTER_CLIENT_IP'];

For ASP:
Locate any lines of code that are similar to this snipper of code,
Request.ServerVariables(“REMOTE_ADDR”)
And replace it with this snipper of code,
Request.ServerVariables(“HTTP_X_CLUSTER_CLIENT_IP”)

My fix for this required a unix shell (if you’re on a Windows look at installing cygwin on your system.

# Ftp your web content down to your local system

$ for file in `find <path_to_files> -exec grep -l REMOTE_ADDR {} \;`; do base=`basename $file`; sed ‘s/REMOTE_ADDR/HTTP_X_CLUSTER_CLIENT_IP/g’ $file > /tmp/$base; grep HTTP_X_CLUSTER_CLIENT_IP /tmp/$base >/dev/null 2>&1 && grep REMOTE_ADDR $file && echo “Updated $base” && mv
/tmp/$base $file; done

# Then simply upload the changed files to your system.