The server and client messages provide a record of TSM activity that you, as an administrator, may use to monitor the server. You can log server messages and most client messages as events to one or more repositories called receivers. You can log the events to any combination of the following receivers:
In addition, you can filter the types of events to be enabled for logging. For example, you might enable only severe messages to the event server receiver and one or more specific messages, by number, to another receiver. Figure 70 shows a possible configuration in which both server and client messages are filtered by the event rules and logged to a set of specified receivers:
Figure 70. Event Logging Overview
To control event logging do the following:
You can issue the BEGIN EVENTLOGGING and END EVENTLOGGING commands to begin and end logging for one or more receivers.
Note: | At server start-up event logging begins automatically to the server console and activity log and for any receivers that are started based on entries in the server options file. See the appropriate receiver sections for details. |
You can enable or disable specific events or groups of events by receiver by issuing the ENABLE EVENTS and DISABLE EVENTS commands. When you enable or disable events, you can specify the following:
For example, to enable event logging to a user exit for server messages with a severity of WARNING, enter:
enable events userexit warning
Notes:
Logging events to the server console and activity log begins automatically at server startup. To enable all error and severe client events to the console and activity log, issue the following command:
enable events console,actlog error,severe nodename=*
Note: | Enabling client events to the activity log will increase the database utilization. You can set a retention period for the log records by using the SET ACTLOGRETENTION command (see Setting the Activity Log Retention Period). At server installation, this value is set to one day. If you increase the retention period, utilization is further increased. For more information about the activity log, see Using the Tivoli Storage Manager Activity Log. |
You can disable server and client events to the server console and client events to the activity log. However, you cannot disable server events to the activity log. Also, certain messages, such as those issued during server startup and shutdown and responses to administrative commands, will still be displayed at the console even if disabled.
You can log events to a file exit and a user exit:
Both file and user exits receive event data in the same data block structure (see Appendix C, User Exit and File Exit Receivers for details). Setting up logging for these receivers is also similar. Here are the steps involved:
To specify a binary version of the file named events.fexit, enter:
fileexit yes events.fexit append
To specify a readable text version of the file named events.ftexit, enter:
filetextexit yes events.ftexit append
For a description of the file format, see Readable Text File Exit (FILETEXTEXIT) Format.
userexit yes events.uexit
For details about these server options, see Administrator's Reference.
begin eventlogging userexit
enable events userexit error,severe
You must specify the name of the user exit in the USEREXIT server option.
enable events file error nodename=msmith,hstanford,bkelly
You must specify the name of the file in the FILEEXIT server option.
TSM includes the Tivoli receiver, a Tivoli/Enterprise Console (T/EC) adapter for sending events to the TE/C. An event name is a four-digit message number preceded by the appropriate prefix:
Tivoli Data Protection Application Client | Prefix | Range |
TDP for Exchange | ACN | 3500-3649 |
TDP for Domino | ACD | 5200-5299 |
TDP for Oracle | ANS | 500-599 |
TDP for Informix | ANS | 600-699 |
TDP for SQL | ACO | 3000-3999 |
Notes:
Enhanced T/EC support provides unique event classes for messages logged to the T/EC from a Tivoli Storage Manager server. The following examples show the message formats:
where:
For example:
TSM_SERVER_ANR2017 TSM_SERVER_ANR7805_AIX TSM_CLIENT_ANE4027 TSM_APPL_ANE4990 TSM_TDP_EXCHANGE_ACN3520
This section describes what you must do to set up Tivoli as a receiver for event logging.
Note: | If you have migrated from ADSM Version 3 and have an existing
ibmadsm.baroc file, do one of the following:
|
enable events tivoli severe,error
techostname 9.114.22.345 tecport 1555
tecbegineventlogging yes
Or
begin eventlogging tivoli
For details about the server options shown, see Administrator's Reference.
You can use the simple network management protocol (SNMP) together with event logging to do the following:
The management information base (MIB) shipped with TSM defines variables with which to run server scripts and return the results. The server runs these scripts under an administrative client, SNMPADMIN, that you must register. A password is not required for the subagent to communicate with the server and run scripts. However, an SNMP password (community name) is required to access the SNMP agent, which forwards the request to the subagent. Also, you should define a password for SNMPADMIN to prevent access to the server from unauthorized users.
Note: | Because the SNMP environment has weak security, you should consider not granting SNMPADMIN any administrative authority. This restricts SNMPADMIN to issuing TSM queries. |
SNMP SET requests are accepted for the name and input variables associated with the script names stored in the MIB by the SNMP subagent. This allows a script to be run by running a GET request for the ibmAdsm1ReturnValue and ibmAdsm2ReturnValue variables. A GETNEXT request will not cause the script to be run. Instead, the results of the previous script processed will be retrieved. When an entire table row is retrieved, the GETNEXT request is used. When an individual variable is retrieved, the GET request is used.
Here is a sample TSM configuration with SNMP:
To run an arbitrary command from an SNMP management application, for example NetView, follow these steps:
To set the variables associated with the script, the nodes on which the subagent and the agent are run must have read-write authority to the MIB variables. This is done through the SNMP configuration process on the system that the SNMP agent runs on. For example, here is the SNMP configuration screen:
Figure 71. IBM SNMP Configuration Screen
An SNMP agent is needed for communication between an SNMP manager and its managed systems. The SNMP agent is accomplished through the snmpd daemon, and the Distributed Protocol Interface (DPI) Version 2 is an extension of this SNMP agent.
TSM management through SNMP requires additional information in the MIB of the local agent. Therefore, an SNMP agent supporting DPI Version 2 must be used to communicate with the TSM subagent. This SNMP agent is not included with TSM. IBM makes the SystemView agent available for Windows NT, Windows 95, and AIX. The TSM subagent is included with TSM and, before server startup, must be started as a separate process communicating with the SNMP agent.
The SNMP manager system can reside on the same system as the TSM server, but typically would be on another system connected through SNMP. The SNMP management tool can be any application, such as NetView or Tivoli, that can manage information through SNMP MIB monitoring and traps. The TSM server system runs the processes needed to send TSM event information to an SNMP management system. The processes are:
Cross-system support for communication between the server and subagent is not supported, and these products must be installed and run on the TSM server system. Figure 72 illustrates a typical TSM implementation:
Figure 72. TSM SNMP Implementation
Figure 73 shows how the communication for SNMP works in a TSM system:
Figure 73. Manager-Agent-Subagent Communication
Notes:
Follow this sequence for setting up NetView for Windows NT:
The Tivoli Storage Manager SNMP set up procedure is illustrated by Figure 74:
Figure 74. Tivoli Storage Manager SNMP Set Up
To set up TSM monitoring through SNMP, do the following:
Figure 75. Example of SNMP Communication Method Options
commmethod snmp snmpheartbeatinterval 5 snmpmessagecategory severity |
logging file=/var/snmp/snmpd.log enabled logging size=0 level=0 community public community private 127.0.0.1 255.255.255.255 readWrite community system 127.0.0.1 255.255.255.255 readWrite 1.17.2 view 1.17.2 system enterprises view trap public <snmp_manager_ip_adr> 1.2.3 fe snmpd maxpacket=16000 smuxtimeout=60 smux 1.3.6.1.4.1.2.3.1.2.2.1.1.2 public
where <snmp_manager_ip_adr> is the IP address of the system running the SNMP management application.
Before starting the agent, ensure that the DPI agent has been started and not the default SNMP agent that ships with the operating system or with TCP/IP. If you are using the SystemView agent, you must set the SVA_SNMPD environment variable to ensure that the correct agent is started. You can set the variable to any value. For example, on AIX (korn shell) use the following export command:
# export SVA_SNMPD="active"
Then run svastart.
begin eventlogging snmp enable event snmp all
[C:\] loadmib -load adsmserv.mib
The Windows NT event log lets you display enabled events in the Windows NT Application Log in the Windows NT Event Viewer. The information displayed includes:
To enable severe and error events for logging on the Event Log, you must first issue the following command:
enable events nteventlog severe,error
One or more servers can send server events and events from their own clients to another server for logging. Tivoli Storage Manager provides a receiver at the sending server that receives the enabled events and routes them to a designated event server. At the event server, an administrator can enable one or more receivers for the events being routed from other servers. Figure 76 shows the relationship of a sending TSM server and a TSM event server.
Figure 76. Server to Server Event Logging
The following scenario is a simple example of how enterprise event logging can work.
The administrator at each sending server does the following:
define server server_b password=cholla hladdress=9.115.3.45 lladdress=1505
define eventserver server_b
enable events eventserver severe,error,warning enable events eventserver severe,error nodename=*
The administrator at the event server does the following:
fileexit yes events append
Then the administrator enables the events by issuing the ENABLE EVENTS command for each sending server. For example, for SERVER_A the administrator would enter:
enable events file severe,error servername=server_a
Note: | By default, logging of events from another server is enabled to the event server activity log. However, unlike events originating from a local server, events originating from another server can be disabled for the activity log at an event server. |
One or more servers can send events to an event server. An administrator at the event server enables the logging of specific events from specific servers. In the previous example, SERVER_A routes severe, error, and warning messages to SERVER_B. SERVER_B, however, logs only the severe and error messages. If a third server sends events to SERVER_B, logging is enabled only if an ENABLE EVENTS command includes the third server. Furthermore, the SERVER_B determines the receiver to which the events are logged.
Attention: It is important that you do not set up server-to-server event logging in a loop. In such a situation, an event would continue logging indefinitely, tying up network and memory resources. TSM will detect such a situation and issue a message. Here are a few configurations to avoid:
The QUERY ENABLED command displays a list of server or client events that are enabled or disabled by a specified receiver. Because the lists of enabled and disabled events could be very long, TSM displays the shorter of the two lists. For example, assume that 1000 events for client node HSTANFORD were enabled for logging to the user exit and that later two events were disabled. To query the enabled events for HSTANFORD, enter:
query enabled userexit nodename=hstanford
The output would specify the number of enabled events and the message names of disabled events:
998 events are enabled for node HSTANFORD for the USEREXIT receiver. The following events are DISABLED for the node HSTANFORD for the USEREXIT receiver: ANE4000, ANE49999
The QUERY EVENTRULES command displays the history of events that are enabled or disabled by a specific receiver for the server or for a client node.
query enabled userexit nodename=hstanford