Administrator's Guide

Using Event Logging

Event logging lets you log server and client activities, called events. Events are ADSM server or client messages. You can send the events to specified receivers, which are simply destinations for the ADSM messages. You can access a receiver as you need information, and use ADSM tools or your own system management tools. You can send the events to any combination of the following receivers:

• The server console

• The ADSM activity log (for use by ADSM queries, including SQL queries)

• File and user exits (see Appendix C. "User Exit and File Exit Receivers" for information about the data structure for these exits)

• Simple Network Management Protocol (SNMP) (see "Setting Up SNMP for ADSM" for information about using this exit).

• Tivoli monitor (see "Setting Up Tivoli as an ADSM Receiver" for information about setting up a Tivoli receiver)

You can control event logging by doing the following:

• Set logging on or off by receiver.

• Enable or disable events for specific receivers. You can also specify the kinds of events to be enabled or disabled.

• Set a retention period for the log records by using the SET ACTLOGRETENTION command.

At server start-up event logging begins automatically to the console and the activity log and for any receivers that are started based on entries in the server options file. You can issue the BEGIN EVENTLOGGING and END EVENTLOGGING commands to begin and end logging for one or more receivers. For example, to begin event logging for a user-defined exit, issue the following command:

begin eventlogging userexit

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:

• A message number or an event severity

• Events for one or more client nodes

Notes:

1. Certain events, such as messages issued during server start-up and shutdown, automatically go to the console but cannot be enabled for any other receivers.

2. Messages in the SEVERE category and message ANR9999 can provide valuable diagnostic information if there is a serious ADSM problem. For this reason, you should not disable these messages.

3. In response to administrative commands, ADSM sends messages to the issuing console. You cannot disable these messages for that console. In addition, some events, such as server start-up and shutdown messages, cannot be disabled for the console.

4. Server messages cannot be disabled for the activity log.

Here are two examples of enabling events:

• Enable event logging to a user exit for server messages with a severity of ERROR or SEVERE:

  enable events userexit error,severe 
  

  The name of the user exit must be specified in the USEREXIT server option.

• Enable event logging to a file for client ERROR messages for three nodes: MSMITH, HSTANFORD, and BKELLY:

  enable events file error nodename=msmith,hstanford,bkelly
  

  The name of the file must be specified in the FILEEXIT server option.

The QUERY ENABLED command displays the events that are enabled and disabled by a specific receiver for the server or for a client node. Because the lists of enabled and disabled events could be very long, ADSM displays the shorter of the two lists. For example, assume that 1000 events were enabled by the user exit for client node HSTANFORD and that later two were disabled. To query the enabled events for HSTANFORD, enter:

query enabled userexit nodename=hstanford

The output would specify the number of events enabled and the message names for the 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

Setting Up Tivoli as an ADSM Receiver

This section describes what you must do to set up Tivoli as a receiver for ADSM event logging.

The file ibmadsm.baroc, which is distributed with the server, defines the ADSM event classes to the Tivoli enterprise console. Before ADSM events are displayed on a Tivoli console, you must import ibmadsm.baroc into an existing rule base or create a new rule base and activate it using this file.

To import ibmadsm.baroc into an existing rule base, do the following:

1. From the TME desktop, click on the RuleBase icon to display the pop-up menu and select Import and specify the location of the ibmadsm.baroc file.

2. Select the Compile pop-up menu.

3. Select the Load pop-up menu and Load, but activate only when server restarts from the resulting dialog.

4. Shut down the event server and restart it.

To create a new rule base, do the following:

1. From the TME desktop, open the Event Server Rules Bases window, by double-clicking on the EventServer icon.

2. Select the Create->RuleBase 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 and select Import and specify the location of the ibmadsm.baroc file.

5. Select the Compile pop-up menu.

6. Select the Load pop-up menu and Load, but activate only when server restarts from the resulting dialog.

7. Shut down the event server and restart it.

After you have added ibmadsm.baroc to a rule base and activated the rule base, define an event source and an event group:

1. From the TME desktop, select Source from the EventServer pop-up menu. From the resulting dialog, define a new source whose name is ADSM.

2. From the TME desktop, select Event Groups from the EventServer pop-up menu. From the resulting dialog, define a new event group for ADSM and a filter that includes event classes IBMADSMSERVER_EVENT and IBMADSMCLIENT_EVENT.

3. From the event console icon, select the Assign Event Group pop-up menu item and assign the new event group to the event console.

4. Double-click on the event console icon to start the configured event console.

To complete your set up, you must also specify the location of the host on which the Tivoli server is running. To do this, specify the TECHOSTNAME server option and, optionally, the TECPORT and TECBEGINEVENTLOGGING server options. For details about these server options, see ADSM Administrator's Reference.

Setting Up SNMP for ADSM

You can use the simple network management protocol (SNMP) together with ADSM event logging to send traps to an SNMP manager, such as NetView or Tivoli. In addition, you can set up an SNMP heartbeat monitor to regularly check that the ADSM server is running.

An SNMP agent is needed for communication between an SNMP manager and its managed systems. The SNMP agent is implemented through the snmpd daemon, and the Distributed Protocol Interface (DPI) Version 2 is an extension of this SNMP agent.

ADSM 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 ADSM subagent. This SNMP agent is not included with ADSM. The ADSM subagent is included with ADSM 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 ADSM 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 ADSM server system runs the processes needed to send ADSM event information to an SNMP management system. The processes are:

• SNMP agent (snmpd)

• ADSM SNMP subagent (dsmsnmp)

• ADSM server (dsmserv)

Cross-system support for communication between the server and subagent is not supported, and these products must be installed and run on the ADSM server system. Figure 53 illustrates a typical ADSM implementation:

Figure 53. ADSM SNMP Implementation

Figure 54 shows how the communication for SNMP implemented in an ADSM system:

• The SNMP manager and agent communicate with each other through the SNMP protocol. The SNMP manager passes all requests for variables to the agent.

• The agent then passes the request to the subagent and sends the answer back to the manager. The agent responds to the manager's requests and informs the manager about events by sending traps.

• The agent communicates with both the manager and subagent. It sends queries to the subagent and receives traps that inform the SNMP manager about events taking place on the application monitored through the subagent. The SNMP agent and subagent communicate through the Distributed Protocol Interface (DPI). Communication takes place over a stream connection, which typically is a TCP connection but could be another stream-oriented transport mechanism.

• The subagent answers MIB queries of the agent and informs the agent about events by sending traps. The subagent can also create and delete objects or subtrees in the agent's MIB. This allows the subagent to define to the agent all the information needed to monitor the managed application.

Figure 54. Manager-Agent-Subagent Communication

Configuring ADSM SNMP

The ADSM SNMP set up procedure is illustrated by Figure 55:

Figure 55. ADSM SNMP Set Up

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

1. Modify server options file, dsmserv.opt, to specify the SNMP communication method. Figure 56 displays an example of a SNMP communication method setting in the ADSM server options file dsmserv.opt. For details about the other options, see ADSM Administrator's Reference.

   Figure 56. 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, 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                         
    
   

   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.

   If 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"
   

3. Start ADSM SNMP subagent through the dsmsnmp executable.

4. Start the ADSM server to begin communication through the configured TCP/IP port with the subagent.

5. Begin event logging for the SNMP receiver and enable individual events or event severities to be reported to SNMP. For example, issue the following commands:

   begin eventlogging snmp  
   enable event snmp all                                      
   

6. Define the ADSM SNMP MIB values for the SNMP manager to help format and display the ADSM SNMP MIB variables and messages. The ADSMSERV.MIB file ships with the ADSM server and must be loaded by the SNMP manager. For example, when you run NetView for OS/2 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