IBM Support

Maximo Asset Management Logging

Troubleshooting


Problem

The purpose of Maximo Logging is to provide customers with meaningful and easy configurable logging to resolve problems quickly without changing released code by using the open source logging API log4j.

Resolving The Problem

Overview

In Maximo, administrators can log messages from a simple configuration file and see the log messages output in various different formats. From these log files, it should be possible to figure out the process flow from the log messages to debug the problem. This document explains logging for Maximo.

Maximo incorporates logging functionality based on an open source logging API called Log4j. The Log4j API was developed by Apache Software Foundation as part of the Apache Jakarta Project. The purpose of Maximo logging functionality and its usage is to help resolve problems quickly without changing released code.

Maximo Logging Basics

Logging is performed in Maximo using a logger object. Loggers define a hierarchy and provide the run-time control to print statements or not. Loggers are named entities. Logger names are case-sensitive and they follow the hierarchical naming rule.

Specifying Log Information

Make changes in the Logging application by going to System Configuration > Platform Configuration. You must be logged in as a user with administrative privileges to modify the Logging and apply and save changes. You can change logging properties without restarting Maximo, and they will take effect immediately upon selecting Apply Settings from the Select Action Menu.

See Creating a SQL Log File to Troubleshoot Problems for details on setting up logging in Maximo.

Log Levels in Detail

A logger is said to be an ancestor of another logger if its name followed by a dot is a prefix of the descendant logger name. A logger is said to be a parent of a child logger if there are no ancestors between it and the descendant logger. Loggers are assigned levels.

A log statement is printed depending on its level and its logger. The following log levels supported for any logger are FATAL, ERROR, WARN, INFO, DEBUG.

A level of OFF can be used to turn off log messages to a specific logger.

The log levels are also inherited. If a given logger is not assigned a level, then it inherits the one from its closest ancestor with an assigned level.

The inherited level for a given logger C, is equal to the first non-null level in the logger hierarchy, starting at C and proceeding upwards in the hierarchy towards the root logger.

Appenders

An Appender is an output destination (usually a file, or sometimes a location, such as a console window) where log information can be written to. Logging requests can be sent to more than one output destination (appender, file).

Usage

FATAL - A message logged at FATAL level indicates that the error is very severe and will cause the application not to function at all. This level is used only by the Maximo application framework code to indicate that the Maximo application failed.

ERROR - A message logged at ERROR level indicates that the application would continue to run, but a specific functionality that's processed by the current thread failed and would continue to fail until the processing information is altered.

WARN - A message logged at WARN level indicates that the application would continue to run, but a specific functionality that's processed by the current thread may be operating on some data that might not be appropriate.

INFO - A message logged at INFO level indicates a general message that highlights the progress of the specific functionality that's processed by the current thread.

DEBUG - A message logged at DEBUG level indicates a general message that provides fine-grained information about the progress of the specific functionality that is being processed by the current thread.

NOTE: DEBUG is used to log messages that are useful for customers, support and development to diagnose problems in detail, but it is extremely verbose and should be used sparingly. FATAL is not used in Maximo.

Maximo loggers are organized based on Maximo functional hierarchy. Application framework code uses the following fixed loggers to output framework related messages that are common to all.

Hierarchy

A logging request is enabled if its level is equal to or higher than the logger level. Otherwise, the request is disabled. The levels are in the following order from highest to lowest:

FATAL> ERROR > WARN> INFO > DEBUG

This means that if a logger is enabled for INFO level, it would accept FATAL, ERROR, WARN level messages and discards DEBUG level messages.

Maximo Root Loggers

Logger Function
log4j.logger.maximo Root of all Maximo loggers
log4j.logger.maximo.application Root of the Maximo application specific loggers. Enable this logger to see all application logging
log4j.logger.maximo.crontask Root of all Maximo CRON task loggers. Enable this logger to see all CRON task activity
log4j.logger.maximo.datadictionary Root of all Maximo data dictionary loggers. Enable this logger to see data dictionary messages
log4j.logger.maximo.event Root of all Maximo event loggers. Enable this logger to see all Maximo events
log4j.logger.maximo.mail Root of all Maximo mail message loggers. Enable this logger to see all e-mail messages sent from Maximo
log4j.logger.maximo.service Root of all Maximo service loggers. Enable this logger to see all business object service messages
log4j.logger.maximo.sql Root of all Maximo database SQL loggers. Enable this logger to see all SQL statements
By default, all Maximo loggers are set to output only error messages, except for the Maximo root logger, in the initially-installed log configuration file. The Maximo root logger is, by default, set to output informational messages, which you normally see when the Maximo application is started. Since loggers are organized in hierarchical order, enabling a log level for a logger would automatically enable the same level for all descendant loggers, unless a descendant logger overrides the log level.
Logger Function
log4j.logger.maximo.crontaskmgr Root of cron task manager loggers
log4j.logger.maximo.report Root of all reports-related logging, including BIRT
log4j.logger.maximo.security Root of Maximo security events loggers
log4j.logger.maximo.workflow Root of Workflow events loggers
log4j.logger.maximo.integration Root of Integration Framework loggers
log4j.logger.maximo.exception Root of JMS Queue Exception event loggers
log4j.logger.maximo.dm Root of Migration Manager loggers
log4j.logger.maximo.interaction Root of Web Services Library Interaction events loggers
log4j.logger.logger.maximo.webclient.uisession Root of User Interface Session event loggers
log4j.logger.maximo.dbconnection Database Connection watchdog (DbConnectionWatchDog) logger.

For more information see Maximo and Control Desk Database Connection Leak Resolution.

log4j.logger.maximo.jms
JMS queue logger
log4j.logger.maximo.script Automation script events logger. For more information, see Log control of individual scripts.
log4j.logger.maximo.scheduler Root of Scheduler events loggers (when Scheduler is installed)
log4j.logger.maximo.scheduler.sql Root of Scheduler SQL events loggers (when Scheduler is installed)
log4j.logger.maximo.rest Root of REST API event loggers
log4j.logger.maximo.webclient.eventtracking EventTracker filter logger. Events are written to a clientevents.log
log4j.logger.maximo.trace Method entry and exit trace logger. Events are written to a trace.log
log4j.logger.maximo.script To help you identify errors in automation scripts, you can add child script loggers to the root logger for automation scripts.

See Out of the Box Maximo Loggers for a complete list.

Configuring Maximo Logging

See Enabling Logging and Appenders to Log Application Events for details on setting up logging in Maximo.

Enabling SQL Logging

To see SQL statements that executed by Maximo, set the following setting in the Logging application:

log4j.logger.maximo.sql=INFO

By default, this setting writes  all SQL statements that are executed by all business objects to system.out (SystemOut.log for WebSphere). However, setting the root SQL Logger to INFO writes a a large number of messages. Depending on how the application server has been configured to set the number and size of system.out files, the results will most likely not be helpful troubleshooting performance or execution loggers. Therefore, it should be left at ERROR unless the system administrator is advised by Maximo support to change it.

To see SQL statements that are executed by a particular business object and its related business objects, set the following setting in the Maximo log configuration file. For example, to see all WORKORDER service-related SQL statements:

log4j.logger.maximo.sql=ERROR

log4j.logger.maximo.sql.WORKORDER=INFO

Setting the log level of the new WORKORDER logger to INFO writes only SQL statements that executed by business objects of the WORKORDER service to the system.out log files.

The Logging application already contains two SQL loggers (log4j.logger.maximo.sql.WORKORDER.WOSTATUS=INFO and log4j.logger.maximo.sql.crontask.EmailNotification=INFO), as above. You can create, delete and make active or inactive by adding and deleting rows on the sql root logger.

Enable Business Object Logging

To see messages that are output by Maximo business object (mbo) code, set the following setting in the Maximo log configuration file:

log4j.logger.maximo.service=INFO

By default, this setting would output all general messages for all business objects. To see messages that are output by a particular Maximo service and its related business objects, set the following setting in the Maximo log configuration file. To see all WORKORDER service-related messages, set the service and service.WORKORDER loggers as follows:

log4j.logger.maximo.service=ERROR

log4j.logger.maximo.service.WORKORDER=INFO


Those settings would output general messages for all business objects of the WORKORDER service. To see messages that are output by a particular business object only, place the following setting in the Maximo log configuration file to see all WOSTATUS business object messages:

The Logging Application already contains several service loggers, for example,

log4j.logger.maximo.service.BIRTREPORT
log4j.logger.maximo.service.WORKORDER
log4j.logger.maximo.service.CONFIGURE
log4j.logger.maximo.service.WORKORDER.WOSTATUS

You can create, delete and make active or inactive service loggers by adding and deleting rows on the service root logger.

[{"Line of Business":{"code":"LOB59","label":"Sustainability Software"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSLKT6","label":"IBM Maximo Asset Management"},"ARM Category":[{"code":"a8m50000000CbI0AAK","label":"System-\u003ELogging"}],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions","Type":"MASTER"},{"Line of Business":{"code":"LOB59","label":"Sustainability Software"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSWT9A","label":"IBM Control Desk"},"ARM Category":[{"code":"a8m500000008b3TAAQ","label":"Miscellaneous Category (Portal, UI, Maximo, Install)"}],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions","Type":"MASTER"}]

Historical Number

M04685

Product Synonym

MAXIMO

Document Information

Modified date:
12 December 2023

UID

swg21264064