Tivoli Header

Administrator's Guide


Logging Tivoli Storage Manager Events to Receivers

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:

TSM server console and activity log
See Logging Events to the Tivoli Storage Manager Server Console and Activity Log.

File and user exits
See Logging Events to a File Exit and a User Exit.

Tivoli event console
See Logging Events to the Tivoli/Enterprise Console.

Simple Network Management Protocol (SNMP)
See Logging Events to an SNMP Manager.

The Windows Event Log
See Logging Events to the Windows Event Log.

Event server receiver (Enterprise Event Logging)
Routes the events to an event server. See Enterprise Event Logging: Logging Events to Another Server.

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 68 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 68. Event Logging Overview

Event Logging Overview

Task Required Privilege Class
Enable or disable events
Begin or end event logging
System

Controlling Event Logging

To control event logging do the following:

  1. Enable or disable logging for one or more event types and for one or more receivers.
  2. Begin or end logging to one or more receivers.

Enabling and Disabling Events

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,

If you specify a receiver that is not supported on any platform, or if you specify an invalid event or name, TSM issues an error message. However, any valid receivers, events, or names that you specified are still enabled. Certain events, such as messages that are issued during server start-up and shutdown, automatically go to the console. They do not go to other receivers, even if they are enabled.
Note:
Server messages in the SEVERE category and message ANR9999 can provide valuable diagnostic information if there is a serious problem. For this reason, you should not disable these messages. Use the SET CONTEXTMESSAGING ON command to get additional information that could help determine the cause of ANR9999D messages. The Tivoli Storage Manager polls the server components for information that includes process name, thread name, session ID, transaction data, locks that are held, and database tables that are in use.

Beginning and Ending Event Logging

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,

Logging Events to the Tivoli Storage Manager Server Console and Activity Log

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
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.

Logging Events to a File Exit and a User Exit

You can log events to a file exit and a user exit:

Note:
Both types of event receivers must be specified in the server options file (dsmserv.opt) file.

Both file and user exits receive event data in the same data block structure. Setting up logging for these receivers is also similar:

  1. Add an option for the exit to the server options file:
  2. Enable events for the receiver. You must specify the name of the user exit in the USEREXIT server option and the name of the file in the FILEEXIT server option. Here are two examples:
    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.

  3. If you did not specify YES in the server option, begin event logging. For example, to begin event logging for a user-defined exit, enter:
    begin eventlogging userexit
    

    See Beginning and Ending Event Logging for more information.

Logging Events to the Tivoli/Enterprise Console

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:

  1. Define the TSM event classes to the T/EC with the ibmtsm.baroc file, which is distributed with the server.
    Note:
    Please refer to TEC documentation for instruction on removing an existing baroc file, if needed, and installing a new baroc file. If you have migrated from ADSM Version 3 and have an existing ibmadsm.baroc file, do one of the following:
    • Remove the file.
    • Create a new rule base.
    • Copy the file.
    Before the events are displayed on a T/EC, you must import ibmtsm.baroc into an existing rule base or create a new rule base and activate it. To do this:

    To create a new rule base, do the following:

    1. Click on the Event Server icon from the TME desktop. The Event Server Rules Bases window will open.
    2. Select Rule Base from the Create menu.
    3. Optionally, copy the contents of an existing rule base into the new rule base by selecting the Copy pop-up menu from the rule base to be copied.
    4. Click on the RuleBase icon to display the pop-up menu.
    5. Select Import and specify the location of the ibmtsm.baroc file.
    6. Select the Compile pop-up menu.
    7. Select the Load pop-up menu and Load, but activate only when server restarts from the resulting dialog.
    8. Shut down the event server and restart it.
  2. To define an event source and an event group:
    1. From the TME desktop, select Source from the EventServer pop-up menu. Define a new source whose name is TSM from the resulting dialog.
    2. From the TME desktop, select Event Groups from the EventServer pop-up menu. From the resulting dialog, define a new event group for TSM and a filter that includes event classes IBMTSMSERVER_EVENT and IBMTSMCLIENT_EVENT.
    3. Select the Assign Event Group pop-up menu item from the Event Console icon and assign the new event group to the event console.
    4. Double-click on the Event Console icon to start the configured event console.
  3. Enable events for logging to the Tivoli receiver. See Enabling and Disabling Events for more information.
  4. In the server options file (dsmserv.opt), specify the location of the host on which the Tivoli server is running. For example, to specify a Tivoli server at the IP address 9.114.22.345:1555, enter the following:
    techost 9.114.22.345
    tecport 1555
    
  5. Begin event logging for the Tivoli receiver. You do this in one of two ways:

Logging Events to an SNMP Manager

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.

Note:
Because the SNMP environment has weak security, you should consider not granting SNMPADMIN any administrative authority. This restricts SNMPADMIN to issuing only 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 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:

  1. A TSM server on System A communicates with a subagent on system B.
  2. The subagent on System B communicates with an agent on system C, which forward traps to a Netview system.
  3. System D runs a TSM server that also uses the subagent on system B.
  4. System B also has a TSM server that uses the subagent on system B.

To run an arbitrary command from an SNMP management application, for example, NetView, follow these steps:

  1. Choose the name and parameters for a TSM script.
  2. Use the application to communicate with the SNMP agent. This agent changes the TSM MIB variable for one of the two script names that the TSM subagent maintains. The SNMP agent also sets the parameter variables for one of the two scripts.
  3. Use the application to retrieve the variable ibmAdsmReturnValue1.x or ibmAdsmReturnValue2.x, where x is the index of the server that is registered with the subagent.

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 69. IBM SNMP Configuration Screen

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. 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. 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 70 illustrates a typical TSM implementation:

Figure 70. TSM SNMP Implementation

TSM SNMP

Figure 71 shows how the communication for SNMP works in a TSM system:

Figure 71. Manager-Agent-Subagent Communication

Manager-Agent-Subagent Communication

Notes:

  1. You can start dsmsnmp and the server in any order. However, starting dsmsnmp first is more efficient in that it avoids retries.

  2. The MIB file name is adsmserv.mib.

  3. mib2adsm.tbl is for concatenating to mib2.tbl for Windows SystemView agents.

Procedure for Setting up NetView for Windows

Follow this sequence for setting up NetView for Windows:

  1. Install the Microsoft SNMP agent.
  2. Re-apply the Windows Service Pack 3.
  3. Install NetView.
  4. Disable SNMP service.
  5. Install the SystemView agent.

Configuring Tivoli Storage Manager SNMP

The Tivoli Storage Manager SNMP set up procedure is illustrated by Figure 72:

Figure 72. Tivoli Storage Manager SNMP Set Up

Tivoli Storage Manager SNMP Set Up

To set up TSM monitoring through SNMP, do the following:

  1. Modify the server options file to specify the SNMP communication method. Figure 73 displays an example of a SNMP communication method setting in the server options file. You must specify the COMMMETHOD option. For details about server options, see the server options section in Administrator's Reference.

    Figure 73. Example of SNMP Communication Method Options


    commmethod                  snmp
       snmpheartbeatinterval    5
       snmpmessagecategory      severity         
    
  2. Install, configure, and start the SNMP agent as described in the documentation for that agent. The SNMP agent must support the DPI Version 2.0 standard.

    For example, you can download the SystemView Agent for Windows 95, Windows NT, and Windows 2000 from this Web page: http://www.tivoli.com/support/sva/. Issue the snmpcfg command to display the IBM SNMP Configuration Utility screen. Online documentation is supplied with the SystemView Agent.

    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. Then run svastart.

  3. Start TSM SNMP subagent through the dsmsnmp executable.
  4. Start the TSM server to begin communication through the configured TCP/IP port with the subagent.
  5. Begin event logging for the SNMP receiver, and enable events to be reported to SNMP. For example, issue the following commands:
    begin eventlogging snmp  
    enable event snmp all                                      
    
  6. Define the TSM SNMP MIB values for the SNMP manager to help format and display the TSM SNMP MIB variables and messages. The adsmserv.mib file ships with the TSM server and must be loaded by the SNMP manager. For example, when you run NetView for OS/2(R) as an SNMP manager, the adsmserv.mib file is copied to the \netview_path\SNMP_MIB directory and then loaded through the following command:
    [C:\] loadmib -load adsmserv.mib
    

Logging Events to the Windows Event Log

The Windows event log lets you display enabled events in the Windows Application Log in the Windows Event Viewer. The information displayed includes:

For example, to enable severe and error events for logging on the Event Log, you must first issue the following command:

enable events nteventlog severe,error 

Enterprise Event Logging: Logging Events to Another Server

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 74 shows the relationship of a sending TSM server and a TSM event server.

Figure 74. Server to Server Event Logging

Event Logging Overview

The following scenario is a simple example of how enterprise event logging can work.

    The administrator at each sending server does the following:

  1. Defines the server that will be the event server. For details about communication set up, see Setting Up Communications for Enterprise Configuration and Enterprise Event Logging.
    define server server_b password=cholla hladdress=9.115.3.45 lladdress=1505  
    
  2. Identifies the server just defined as the event server:
    define eventserver server_b
    
  3. Enables the logging of severe, error, and warning server messages from the sending server and severe and error messages from all clients to the event server receiver by issuing the following commands:
    enable events eventserver severe,error,warning 
    enable events eventserver severe,error nodename=* 
    
  4. Begins event logging by issuing the following command:
    begin eventlogging eventserver  
    

    The administrator at the event server does the following:

  5. Enables the logging of severe and error messages to a file named events that are sent to it from the sending servers. The administrator defines the file with the following option in the server options file:
    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:

Querying Event Logging

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


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]