Common Log

The Common Log sub-tab displays messages pertaining to various aspects of SBM runtime operations, including the execution of application workflows. However, common log messages are most useful for diagnosing and debugging orchestration workflow problems.

On the Common Log sub-tab, you can:

• Create, edit, and delete custom filters that limit the number of messages in the log. You can search messages by the user who logged the entry, application name or orchestration name, date/time, level, or entry content. For more information, see Working with Logs.
  Note: Filtering the common log by orchestration name is an effective way to limit results for process apps that were deployed from SBM Composer. However, if the process app was deployed from Application Repository, filtering by orchestration name does not provide correct results because some assets in the orchestration are only created during deploy from SBM Composer.
• Open the Settings dialog box, where you can control logging levels for messages in the log. This option is enabled only if you have the necessary administration privileges. For details, see Logging Levels.
• Click Clear History to clear all the messages in the log. You can delete all events, or events prior to a specific date. You can also schedule recurring clear history operations. Note that this option is enabled only for global administrators.

  Select the Cancel any scheduled activities for all environments option to cancel scheduled clear history operations for all of your environments.

• Click the refresh icon to update the list with the latest entries.

There are two logging types for messages that appear in the Common Log:

• User: User messages (also known as "key" messages) provide diagnostic information that pertains to the high-level, logical execution of a process app, particularly orchestration workflows. These messages can be used to debug the logic of orchestration workflows because they are generated at key points in their execution and capture relevant information. They can be of any logging level (see below).
• Technical: Technical messages provide both high-level and internal implementation information.

Logging Levels

Click the Settings button to select a logging level that determines the verbosity, or volume of messages that will be logged.

Select an application or orchestration, and then select a logging level from the Level drop-down list. You can also select a logging level, and then click Apply to all to use the selected logging level with every application and orchestration.

The following logging levels are available:

• user: Logs user-type messages, regardless of their technical level. This setting also logs "error" and "fatal" messages, regardless of whether they are marked as user-type messages.
• trace: Detailed information about the execution of the program (for example, which function was called).
• debug: Useful information about the execution of the program (for example, the data contained in the request).
• info: The program reached a certain point in its execution (for example, the request was received).
• warning: Some unexpected or abnormal condition occurred that does not affect the logic of the program, but may indicate a general problem (for example, the request is taking a long time to complete).
• error: Some unexpected or abnormal condition occurred that affects the logic of the program (for example, an out-of-range value or an expected resource that was not present). This is the default logging level.
• fatal: A serious problem occurred from which the program may not recover (for example, an out-of-memory condition).
• off: Stops all messages from being logged to the Common Log.

The technical log entry is an attribute attached to the log message at its origination. It indicates the purpose of the log message and allows log messages to be filtered, reducing the volume of log messages that are captured while still capturing useful information.

The highest volume of messages are logged with the trace level; the lowest volume of messages are logged with the fatal level. If any technical logging level is selected, the system logs both user-type and technical-type messages to that level. For example, if you select warn, then user-type messages containing debug information will not be logged.

Logging Tips and Best Practices

The following list provides recommendations for using the Common Log.

• It is generally not a good idea to set a technical level higher than warn in a production environment, because system performance can be adversely affected by a large volume of log messages. If you need to collect more information, consider the user setting; this will limit the number of messages while still tracking the execution of the program. If this is not sufficient, and you need to set a higher technical level, be sure to restore the setting to warn or below after you obtain the information you need.
• If you have multiple environments, each environment must have its own Common Log database. This ensures that Common Log messages you see are specific to each environment. See the SBM Installation and Configuration Guide for information about configuring databases.
• The trace level is normally only useful to Support personnel.
• Log messages accumulate in the database until they are cleared, so it is important to keep them at a manageable level, especially if you combine the logging database with other SBM databases, such as the Orchestration Engine database. It is recommended that you clear the log messages you no longer need as soon as it is practical. Technical level log messages can accumulate very quickly if your process apps use orchestration workflows, so they need to be cleared even more frequently. If you encounter a server time out after applying a filter to the log, consider clearing unnecessary data from the Common Log first.
• If necessary, you can use the -clearEventLog and -clearCommonLog renew utility commands to purge the common log and event log in the event they have grown large enough in size that timeouts occur during the purge operation in Application Repository or SBM Composer. For more information, refer to the renew topics in the SBM Orchestration Guide.