Core: System Administrator's Guide

Overview
Core Quick Start
Configuring OGSA extensions
>Configuring the Logging Service

Configuring the Logging Service

Logging in the Globus Toolkit is based on the Jakarta Commons Logging architecture. Commons Logging provides a consistent interface for instrumenting source code while at the same time allowing the user to plug-in a different logging implementation. The Globus Toolkit implements the Commons Logging interface and provides the logging implementation.

In addition the Globus Toolkit provides a logging Grid Service with the following features:

  • Dynamically change the runtime logging characteristics of both the hosting environment and the services running in it.
  • Change the persistent logging configuration.
  • Query or subscribe to a rolling window of the log entries as service data.
  • Query transient and persistent attributes as service data.
  • Access to and management of logging as a Grid Service.

Logging Configuration

Basic logging is automatically configured and enabled during installation. No additional configuration is needed to enable logging. This section is provided so that administrators can change the logging configuration if needed.

This section describes only the static configuration of logging. The OgsiLogging service can be used to dynamically change the logging configuration and options at runtime. This can done using the service interface from a Grid Service client application. A panel is provided as part of the ServiceBrowser as an exmaple. For details see the logging service detailed specification.

The following files are used to configure logging:

  • commons-logging.properties
  • ogsilogging_parms.properties
  • ogsilogging.properties

commons-logging.properties

This file is used by Jakarta Commons to find the LogFactory to use when creating Loggers. It must be in the classpath. This is the entire content: org.apache.commons.logging.LogFactory=org.globus.ogsa.impl.core.logging.OGSALogFactory If the commons-logging.properties file is not found, and assuming a factory was not specified in the system properties, the behavior of commons LogFactory is to dynamically discover built-in supported loggers. If the log4j-core.jar file is found in the classpath, log4j will be used. See the commons Logging LogFactory javadoc for details regarding LogFactory implementation lookup.

ogsilogging_parm.properties

This file contains 2 parameters:

1. persistentAttributeLocation contains the name of the file which contains the detailed logging configuration. It can be fully qualified or relative to the current directory. In this example the file is located in the current directory. persistentAttributeLocation=ogsilogging.properties

2. logDestinationBasePath contains the base path of log files for any logger with a file desination. The default setting is blank, which means the current working directory. In the default Globus Toolkit container, this defaults to the <ogsa root>/impl/java/ directory. logDestinationBasePath=

ogsilogging.properties

This file contains the detailed logging settings for a Globus Toolkit installation.

There is one and only one default setting, which has the following format: default=destination,level,group The "default" entry provides logging settings for any logger that is not explicitly defined elsewhere in the ogsilogging.properties file.

In addition to the default entry, there are configuration entries for individual loggers. Individual Logger entries have the following format: logger_name=destination,level,group

Logger name
logger_name is a string that matches what the log generating application used to define it's logging entries. It is typically the class name of the application generating the log information, but it can be any name that binds a set of contributors to an identified log stream.

Level
The level is the key log-filtering item. There are two views of level: the application view, and the administrative view. From the standpoint of the log generating application, it selects one of the following levels indicating the log message priority:

  • DEBUG
  • TRACE
  • INFO
  • WARN
  • ERROR
  • FATAL

From the administrative view, the level attribute contained in this file is used for the hierarchical filtering of log message flows. Valid level attributes, in hierarchical order are:

  • ALL or DEBUG
  • TRACE
  • INFO
  • WARN
  • ERROR
  • FATAL
  • OFF

The administrator will set a level associated with a logger name from one of the above. The selection of a particular level enables all log filters below it. For example, setting level to ALL or DEBUG causes all messages to be logged. Setting the level to TRACE also causes INFO, WARN, ERROR, FATAL level messages to be logged. Setting level to INFO causes WARN, ERROR, FATAL level messages to be logged, and so on.

Setting level to "OFF" disables all log messages for this logger.

Destination
The destination field is either "CONSOLE" or filename. The filename is relative and will be pre-pended by the logDestinationBasePath.

Group
This is an unmanaged tag, which can be used in group wide operations. An attribute can only belong to one group. Group is useful when programmatically changing the logging settings for a group of loggers.

Configuring The Logging Service

The OgsiLogging Grid Service is defined in the server-config.wsdd. Following are the configurable parameters:

logBufferSize defines the number of entries in the log messages buffer. The log message buffer is a rolling (FIFO) list of the latest log messages.

logBufferSizeMax defines the maximum size of any change in log buffer size.

Underlying Log Engine

Ogsi Logging uses Log4j in it's implementation. The log4j-core.jar file should be in the classpath.

Any application using log4j directly instead of using commons APIs will NOT be supported from a logging management standpoint. Any discovered log4j.properties file will be in effect for direct users. Commons users will have OGSI Logging Management prevail and existing log4j.properties files will have no effect. For example, if a category logger is defined in log4j as DEBUG but is defaulted by an ogsilogging.properties as WARN, then WARN is the designated log level.

Logging in Tomcat

The deployTomcat target takes care of all the required logging setup in the Tomcat application server environment.

Tracing SOAP messages

Three methods for tracing SOAP messages are described.

1. To trace SOAP messages on the wire you can use TcpMon from Apache Axis. After setting the environment using setenv scripts you can run: java org.apache.axis.utils.tcpmon [listenPort targetHost targetPort]

If no arguments are used, you have to fill out these values in the GUI.

2. One method for logging SOAP messages is to add the org.globus.ogsa.handlers.MessageLoggingHandler to the request or response chain in the server-config.wsdd or client-config.wsdd files. For example: 

<requestFlow> ... <handler type="java:org.globus.ogsa.handlers.MessageLoggingHandler"/> ... <requestFlow>

3. Another method for tracing SOAP messages is to enable logging for selected Axis classes. Add the following lines to the ogsilogging.properties file: org.apache.client.Call=console,debug org.apache.axis.transport.http.HTTPSender=console,debug This will cause axis client side calls and Axis HTTP messages to be logged.