TSM server and client messages provide a record of TSM activity that you, as an administrator, may use to monitor TSM. 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 66 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 66. 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 TSM 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 TSM 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 B, 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 TSM events to the TE/C. This section describes what you must do to set up Tivoli as a receiver for event logging:
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 (for example, ibmAdsmServerScript1/2 or ibmAdsmM1Parm1/2/3), 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. In AIX, the file name is /etc/snmpd.conf.
Here is an example:
community public 9.115.20.174 255.255.255.254 readWrite community public 9.115.46.25 255.255.255.254 readWrite community public 127.0.0.1 255.255.255.254 readWrite community public 9.115.20.176 255.255.255.254 readWrite smux 1.3.6.1.4.1.2.3.1.2.2.1.1.2 public
The statements grant readWrite authority to the MIB for the local node through the loopback mechanism (127.0.0.1), and to nodes with the three 9.115.xx.xx addresses. On AIX, TSM installation automatically updates the/etc/mib.defs file with the names of the TSM MIB variables. This makes the MIB variables available symbolically to applications like the AIX System Monitor product. The smux statement allows the dpid2 daemon to communicate with snmpd.
The snmpinfo command is shipped with the System Monitor product. Here is an example of this command used to set and retrieve MIB variables:
snmpinfo -v -ms -c public -h tpcnov73 ibmAdsmServerScript1.1=QuerySessions
This command issues the set operation (-ms ), passing in community name public, sending the command to host tpcnov73, and setting up variable ibmAdsmServerScript1 to have the value QuerySessions. QuerySessions is the name of a server script that has been defined on a server that will register with the TSM subagent. In this case, the first server that registers with the subagent is the .1 suffix in ibmAdsmServerScript1.1. The following commands set the parameters for use with this script:
snmpinfo -v -ms -c public -h tpcnov73 ibmAdsmM1Parm1.1=xyz snmpinfo -v -ms -c public -h tpcnov73 ibmAdsmM1Parm2.1=uvw snmpinfo -v -ms -c public -h tpcnov73 ibmAdsmM1Parm3.1=xxx
You can set zero to three parameters. Only the script name is needed. To make the QuerySessions script run, retrieve the ibmAdsmM1ReturnValue variable (in this case, ibmAdsmM1ReturnValue.1. For example:
snmpinfo -v -mg -c public -h tpcnov73 ibmAdsmM1ReturnValue.1
The results of the command are returned as a single string with embedded carriage return/newline characters.
Note: | Not all MIB browsers properly handle embedded carriage return/newline characters. |
snmpinfo -v -md -c public -h tpcnov73 ibmAdsm
in which all TSM MIB variables are displayed.
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. AIX 4.2.1 and later include such an SNMP agent. 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 67 illustrates a typical TSM implementation:
Figure 67. TSM SNMP Implementation
Figure 68 shows how the communication for SNMP works in a TSM system:
Figure 68. Manager-Agent-Subagent Communication
Notes:
The Tivoli Storage Manager SNMP set up procedure is illustrated by Figure 69:
Figure 69. Tivoli Storage Manager SNMP Set Up
To set up TSM monitoring through SNMP, do the following:
Figure 70. 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.
Note: | For AIX 4.2.1 and above, the correct agent is shipped with the system. |
# export SVA_SNMPD="active"
Then run svastart.
begin eventlogging snmp enable event snmp all
[C:\] loadmib -load adsmserv.mib
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 71 shows the relationship of a sending TSM server and a TSM event server.
Figure 71. 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 fileexit 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