![]() |
![]() |
The server and client messages provide a record of TSM activity that you can 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 61 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 61. Event Logging Overview
Task | Required Privilege Class |
---|---|
Enable or disable events
Begin or end event logging | System |
To control event logging do the following:
When you enable or disable events, you can specify the following:
To enable or disable events, issue the ENABLE EVENTS and DISABLE EVENTS commands. For example,
enable events userexit error,severe
enable events userexit severe nodename=*
disable events userexit error
A receiver for which event logging has begun is an active receiver. To begin and end logging for one or more receivers, issue the BEGIN EVENTLOGGING and END EVENTLOGGING commands.
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. To begin logging events to receivers for which event logging is not started automatically, issue the BEGIN EVENTLOGGING command. You can also use this command after you have disabled event logging to one or more receivers. To end event logging for an active receiver issue the END EVENTLOGGING command.
For example,
begin eventlogging eventserver
end eventlogging eventserver
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
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. Setting up logging for these receivers is also similar:
For example,
fileexit yes /tsm/server/data replace filetextexit yes /tsm/server/data replace
For example,
userexit no fevent.exit
enable events file error
enable events userexit error,severe
You can also enable events to one or more client nodes or servers by specify the NODENAME OR SERVERNAME parameter. See Enabling and Disabling Events for more information.
begin eventlogging userexit
See Beginning and Ending Event Logging for more information.
TSM includes the Tivoli receiver, a Tivoli/Enterprise Console (T/EC) adapter
for sending events to the T/EC. You can specify the events to be logged
based on their source. The valid event names are:
Event Name | Source |
---|---|
TSM_SERVER_EVENT | TSM server |
TSM_CLIENT_EVENT | TSM clients |
TSM_APPL_EVENT | TSM application program interface |
TSM_TDP_DOMINO_EVENT | TDP for Domino |
TSM_TDP_EXCHANGE_EVENT | TDP for MS Exchange |
TSM_TDP_INFORMIX_EVENT | TDP for Informix |
TSM_TDP_ORACLE_EVENT | TDP for Oracle |
TSM_TDP_SQL_EVENT | TDP for MS SQL |
The application client must have enhanced T/EC support enabled in order to route the events to the T/EC. Because of the number of messages, you should not enable all messages from a node to be logged to the T/EC.
To set up Tivoli as a receiver for event logging:
To create a new rule base, do the following:
techost 9.114.22.345 tecport 1555
tecbegineventlogging yes
Or
begin eventlogging tivoli
See Beginning and Ending Event Logging for more information.
You can use the simple network management protocol (SNMP) together with event logging to do the following:
The management information base (MIB), which is shipped with TSM, defines the variables that will run server scripts and return the server scripts' results. You must register SNMPADMIN, the administrative client the server runs these scripts under. Although a password is not required for the subagent to communicate with the server and run scripts, a password should be defined for SNMPADMIN to prevent access to the server from unauthorized users. An SNMP password (community name) is required, however, to access the SNMP agent, which forwards the request to the subagent.
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 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 AIX 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 read-write 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 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.
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. The Distributed Protocol Interface (DPI(R)) 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(R) agent available for Windows 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 62 illustrates a typical TSM implementation:
Figure 62. TSM SNMP Implementation
Figure 63 shows how the communication for SNMP works in a TSM system:
Figure 63. Manager-Agent-Subagent Communication
Notes:
The Tivoli Storage Manager SNMP set up procedure is illustrated by Figure 64:
Figure 64. Tivoli Storage Manager SNMP Set Up
To set up TSM monitoring through SNMP, do the following:
Figure 65. Example of SNMP Communication Method Options
commmethod snmp snmpheartbeatinterval 5 snmpmessagecategory severity |
For example, the AIX SystemView agent is configured by customizing the file /etc/snmpd.conf. A default configuration might look like this:
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.
# 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. The sending server receives the enabled events and routes them to a designated event server. This is done by a receiver that Tivoli Storage Manager provides. At the event server, an administrator can enable one or more receivers for the events being routed from other servers. Figure 66 shows the relationship of a sending TSM server and a TSM event server.
Figure 66. 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=*
begin eventlogging eventserver
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
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