Softpanorama
(slightly skeptical) Open Source Software Educational Society

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

Google   


Sending events to TEC from scripts

News Recommended Links Reference Arguments Examples

Typical Errors

"Error creating a connection to the Event Server" Tips Humor Etc

Sending a Tivoli event from a script involves several steps:

Optionally you can do a lot of thing and populate any slot of the message. For example:

Once an event is sent to the TEC, it will remain until it is removed.  Events can be removed manually from the TEC console display, or by two automatic methods.  Either a closing event can be sent, or a timer can be set on the event so that it will be closed after a specified period of time.  To use a “closing” event, send a message with the same hostname and class, but with an attribute status=CLOSED.  To close events based on a timer, you need to set a timer for a specific class, and specify the duration for the timer.

Diagnostic can be called either non existent or very bad as both wpostzmsg and postzmsg  do minimal job to validate input.  Also they cannot check the existence of the class of messages you are sending so it is wrong it will be discarded. That means that typing class of the message is a bad idea: it is safer to copy it verbatim from some source.

Both commands have similar syntax. In both cases you need to create the correct environment before executing the command by sourcing  lcf_env.sh.  Commands should be run as root or as Tivoli user. Running under other IDs produces error  "error creating a connection to the Event Server".  It is possible to change endpoint configuration so that other IDs can post messages.

If you have distributed an adapter to the endpoint, both commands can be found in the $LCF_BINDIR/../bin directory.

Here is the syntax for  wpostzmsg  (the syntax for postzmsg is identical):

wpostzmsg [-S server | -f configuration_file] [-m message] [-r severity] [attribute=value...] class source

Typically to use it in Perl script you need first to switch to root or Tivoli user (if you are not already in this role), then create environment and only then invoke a command:

`sudo /export/home/alerts/bin/postalert.sh  "The alert to be send" CRITICAL  Logfile_Sendmail "hostname=myserver@mydomain.my" `

where postalert should be a shell scripts that contains the necessary environment initialization and invocation of wpostzmsg:

. $LCF_PATH/lcf_env.sh && $LCF_BINDIR/../bin/wpostzmsg -m "$1" -r $2 $4 $3 LOGFILE`;

Arguments

Notes:

If you are using wpostzmsg on a system that is configured both as an endpoint and as a managed node, you might want to create a shell alias for the endpoint version of the command. The following examples show how you might do this:

Make sure your PATH does not include both versions of the command.

Examples

The following example for UNIX environments sends a test message that displays an Su_Failure event of severity WARNING on the event consoles (we assume that  lcf_env.sh is in PATH):
. lcf_env.sh  && $LCF_BINDIR/../bin/wpostzmsg -r WARNING -m "su login failure." Su_Failure LOGFILE

.  lcf_env.sh  && $LCF_BINDIR/../bin/wpostzmsg -m ‘Percent disk’ -r WARNING hostname=isserver1 value=98 probe_arg=’/tmp space’ unix_dfwarn unix

.  lcf_env.sh  && $LCF_BINDIR/../bin/wpostzmsg -m ‘Percent inodes’ -r WARNING hostname=isserver1 value=98 probe_arg=’/tmp inodes’ unix_dfwarn unix

 

wpostemsg (endpoint version)

This is older version of wpostzmsg Posts an event to the event server using Tivoli endpoint communication to a Tivoli Enterprise Console gateway.

wpostzmsg -r WARNING -m "WARNING: /pci@8,700000/lpfc@2/sd@f,0 (sd44
):" SCSI_Error LOGFILE

Syntax

wpostemsg [-S server | -f configuration_file] [-m message] [-r severity ] [ attribute=value... ] class source

Description

The wpostemsg command sends an event to an event server using Tivoli endpoint communication to a Tivoli Enterprise Console gateway.

 

Notes:
  1. Although this command is still supported, the wpostzmsg command is preferred for sending events using Tivoli communication.
  2. Because cache files cannot be shared by applications, you should not use a configuration file for this command that is being used by another program (such as an adapter).

This command requires the installation of a Tivoli endpoint on the same system where you are running the command. If you have distributed an adapter to the endpoint, this command can be found in the $LCF_BINDIR/../bin directory.

This command is dependent upon the endpoint environment variables, which can be set using the lcf_env.sh or lcf_env.csh scripts that are included in the endpoint installation.

If you are using wpostemsg on a system that is configured both as an endpoint and as a managed node, you might want to create a shell alias for the endpoint version of the command. The following examples show how you might do this:

Make sure your PATH does not include both versions of the command.

Authorization

user

Options

attribute=value...
Assigns a value to any valid attribute. The attribute should be one defined for the event class. Separate multiple attribute=value expressions with spaces.
class
Specifies the class of the event. It must match a class that is configured at the server. Classes are defined by the event adapter and are listed in the adapter BAROC file. If any blank spaces are in the class name, enclose the class name in double quotation marks.
source
Specifies the source of the event. The source is defined by the adapter type or it can be set to a default source in the event adapter configuration file. If any blank spaces are in the source name, enclose the source name in double quotation marks.
 
-f configuration_file
Specifies the name of the configuration file. See the IBM Tivoli Enterprise Console Event Integration Facility Reference for more information about configuration files.
-m message
The text of the event, in double quotation marks.
-r severity
Specifies a severity. The severity must be one defined for the event class.
-S server
Specifies the name of the event server in name registry format. Specify @EventServer to have events submitted to the locally named event server of the Tivoli Enterprise Console gateway. To indicate a remote server, specify @EventServer#tmr, where tmr is the name of a Tivoli region. If you do not specify the -S or -f option, the event is sent to the event server defined by the Tivoli Enterprise Console gateway.

If portmapper is running on the event server, you can specify a TCP/IP host name or IP address instead. This results in non-Tivoli communication between the Tivoli Enterprise Console gateway and the event server.

Examples

The following example sends a test message that displays an Su_Failure event of severity WARNING on the event consoles:
wpostemsg -r WARNING -m "su failure" Su_Failure LOGFILE

See Also

postemsg, postzmsg, TECAgent, wpostemsg (managed node version), wpostzmsg (endpoint version), wpostzmsg (managed node version), wsetemsg

Old News ;-)

[DOC] Sending events to Tivoli

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:

/var/local/Tivoli/Princeton/bin/tiv wpostemsg -m ‘Percent disk’ -r WARNING hostname=isserver1 value=98 probe_arg=’/tmp space’ unix_dfwarn unix

/var/local/Tivoli/Princeton/bin/tiv wpostemsg -m ‘Percent inodes’ -r WARNING hostname=isserver1 value=98 probe_arg=’/tmp inodes’ unix_dfwarn unix 

Closing events 

Once an event is sent to the TEC, it will remain until it is removed.  Events can be removed manually from the TEC console display, or by two automatic methods.  Either a closing event can be sent, or a timer can be set on the event so that it will be closed after a specified period of time.  To use a “closing” event, send a message with the same hostname and class, but with “status=CLOSED”.  To close events based on a timer, notify ESM that you want to set a timer for a specific class, and specify the duration for the timer.

Recommended Links


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

[DOC] Sending events to Tivoli

TivoliLogging - Perl Extension for Tivoli

Typical Errors

 Error creating a connection to the Event Server

Making connections to the event server

The following scenarios can occur when there are problems connecting to the event server:

IBM - postzmsg and postemsg "error creating a connection to the Event Server" errors

postzmsg gets "error creating a connection to the Event Server"
and postemsg sometimes gets tec_put_event failed errno 38
Neither postemsg or postzmsg is using -f for config file.

Cause

permissions

Solution

The default location for a cache file will be /etc/Tivoli/tec on unix and %systemroot%\system32\drivers\etc\Tivoli on Windows.

Error 38 is returned by the EIF code when an event can't be sent to TEC and it also can't be cached for some reason.

The postzmsg error is also because the event is unable to be written to the cache file. Normally, the reason is permissions on the cache directory or cache file. In order for the event to be cached, the file does not have to exist but the directory path to it does. EIF will not create directories. The user should try opening permissions wide open on the cache directory location and the file.

Under normal circumstances using postemsg no cache file is used. But if the connection to the server is down, then the 'e' commands have the same problem.  The 'z' commands have the problem in normal circumstances due to the way the EEIF handles caching.

With the EEIF, events are always written to the cache and a separate thread is used to send the events to the server.  The advantage of this is that when the EEIF is used in a long running adapter, the cache can be automatically emptied when connection to the server is restored without requiring an additional event.
   


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