12 Managing Log Files and Diagnostic Data
This chapter describes how to find information about the cause of an error and its corrective action and to view and manage log files to assist in monitoring system activity and in diagnosing problems.
- Overview of Oracle Fusion Middleware Logging
By default, Oracle WebLogic Server is configured to use the common log format for HTTP access logs. Most other Oracle Fusion Middleware components write diagnostic log files in the Oracle Diagnostic Logging (ODL) format. - About ODL Messages and ODL Log Files
Using ODL, diagnostic messages are written to log files and each message includes information, such as the time, component ID, and user, written in a specific format. - Viewing and Searching Log Files
You can view, list, and search log files across Oracle Fusion Middleware components. You can view and search log files using Fusion Middleware Control or you can download a log file to your local client and view the log files using another tool. You can also list, view, and search log files using the WLST command-line tool. - Configuring Settings for Log Files
You can change the location of log files, how often the log files rotate, and the level of information written to them, along with other configuration settings. You can change the log settings of Managed Servers and Java components using Fusion Middleware Control or WLST. - About Correlating Messages Across Log Files and Components
Oracle Fusion Middleware components provide message correlation information for diagnostic messages. Message correlation information helps those viewing diagnostic messages to determine relationships between messages across components. - Configuring Tracing
Sometimes you need more information to troubleshoot a problem than is usually recorded in the logs. One way to achieve that is to increase the level of messages logged by one or more components, and fine-tune which messages are written to the log files.
Parent topic: Monitoring Oracle Fusion Middleware
Overview of Oracle Fusion Middleware Logging
By default, Oracle WebLogic Server is configured to use the common log format for HTTP access logs. Most other Oracle Fusion Middleware components write diagnostic log files in the Oracle Diagnostic Logging (ODL) format.
The following topics describe HTTP access logging and diagnostic logging.
- About Oracle Fusion Middleware HTTP Access Logging
- About Oracle Fusion Middleware Diagnostic Logging
Parent topic: Managing Log Files and Diagnostic Data
About Oracle Fusion Middleware HTTP Access Logging
By default, Oracle WebLogic Server is configured to use the common log format for HTTP access logs. Oracle WebLogic Server also supports the extended log format, an emerging standard defined by the draft specification from the World Wide Web Consortium (W3C).
When you install Oracle WebLogic Server with Oracle JRF, it uses the extended log format for HTTP access logs by default. The extended log format allows you to specify the type and order of information recorded about each HTTP communication.
Oracle Fusion Middleware supports the following field identifiers:
-
date: The date at which transaction completed. The field has the format YYYY-MM-DD. All dates are specified in GMT.
-
time: The time at which transaction completed. The field has the format HH:MM, HH:MM:SS or HH:MM:SS.S where HH is the hour in 24-hour format, MM is minutes, and SS is seconds. All times are specified in GMT.
-
cs-method: The request method, for example GET or POST. This field has type <name>, as defined in the W3C specification.
-
cs-url: The full requested URI. This field has type <uri>, as defined in the W3C specification.
-
ctx-ecid: The Execution Context ID (ECID). The ECID is a globally unique identifier associated with the execution of a particular request.
-
ctx-rid: The Relationship ID (RID). The RID distinguishes the work done in one thread on one process, from work done by any other threads on this and other processes on behalf of the same request.
-
sc-status: The status code of the response, for example (404) indicating a "File not found" status. This field has type <integer>, as defined in the W3C specification.
For information about the extended log format fields, see:
http://www.w3.org/TR/WD-logfile.html
Parent topic: Overview of Oracle Fusion Middleware Logging
About Oracle Fusion Middleware Diagnostic Logging
Most Oracle Fusion Middleware components write diagnostic log files in the Oracle Diagnostic Logging (ODL) format. Log file naming and the format of the contents of log files conforms to an Oracle standard. By default, the diagnostic messages are written in text format.
ODL provides the following benefits:
-
The capability to limit the total amount of diagnostic information saved. You can set the level of information saved and you can specify the maximum size of the log file and the log file directory.
-
When you reach the specified size, older segment files are removed and newer segment files are saved in chronological fashion.
-
Components can remain active, and do not need to be shutdown, when older diagnostic logging files are deleted.
You can view log files using Fusion Middleware
Control or the WLST displayLogs
command, or you can download log files to your local client and view them using another tool (for example, a text editor or another file viewing utility).
Note:
Oracle WebLogic Server does not use the ODL format. For information about the Oracle WebLogic Server log format, see Log Message Format in Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server.
Parent topic: Overview of Oracle Fusion Middleware Logging
About ODL Messages and ODL Log Files
Using ODL, diagnostic messages are written to log files and each message includes information, such as the time, component ID, and user, written in a specific format.
The following example shows an ODL format error messages from Oracle HTTP Server:
[2017-03-13T12:31:29.0584-07:00] [OHS] [NOTIFICATION:16] [OHS-9999]
[mod_weblogic.c] [host_id: example] [host_addr: nn.nnn.nn.nn] [pid: 12789]
[tid: 46919953675776] [user: username VirtualHost: main
WebLogic Server Plugin version 12.1.2 <WLSPLUGINS_MAIN_LINUX.X64_130502.1731>
In the message, the fields map to the following attributes, which are described in Table 12-1:
-
Timestamp, originating:
2017-03-13T12:31:29.0584-07:00
-
Organization ID:
OHS
-
Message Type:
NOTIFICATION:16
-
Component ID:
mod_weblogic.c
-
Host ID:
host_id: example
-
Host Address:
host_addr: nn.nnn.nn.nn
-
Process ID:
pid: 12789
-
Thread ID:
tid: 46919953675776
-
User ID:
userId: username
-
Virtual Host:
VirtualHost: main
-
Message Text:
"WebLogic Server Plugin version 12.1.2 <WLSPLUGINS_MAIN_LINUX.X64_130502.1731>"
By default, the information is written to the log files in ODL text format. You can change the format to ODL XML format, as described in Specifying the Log File Format.
Table 12-1 describes the contents of an ODL message. For any given component, the optional attributes may not be present in the generated diagnostic messages.
Table 12-1 ODL Format Message Fields
Attribute Name | Description | Required |
---|---|---|
Timestamp, Originating (TIME) |
The date and time when the message was generated. This reflects the local time zone. |
Yes |
Timestamp, normalized (time_norm) |
The timestamp normalized for clock drift across hosts. This field is used when the diagnostic message is copied to a repository on a different host. |
No |
Organization ID (org_id) |
The organization ID for the originating component. |
No |
INSTANCE_ID (INST_ID) |
The name of the instance to which the component that originated the message belongs. |
No |
COMPONENT ID (COMP_ID) |
The ID of the component that originated the message. |
Yes |
MESSAGE_ID (MSG_ID) |
The ID that uniquely identifies the message within the component. The ID consists of a prefix that represents the component, followed by a dash, then a 5-digit number. For example: OHS-51009 |
Yes |
MESSAGE_TYPE (MSG_TYPE) |
The type of message. Possible values are: INCIDENT_ERROR, ERROR, WARNING, NOTIFICATION, TRACE, and UNKNOWN. See Table 12-3 for information about the message types. |
Yes |
MESSAGE_LEVEL (MSG_LEVEL) |
The message level, represented by an integer value that qualifies the message type. Possible values are from 1 (highest severity) through 32 (lowest severity). See Table 12-3 for information about the message levels. |
Yes |
HOST_ID (HOST_ID) |
The name of the host where the message originated. |
No |
HOST_NW_ADDR (HOST_ADDR) |
The network address of the host where the message originated. |
No |
MODULE_ID (MODULE) |
The ID of the module that originated the message. If the component is a single module, the component ID is listed for this attribute. |
Yes |
PROCESS_ID (PID) |
The process ID for the process or execution unit associated with the message. |
No |
THREAD_ID (TID) |
The ID of the thread that generated the message. |
No |
USER_ID (USER) |
The name of the user whose execution context generated the message. |
No |
ECID |
The Execution Context ID (ECID), which is a global unique identifier of the execution of a particular request in which the originating component participates. You can use the ECID to correlate error messages from different components. See About Correlating Messages Across Log Files and Components for information about ECIDs. |
Yes |
RID |
The relationship ID (RID), which distinguishes the work done in one thread on one process, from work done by any other threads on this and other processes, on behalf of the same request. See About Correlating Messages Across Log Files and Components for information about RIDs. |
No |
SUPPL_ATTRS |
An additional list of name/value pairs which contain component-specific attributes about the event. Oracle Fusion Middleware provides the supplemental attribute DSID (Diagnostic Session ID). DSID is an ID for a user session and is used to map a set of log messages, incidents, and other diagnostic data to a user session. For example, you can see if a specific incident generated in a user session may have been proceeded by earlier incidents in the same session, and could therefore be the root cause of the subsequent incident. |
No |
MESSAGE TEXT (TEXT) |
The text of the message. |
Yes |
Message Arguments (arg) |
A list of arguments bound with the message text. |
No |
Supplemental Detail |
Supplemental information about the event, including more detailed information than the message text. |
No |
The log file location depends on the type of component:
-
For most Java components, the log file location is:
(UNIX) DOMAIN_HOME/servers/server_name/logs (Windows) DOMAIN_HOME\servers\server_name\logs
The default name of a log file is server-name-diagnostic.log.
-
For system components, the default log file location is:
(UNIX) DOMAIN_HOME/servers/component_name/logs (Windows) DOMAIN_HOME\servers\component_name\logs
Table 12-2 shows the log file location for components of Oracle Fusion Middleware.
Table 12-2 Log File Location for Oracle Fusion Middleware Components
Component | Log File Location |
---|---|
Fusion Middleware Control |
DOMAIN_HOME/sysman/log/emoms.log DOMAIN_HOME/sysman/log/emoms.trc |
Oracle Application Development Framework |
DOMAIN_HOME/servers/server_name/logs/server-name-diagnostic.log |
Oracle BI Enterprise Edition |
DOMAIN_HOME/servers/server_name/logs/server-name-diagnostic.log DOMAIN_HOME/servers/instance_key/logs/server-name-diagnostic.log |
Oracle Enterprise Scheduler |
DOMAIN_HOME/servers/server_name/logs/server-name-diagnostic.log |
Oracle Event Processing |
DOMAIN_HOME/servers/server_name/logs/server-name-diagnostic.log |
Oracle Forms Services |
DOMAIN_HOME/servers/server_name/logs/application_name.log |
Oracle HTTP Server |
DOMAIN_HOME/servers/component_name/logs/*.log |
Oracle Managed File Transfer |
DOMAIN_HOME/servers/server_name/logs/server-name-diagnostic.log |
Oracle Platform Security Services |
DOMAIN_HOME/servers/server_name/logs/server-name-diagnostic.log |
Oracle Service Bus |
DOMAIN_HOME/servers/server_name/logs/server-name-diagnostic.log |
Oracle TopLink |
DOMAIN_HOME/servers/server_name/logs/server-name-diagnostic.log |
Oracle Web Services Manager |
DOMAIN_HOME/servers/server_name/logs/owsm/msglogging DOMAIN_HOME/servers/server_name/logs/owsm-diagnostic.log |
Oracle WebLogic Server |
DOMAIN_HOME/servers/server_name/logs/server-name-diagnostic.log |
Oracle WebCenter Content |
DOMAIN_HOME/servers/server_name/logs/server-name-diagnostic.log |
Oracle WebCenter Portal |
DOMAIN_HOME/servers/server_name/logs/server-name-diagnostic.log |
Oracle WebCenter Sites |
DOMAIN_HOME/servers/server_name/logs/server-name-diagnostic.log DOMAIN_HOME/servers/server_name/logs/sites_server-name.log000n DOMAIN_HOME/servers/server_name/logs/cas_server-name.log000n |
Repository Creation Utility |
By default, writes to file specified in RCU_LOG_LOCATION. If not specified, attempts to write to the following locations:
|
Parent topic: Managing Log Files and Diagnostic Data
Viewing and Searching Log Files
You can view, list, and search log files across Oracle Fusion Middleware components. You can view and search log files using Fusion Middleware Control or you can download a log file to your local client and view the log files using another tool. You can also list, view, and search log files using the WLST command-line tool.
Note the following about using the WLST commands to view the log files:
-
The log viewing commands work whether you are connected or not connected to a WebLogic server. If you are not connected, you must specify the path in the oracleInstance parameter, passing it the path to the domain home.
-
Most of the WLST logging commands require that you are running in the domainRuntime tree. For example, to connect and to run in the domainRuntime tree, use the following WLST commands:
connect('username', 'password', 'localhost:port_number') domainRuntime()
For more information about the commands, see Logging Custom WLST Commands in the WLST Command Reference for Infrastructure Components.
Parent topic: Managing Log Files and Diagnostic Data
Viewing Log Files and Their Messages
You can view the log files using Fusion Middleware Control or WLST commands, as described in the following topics:
- Viewing Log Files and Their Messages Using Fusion Middleware Control
- Viewing Log Files and Their Messages Using WLST
Parent topic: Viewing and Searching Log Files
Viewing Log Files and Their Messages Using Fusion Middleware Control
You can view the messages for all of the entities in a domain, an Oracle WebLogic Server, a component, or an application.
For example, to view the log files and their messages for a Managed Server:
Parent topic: Viewing Log Files and Their Messages
Viewing Log Files and Their Messages Using WLST
You can list the log files for an Oracle WebLogic Server domain, a server, or component using the WLST listLogs
command.
You can use this command while connected or disconnected. While connected, the default target is the Oracle WebLogic Server domain.
To list the log files, first use the domainRuntime
command as described in Viewing and Searching Log Files. The following describes how to list and view log files:
-
To list all of the log files for the Oracle WebLogic Server wls_server_1, use the following command:
listLogs(target='wls_server_1') file://hostname/scratch/oracle1/Oracle/domains/base_domain/servers/wls_server_1/logs/wls_server_1.log 2017-03-21 06:55:37 500.1K wls_server_1.log00026 2017-03-21 07:49:08 500.1K wls_server_1.log00027 2017-03-21 08:46:29 500.4K wls_server_1.log00028 2017-03-21 09:45:29 500.4K wls_server_1.log00029 2017-03-21 10:43:00 500.3K wls_server_1.log00030 2017-03-21 11:39:56 500.3K wls_server_1.log00031 2017-03-21 12:38:56 500.4K wls_server_1.log00032 2017-03-21 13:18:06 358.1K wls_server_1.log file://hostname/scratch/oracle1/Oracle/domains/base_domain/servers/wls_server_1/logs/wls_server_1.out 2017-03-13 11:00:05 4M wls_server_1.out00001 2017-03-21 13:18:06 12.1M wls_server_1.out ...
-
To list the logs for a system component, use one of the following formats:
listLogs(target='
component_name
') listLogs(target='sc:component_name
')For example, to list the logs for the Oracle HTTP Server ohs1, use the following command:
listLogs(target='ohs1')
-
To list the logs while disconnected, you must specify the
oracleInstance
parameter, passing it the path of the domain. For example, to list the log files for the Managed Server wls_server_1:listLogs(oracleInstance='/scratch/Oracle/config/domains/WLS_domain', target='wls_server_1')
-
To view the diagnostic messages in log files, use the WLST
displayLogs
command. This command works when you are either connected or disconnected.For example, to view the messages generated in the last 10 minutes in the log files for the Oracle WebLogic Server domain, use the following command:
displayLogs(last=10) [2017-03-21T13:30:11.892-07:00] [wls_server_1] [WARNING] [WSM-09004] [oracle.wsm.resources.common] [host: hostname [nwaddr: 10.240.82.231] [tid: [ACTIVE].ExecuteThread: '5' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: OracleSystemUser] [ecid: 66217af9-247f-4344-94a9-14f90e75a586-00070b85,0] [APP: wsm-pm] [TARGET: /base_domain/wls_server_1/wsm-pm] [LOG_FILE: /scratch/oracle1/Oracle/domains/base_domain/servers/wls_server_1/logs/wls_server_1-diagnostic.log] Component auditing cannot be initialized. [2017-03-21T13:30:11.895-07:00] [wls_server_1] [NOTIFICATION] [BEA-010227] [EJB] [host: hostname] [nwaddr: 10.240.82.231] [tid: [ACTIVE].ExecuteThread: '5' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: OracleSystemUser] [ecid: 66217af9-247f-4344-94a9-14f90e75a586-00070b85,0] [TXN_ID: BEA1-7438ECB7CDFCAF163A9A] [TARGET: /base_domain/wls_server_1] [LOG_FILE: /scratch/oracle1/Oracle/domains/base_domain/servers/wls_server_1/logs/wls_server_1.log] EJB exception occurred during invocation from home or business: weblogic.ejb.container.internal.StatelessEJBHomeImpl@314c2224 generated exception: java.lang.reflect.UndeclaredThrowableException
The previous command returns the messages sorted by time, in ascending order.
-
To display the logs for a system component, use one of the following formats:
listLogs(target='
component_name
') listLogs(target='sc:component_name
')For example, to display the log files for the Oracle HTTP Server ohs_1, use the following command:
displayLogs(target='sc:ohs_1')
You can search the messages by specifying particular criteria and sort the output, as described in Searching Log Files.
See Logging Custom WLST Commands in the WLST Command Reference for Infrastructure
Components for more information about the listLogs
and displayLogs
commands.
Parent topic: Viewing Log Files and Their Messages
Searching Log Files
You can search for diagnostic messages by time, type of message, and certain log file attributes by using Fusion Middleware Control or WLST commands, as described in the following topics:
Parent topic: Viewing and Searching Log Files
Searching Log Files Using Fusion Middleware Control
You can search for diagnostic messages using standard and supplemental ODL attributes using the Log Messages page of Fusion Middleware Control. By default, this page shows a summary of the logged issues for the last hour.
You can modify the search criteria to identify messages of relevance. You can view the search results in different modes, allowing ease of navigation through large amounts of data.
The following topics describe how to search log files:
Parent topic: Searching Log Files
Searching Log Files: Basic Searches
This section describes how to perform basic searches for log messages.
You can search for all of the messages for all of the entities in a domain, an Oracle WebLogic Server, a component, or an application.
For example, to search for messages for a domain:
Parent topic: Searching Log Files Using Fusion Middleware Control
Searching Log Files: Advanced Searches
You can refine your search criteria by clicking the Search icon and using the following additional controls:
-
Message: Select an operator, such as contains and then enter a value to be matched.
-
Add Fields: Click this to specify additional criteria, such as Host, which lets you narrow the search to particular hosts. Then click Add.
For each field you add, select an operator, such as contains and then enter a value to be matched.
Parent topic: Searching Log Files Using Fusion Middleware Control
Searching Log Files Using WLST
You can search the log files using the WLST displayLogs
command. You can narrow your search by specifying criteria, such as time, component ID, message type, or ECID. For example:
-
To search for error messages generated in the last 5 minutes, for a system component such as the Oracle HTTP Server ohs1, use the following command:
displayLogs(target='sc:ohs1', last=5)
-
To search for error messages generated in the last 10 minutes for the Managed Server wls_server_1, use the following command:
displayLogs(oracleInstance='/scratch/Oracle/config/domains/WLS_domain', target='wls_server_1', last=10)
You can narrow your search by using the query
parameter and specifying criteria, such as component ID, message type, or ECID. In the query
clause, you can specify a query expression with any of the attributes listed in Table 12-1. Some of the criteria you can use are:
-
Types of messages. For example, to search for ERROR and INCIDENT_ERROR messages for the Managed Server wls_server_1, use the following command:
displayLogs(oracleInstance='/scratch/Oracle/config/domains/wls_domain', target='wls_server_1', query='MSG_TYPE eq ERROR or MSG_TYPE eq INCIDENT_ERROR')
-
A particular ECID. For example, to search for error messages with a particular ECID (0000I3K7DCnAhKB5JZ4Eyf19wAgN000001,0') for the Managed Server wls_server_1, use the following command:
displayLogs(oracleInstance='/scratch/Oracle/config/domains/wls_domain', target='wls_server_1', query='ecid eq 0000I3K7DCnAhKB5JZ4Eyf19wAgN000001,0')
-
Component type. For example, to search for messages from Oracle HTTP Server instances, use the following query:
displayLogs(query='COMPONENT_ID eq ohs')
-
Range of time. To search for error messages that occurred within a specified range of time, you specify the attribute TSTZ_ORIGINATING with both
from
andto
operators, using the following format:displayLogs(query='TSTZ_ORIGINATING from start_time and TSTZ_ORIGINATING to end_time')
You specify the date using the following ISO 8601 time format:
YYYY-MM-DDThh:mm:ss-hh:mm_offset_from_UTC
For example:
2017-03-30T12:00:00:0000-08:00
For example, to display the error message from between 8:00 a.m. and 11 a.m. on March 17, 2017, use the following command:
displayLogs(query='TSTZ_ORIGINATING from 2017-03-17T08:00:00-07:00 and TSTZ_ORIGINATING to 2017-03-17T11:00:00-07:00')
-
Group messages. To display a count of messages, grouped by specific attributes, use the
groupBy
parameter to the WLST commanddisplayLogs
. For example, to display the count of WARNING messages by component, use the following command:displayLogs(groupBy=['COMPONENT_ID'], query='MSG_TYPE eq WARNING')
-
Group messages by supplemental attributes. If you use the DMS event tracing commands, you can create a destination that enables you to query and group messages by specific supplemental attributes. In this case, you use the addDMSEventDestination command to create a destination with the property writeDataAsMessageAttributes. (See addDMSEventDestination in the WLST Command Reference for Infrastructure Components.)
Then, you can query the log messages. For example, to query by Completing Party:
displayLogs(log="DOMAIN_HOME/servers/AdminServer/logs/DMSEventTraceLoggerDestination-event.log", groupBy=["SUPPL_ATTR.dms.NounType", "SUPPL_ATTR.dms.NounPath", "SUPPL_ATTR.org.service.CompletingParty"])
This command returns the following:
------------------------+------------------+-----------------------------+------ dms.NounType | dms.NounPath |org.service.CompletingParty|COUNT -----------------------+--------------------------+-------------------+------ CallCenter_Agent |/callAgent/Freya | null | 25 CallCenter_Agent |/callAgent/Johann | null | 20 CallCenter_Agent |/callAgent/Rhys | null | 25 CallCenter_City |/callCenter/fr/Pau | null | 2 CallCenter_City |/callCenter/fr/Vichy | null | 2 CallCenter_City |/callCenter/uk/Watford | null | 2 CallCenter_Country |/callCenter/de | null | 6 CallCenter_Country |/callCenter/fr | null | 6 CallCenter_Country |/callCenter/uk | null | 6 CallCenter_IncomingCall|/callCenter/fr/Pau/inCalls| agent | 10 CallCenter_IncomingCall|/callCenter/fr/Pau/inCalls| caller | 40
Parent topic: Searching Log Files
Downloading Log Files
You can download messages using Fusion Middleware Control or WLST commands, as described in the following topics:
- Downloading Log Files Using Fusion Middleware Control
- Downloading Log Files for Specific Components Using Fusion Middleware Control
- Downloading Specific Types of Messages Using Fusion Middleware Control
- Downloading Log Files Using WLST
Parent topic: Viewing and Searching Log Files
Downloading Log Files Using Fusion Middleware Control
You can download the log messages to a file. You can download either the matching messages from a search or the messages in a particular log file.
To download the matching messages from a search to a file using Fusion Middleware Control:
Parent topic: Downloading Log Files
Downloading Log Files for Specific Components Using Fusion Middleware Control
To download the log files for a specific component using Fusion Middleware Control:
Parent topic: Downloading Log Files
Downloading Specific Types of Messages Using Fusion Middleware Control
To export specific types of messages or messages with a particular Message ID to a file:
Parent topic: Downloading Log Files
Downloading Log Files Using WLST
You can download log files using the WLST displayLogs
command and redirecting the output to a file. For example:
displayLogs(type=['ERROR','INCIDENT_ERROR'], exportFile='/scratch/tmp/download_log.txt')
The messages are written to the file download_log.txt in the specified directory. By default, they are written to standard output.
Parent topic: Downloading Log Files
Configuring Settings for Log Files
You can change the location of log files, how often the log files rotate, and the level of information written to them, along with other configuration settings. You can change the log settings of Managed Servers and Java components using Fusion Middleware Control or WLST.
Note:
For many system components, which are listed in Using WLST Commands with System Components, you cannot configure settings for log files using Fusion Middleware Control. For information about how to configure options for log files for system components, see the administrator's guide for the component.
Note the following about using the WLST commands to configure log settings:
-
The configuration commands, such as
setLogLevel
, only work in connected mode. That is, you must connect to a running WebLogic Server instance before you invoke the commands.The configuration commands are supported for Java components that run within a WebLogic Server, but are not supported for Oracle WebLogic Server. The configuration commands are not supported for system components.
-
Most of the WLST logging commands require that you are running in the domainRuntime tree. For example, to connect and to run in the domainRuntime tree, use the following commands:
connect('username', 'password', 'localhost:port_number') domainRuntime()
-
The
listLoggers
,getLogLevel
, andsetLogLevel
commands work inconfig
andruntime
mode. Inconfig
mode the commands work on loggers that are defined in the configuration file. Inruntime
mode, the commands work directly with loggers that are defined in the server JVM. By default, thesetLogLevel
command sets the level on the run-time logger and updates the logger definition in the configuration file. By default, thelistLoggers
andgetLogLevel
commands return run-time loggers.
For more information about these commands, see Logging Custom WLST Commands in the WLST Command Reference for Infrastructure Components.
For Java components, you can configure the names and locations of log files, the size of the log files, the level of information written to the log files, the format, and the Locale encoding, as described in the following topics:
- Changing Log File Locations
- Configuring Log File Rotation
- Setting the Level of Information Written to Log Files
- Specifying the Log File Format
- Specifying the Log File Locale
Parent topic: Managing Log Files and Diagnostic Data
Changing Log File Locations
You can change the name and location of log files by using Fusion Middleware Control or WLST commands, as described in the following topics:
Parent topic: Configuring Settings for Log Files
Changing Log File Locations Using Fusion Middleware Control
To change the name and location of a component log file using Fusion Middleware Control:
Note that if you change the location of Oracle HTTP Server log files, the location of the access_log and ohsn.log files are changed, but the location of console~OHS~1.log is not changed.
Parent topic: Changing Log File Locations
Changing Log File Locations Using WLST
To change the log file location using WLST, use the configureLogHandler
command. For example, to change the path of the logger named odl-handler, use the following command:
configureLogHandler(name='odl-handler', path='/scratch/Oracle/logs')
Parent topic: Changing Log File Locations
Configuring Log File Rotation
An ODL log is a set of log files that includes the current ODL log file and zero or more ODL Archives (segment files) that contain older messages. As the log file grows, new information is added to the end of the log file, server_name
-diagnostic.log
. When the log file reaches the rotation point, it is renamed and a new log file, server_name
-diagnostic.log
is created. You specify the rotation point, by specifying the maximum ODL segment size or the rotation time and rotation frequency.
Segment files are created when the ODL log file server_name
-diagnostic.log
reaches the rotation point. That is, the server_name
-diagnostic.log
is renamed to server_name
-diagnostic-
n
.log
, where n
is an integer, and a new server_name
-diagnostic.log
file is created when the component generates new diagnostic messages.
To limit the size of the ODL log, you can specify:
-
The maximum size of the logging directory. Whenever the sum of the sizes of all of the files in the directory reaches the maximum, the oldest archive is deleted to keep the total size under the specified limit.
By default, the log files are rotated when they reach 10 MB. The maximum size of all log files for a particular component is 100 MB.
-
The maximum size of the log file. You specify that a new log file be created when a specific time or frequency is reached.
Note:
After you change the log file rotation, the configuration is reloaded dynamically. It may take 1 or 2 seconds to reload the configuration.
The following topics describe how to change the rotation:
- Specifying Log File Rotation Using Fusion Middleware Control
- Specifying Log File Rotation Using WLST
Parent topic: Configuring Settings for Log Files
Specifying Log File Rotation Using Fusion Middleware Control
To configure log file rotation using Fusion Middleware Control:
Parent topic: Configuring Log File Rotation
Specifying Log File Rotation Using WLST
To specify log file rotation using WLST, use the configureLogHandler
command. You can specify size-based rotation or time-based rotation.
For example, to specify that the log files rotate daily and that they are retained for a week, use the following command:
configureLogHandler(name='odl-handler', rotationFrequency='daily', retentionPeriod='week')
To specify that the size of a log file does not exceed 5 MB and rotates when it reaches that size, use the following command:
configureLogHandler(name='odl-handler', maxFileSize='5M')
Parent topic: Configuring Log File Rotation
Setting the Level of Information Written to Log Files
You can configure the amount and type of information written to log files by specifying the message type and level. For each message type, possible values for the message level are from 1 (lowest severity) through 32 (highest severity). Some components support only some of the levels for each message type. See the administrator's guide for your component for more information. Generally, you need to specify only the type; you do not need to specify the level.
When you specify the type, Oracle Fusion Middleware returns all messages of that type, as well as the messages that have a higher severity. For example, if you set the message type to WARNING, Oracle Fusion Middleware also returns messages of type INCIDENT_ERROR and ERROR.
Table 12-3 describes the message types and the most common levels for each type.
Table 12-3 Diagnostic Message Types and Level
Message Type | Level | Description |
---|---|---|
INCIDENT_ERROR |
1 |
A serious problem that may be caused by a bug in the product and that should be reported to Oracle Support. Examples are errors from which you cannot recover or serious problems. |
ERROR |
1 |
A serious problem that requires immediate attention from the administrator and is not caused by a bug in the product. An example is if Oracle Fusion Middleware cannot process a log file, but you can correct the problem by fixing the permissions on the document. |
WARNING |
1 |
A potential problem that should be reviewed by the administrator. Examples are invalid parameter values or a specified file does not exist. |
NOTIFICATION |
1 |
A major lifecycle event such as the activation or deactivation of a primary sub-component or feature. This is the default level for NOTIFICATION. |
NOTIFICATION |
16 |
A finer level of granularity for reporting normal events. |
NOTIFICATION |
32 |
The finest level of granularity for reporting normal events. |
TRACE |
1 |
Trace or debug information for events that are meaningful to administrators, such as public API entry or exit points. |
TRACE |
16 |
Detailed trace or debug information that can help Oracle Support diagnose problems with a particular subsystem. |
TRACE |
32 |
Very detailed trace or debug information that can help Oracle Support diagnose problems with a particular subsystem. |
The default is NOTIFICATION, level 1.
The INCIDENT_ERROR, ERROR, WARNING, and NOTIFICATION with level 1 have no performance impact. For other types and levels, note the following:
-
NOTIFICATION, with level 16 and 32: Minimal performance impact.
-
TRACE, with level 1: Small performance impact. You can enable this level occasionally on a production environment to debug problems.
-
TRACE, with level 16: High performance impact. This level should not be enabled on a production environment, except on special situations to debug problems.
-
TRACE, with level 32: Very high performance impact. This level should not be enabled in a production environment. It is intended to be used to debug the product on a test or development environment.
Table 12-4 shows the log level mappings among ODL format, Oracle WebLogic Server, and Java.
Table 12-4 Mapping of Log Levels Among ODL, Oracle WebLogic Server, and Java
ODL | WebLogic Server | Java |
---|---|---|
OFF |
OFF |
2147483647 - OFF |
INCIDENT_ERROR:1 |
(EMERGENCY) |
1100 |
INCIDENT_ERROR:4 |
EMERGENCY |
1090 |
INCIDENT_ERROR:14 |
ALERT |
1060 |
INCIDENT_ERROR:24 |
CRITICAL |
1030 |
ERROR:1 |
(ERROR) |
1000 - SEVERE |
ERROR:7 |
ERROR |
980 |
WARNING:1 |
WARNING |
900 - WARNING |
WARNING:7 |
NOTICE |
880 |
NOTIFICATION:1 |
INFO |
800 - INFO |
NOTIFICATION:16 |
(DEBUG) |
700 - CONFIG |
TRACE:1 |
(DEBUG) |
500 - FINE |
TRACE:1 |
DEBUG |
495 |
TRACE:16 |
(TRACE) |
400 - FINER |
TRACE:32 |
(TRACE) |
300 - FINEST |
TRACE:32 |
TRACE |
295 |
You can configure the message levels written to a log file for a particular log file or a logger using Fusion Middleware Control or WLST commands, as described in the following topics:
- Configuring Message Levels for a Log File Using Fusion Middleware Control
- Configuring Message Levels for Loggers Using Fusion Middleware Control
- Configuring Message Levels Using WLST
Parent topic: Configuring Settings for Log Files
Configuring Message Levels for a Log File Using Fusion Middleware Control
To set the message level for a component log file:
Parent topic: Setting the Level of Information Written to Log Files
Configuring Message Levels for Loggers Using Fusion Middleware Control
To set the message level for one or more loggers for a component:
Parent topic: Setting the Level of Information Written to Log Files
Configuring Message Levels Using WLST
To set the message level with WLST, you use the setLoglevel
command. To get the current message level, you use the getLogLevel
command. You must be connected to WebLogic Server before you use the configuration commands.
You can view the log level for a logger for an Oracle WebLogic Server. For example, to view the log level of the Oracle WebLogic Server wls_server_1, use the following command:
getLogLevel(logger='oracle', target='wls_server_1') NOTIFICATION:1
You can set the log level for a particular logger. The following example sets the message type to WARNING for the logger oracle.wsm.msg.logging:
setLogLevel(target='wls_server_1', logger='oracle.wsm.msg.logging', level='WARNING')
To get a list of loggers for the Oracle WebLogic Server wls_server_1, use the listLoggers command:
listLoggers(target='wls_server_1') . . . oracle.wsm.msg.logging | NOTIFICATION:1 oracle.wsm.nobehavior.model.NoBehaviorAssertion | <Inherited> oracle.wsm.policy.advertisement.AdvertisementContext | <Inherited> oracle.wsm.policy.model.impl.AndCompositeAssertion | <Inherited> . . .
You can also filter logger names using the pattern parameter and a regular expression. For example, to return all loggers that begin with oracle
in the Oracle WebLogic Server wls_server_1, use the following command:
listLoggers(target='wls_server_1', pattern='oracle.*') ------------------------------------------------------------------------------- Logger | Level ------------------------------------------------------------------------------- oracle NOTIFICATION:1 oracle.adf <Inherited> oracle.adf.controller <Inherited> oracle.adf.desktopintegration <Inherited> oracle.adf.faces <Inherited>
Parent topic: Setting the Level of Information Written to Log Files
Specifying the Log File Format
By default, information is written to log files in ODL text format. You can change the format to ODL XML format using Fusion Middleware Control or WLST commands, as described in the following topics:
- Specifying the Log File Format Using Fusion Middleware Control
- Specifying the Log File Format Using WLST
Parent topic: Configuring Settings for Log Files
Specifying the Log File Format Using Fusion Middleware Control
To change the format using Fusion Middleware Control:
Parent topic: Specifying the Log File Format
Specifying the Log File Format Using WLST
To specify the log file format using WLST, you use the configureLogHandler
command, with the format
parameter and specify either ODL-Text or ODL-XML. ODL-Text is the default.
For example, to specify ODL-XML format, use the following command:
configureLogHandler(name='odl-handler', format='ODL-XML')
Parent topic: Specifying the Log File Format
Specifying the Log File Locale
The language and data formats used in the log files are determined by the default locale of the server Java Virtual Machine (JVM). You can change them using the Language and Regional Options applet in Control Panel on Windows or the LANG and LC_ALL environment variables on a UNIX platform.
The character encoding of log files is determined by the server JVM's default character encoding or an optional configuration setting. You should choose an encoding that supports all languages used by the users, or the log file may be corrupted. By default, the log is in the server JVM's default character encoding. If you change the encoding, delete or rename old log files to prevent them from being damaged by the new logs appended in a different encoding.
For support of any language, Oracle recommends that you use Unicode UTF-8 encoding. On a UNIX operating system, setting the LANG and LC_All environment variables to a locale with the UTF-8 character set enables UTF-8 logging (for example, en_US.UTF-8
for the US locale in UTF-8 encoding).
You can specify the log file locale using WLST commands or by editing a file, as described in the following topics:
Parent topic: Configuring Settings for Log Files
Specifying the Log File Encoding Using WLST
To specify the log file encoding using WLST, use the configureLogHandler
command. You can use the encoding parameter to specify the character set encoding.
For example, to specify UTF-8, use the following command:
configureLogHandler(name="odl-handler", encoding="UTF-8")
Parent topic: Specifying the Log File Locale
Specifying the Log File Encoding in logging.xml
To specify the log file encoding in the logging.xml file, use an optional encoding property to specify the character set encoding.
The logging.xml file is located in the following directory:
DOMAIN_HOME/config/fmwconfig/servers/server_name/
For example, to specify UTF-8, add the following encoding property in the log_handler element:
<property name='encoding' value='UTF-8'/>
Parent topic: Specifying the Log File Locale
About Correlating Messages Across Log Files and Components
Oracle Fusion Middleware components provide message correlation information for diagnostic messages. Message correlation information helps those viewing diagnostic messages to determine relationships between messages across components.
This section contains the following topics:
- Understanding ECIDs and RIDs in Correlating Messages
- Correlating Messages Across Messages and Components
Parent topic: Managing Log Files and Diagnostic Data
Understanding ECIDs and RIDs in Correlating Messages
Each diagnostic message contains an Execution Context ID (ECID) and a Relationship ID (RID):
-
An ECID is a globally unique identifier associated with the execution of a particular request. An ECID is generated when the request is first processed.
-
A RID distinguishes the work done in one thread on one process, from work done by any other threads on this and other processes on behalf of the same request.
The ECID and RID help you to use log file entries to correlate messages from one application or across Oracle Fusion Middleware components. By searching for related messages using the message correlation information, multiple messages can be examined and the component that first generates a problem can be identified (this technique is called first-fault component isolation). Message correlation data can help establish a clear path for a diagnostic message across components, within which errors and related behavior can be understood.
You can use the ECID and RID to track requests as they move through Oracle Fusion Middleware.
The following shows an example of an ECID:
0000I3K7DCnAhKB5JZ4Eyf19wAgN000001,0
The RID is one or more numbers separated by a colon (:). The first RID created for a request is 0. Each time work is passed from a thread that has an ECID associated with it to another thread or process, a new RID is generated that encodes the relationship to its creator. That is, a new generation is created. Each shift in generation is represented by a colon and another number. For example, the seventh child of the third child of the creator of the request is:
0:3:7
Correlating Messages Across Messages and Components
You can view all the messages with the same ECID using the WLST displayLogs
command. The following example searches for the ECID in the domain:
displayLogs(ecid='0000Hl9TwKUCslT6uBi8UH18lkWX000002')
You can also search for the ECID in a WebLogic Server instance, or a system component, by specifying it in the target option.
You can search for messages with a particular ECID on the Log Messages page in Fusion Middleware Control:
Configuring Tracing
Sometimes you need more information to troubleshoot a problem than is usually recorded in the logs. One way to achieve that is to increase the level of messages logged by one or more components, and fine-tune which messages are written to the log files.
For example, you can set the logging level to TRACE:1 or TRACE:32, as described in Setting the Level of Information Written to Log Files, which results in more detailed messages being written to the log files. This is referred to as tracing.
However, tracing can often result in a large amount of log messages being written to the log files. Oracle Fusion Middleware provides the following mechanisms to fine-tune which messages are traced:
-
QuickTrace, which provides fine-grained logging to memory
-
Selective Trace, which provides fine-grained logging for a specific user or other properties of a request
The following topics provide information about how to use these mechanisms:
Parent topic: Managing Log Files and Diagnostic Data
Configuring and Using QuickTrace
QuickTrace provides fine-grained logging to memory. The following topics describe Quick Trace and how to enable and use it:
- About Quick Trace
- Configuring QuickTrace
- Writing Trace Messages to a File
- Disabling QuickTrace Using WLST
Parent topic: Configuring Tracing
About Quick Trace
With QuickTrace, you can trace messages from specific loggers and store the messages in memory. Because QuickTrace logs the messages to memory, it avoids the cost of formatting, string manipulations, and input/output operations. As as result, you can enable fine-level application logging for specific loggers without performance overhead.
By default, QuickTrace writes the messages to one common buffer. However, you can specify that messages for particular users are written to separate buffers.
You can save the messages that are in memory to a file by invoking the QuickTrace Dump in Fusion Middleware Control as described in Writing the Trace Messages to a File Using Fusion Middleware Control or by using the WLST, as described in Writing the Trace Messages to a File Using WLST.
To enable QuickTrace, you create a QuickTrace handler and associate a logger with it. You can specify the buffer size, as well as other attributes, for the handler. Then, you set the level of the amount and type of information to be written by the loggers to memory.
Parent topic: Configuring and Using QuickTrace
Configuring QuickTrace
You can configure and use QuickTrace using Fusion Middleware Control or WLST, as described in the following topics:
Parent topic: Configuring and Using QuickTrace
Configuring QuickTrace Using Fusion Middleware Control
To configure QuickTrace using Fusion Middleware Control:
Now, messages of the specified level for the specified loggers are written to memory.
Parent topic: Configuring QuickTrace
Configuring QuickTrace Using WLST
To configure QuickTrace using WLST, you associate a logger with the QuickTrace handler, using the configureLogHandler command.
For example, to associate the oracle.adf logger with the QuickTrace handler and write all TRACE:1 messages to memory:
See configureLogHandler in the WLST Command Reference for Infrastructure Components
To confirm the level for the handler, use the getLogLevel command, as described in Configuring Message Levels Using WLST.
Parent topic: Configuring QuickTrace
Writing Trace Messages to a File
You can write trace messages to a file using Fusion Middleware Control or WLST, as described in the following topics:
- Writing the Trace Messages to a File Using Fusion Middleware Control
- Writing the Trace Messages to a File Using WLST
Parent topic: Configuring and Using QuickTrace
Writing the Trace Messages to a File Using Fusion Middleware Control
You can save the messages that are in memory to a file by invoking the QuickTrace Dump in Fusion Middleware Control:
Parent topic: Writing Trace Messages to a File
Writing the Trace Messages to a File Using WLST
You can save the messages to a file by using the executeDump command.
For example:
executeDump(name="odl.quicktrace", outputFile="/scratch/oracle1/qt1.dmp")
The command writes the dump to the specified file.
For more information about the executeDump command, see Executing Dumps.
In addition, if an incident is created (automatically or manually), the QuickTrace messages are written to dump files in the incident directory. If you enabled user buffers, each user will have one file and the common buffer will have one file.
The file names have the following format:
odl_quicktraceN_iincident_number.username.dmp
For example:
odl_quicktrace6_i1.weblogic.dmp
See Creating an Incident Manually for information about creating an incident.
Parent topic: Writing Trace Messages to a File
Disabling QuickTrace Using WLST
To disable QuickTrace, use the WLST configureLogHandler command and specify that the level is OFF:
configureLogHandler(name="quicktrace-handler", level="OFF") Handler Name: quicktrace-handler type: oracle.core.ojdl.logging.QuickraceHandlerFactory . . . reserveBufferUserID: user1, user2 enableUserBuffer: true
To remove a specific logger from association with the QuickTrace handler, use the configureLogHandler command with the removeFromLogger parameter:
configureLogHandler(name="quicktrace-handler", removeFromLogger="oracle.adf.faces") Handler Name: quicktrace-handler type: oracle.core.ojdl.logging.QuickraceHandlerFactory reserveBufferUserID: user1, user2 enableUserBuffer: true
See configureLogHandler in the WLST Command Reference for Infrastructure Components for complete syntax.
Parent topic: Configuring and Using QuickTrace
Configuring and Using Selective Tracing
Selective tracing provides fine-grained logging for specified users or other attributes of a request.
The following topics describe selective tracing and how to manage it using Fusion Middleware Control or WLST:
- About Selective Tracing
- Configuring Selective Tracing
- Viewing Selective Traces
- Disabling Selective Tracing
Parent topic: Configuring Tracing
About Selective Tracing
Selective tracing provides fine-grained logging for specified users or other attributes of a request.
For example, a user cannot perform some functions because of security permissions, but it is not clear what operations or lack of permission for those operations are posing a problem.
In this case, you can enable tracing across the entire system but this would generate a large volume of log messages for all users in the system, not only for the user having a problem. With selective tracing, you can enable tracing only for the user who is having a problem. Then, you can ask the user to retry the functions. Following that, you can look at the trace messages which apply to the specific request made by the user.
You can also specify the logger to narrow the scope of the messages being logged.
Parent topic: Configuring and Using Selective Tracing
Configuring Selective Tracing
You can configure selective tracing using Fusion Middleware Control or WLST, as described in the following topics:
- Configuring Selective Tracing Using Fusion Middleware Control
- Configuring Selective Tracing Using WLST
Parent topic: Configuring and Using Selective Tracing
Configuring Selective Tracing Using Fusion Middleware Control
To configure selective tracing using Fusion Middleware Control:
Now that you have started the trace, you can view active traces, as well as former traces, as described in Viewing Selective Traces Using Fusion Middleware Control.
Parent topic: Configuring Selective Tracing
Configuring Selective Tracing Using WLST
You can configure loggers for selective tracing and start tracing using the WLST configureTracingLoggers and startTracing commands.
For the simplest case, you can configure and start a trace using the startTracing command. When you do so, the selective tracing includes all loggers enabled for selective tracing.
For example, user1 receives errors when attempting to perform certain operations. To start a trace of messages related to user1 and to set the logging level to FINE, use the following command:
startTracing(user="user1",level="FINE") Started tracing with ID: 885649f7-8efd-4a7a-9898-accbfc0bbba3
The startTracing command does not provide options to include or exclude particular loggers. In this case, you can use the configureTracingLoggers command. This command allows you to configure selective tracing to include only particular loggers and particular Oracle WebLogic Server instances. Note that the options you specify apply to all current and active traces.
For example, to configure selective tracing to include only security-related loggers:
See the following commands in the WLST Command Reference for Infrastructure Components for complete syntax:
Parent topic: Configuring Selective Tracing
Viewing Selective Traces
You can view selective traces using Fusion Middleware Control or WLST, as described in the following topics:
Parent topic: Configuring and Using Selective Tracing
Viewing Selective Traces Using Fusion Middleware Control
You can view the selective traces that are currently active and the history of selective traces.
To view the selective traces:
Parent topic: Viewing Selective Traces
Viewing Selective Traces Using WLST
After you have begun a trace, you can see the active traces by using the listActiveTraces command, as shown in the following example:
listActiveTraces()
-------------------------------------+----------+-----------+------+--------------+----------- Trace ID |Attr. Name|Attr. Value| Level| Exp. Time |Description -------------------------------------+----------+-----------+------+--------------+----------- b73b351c-9a9b-47df-b05a-356a336d5780 | USER_ID | user1 | FINE | 5/22/17 11:17 AM | a9580e65-13c4-420b-977e-5ba7dd88ca7f |USER_ID |user1 | FINE | 5/22/17 11:19 AM |
You can view the contents of the trace using the displayLogs command and passing it the trace ID. You can also view traces that have stopped. For example:
displayLogs("a9580e65-13c4-420b-977e-5ba7dd88ca7f")
See listActiveTraces in the WLST Command Reference for Infrastructure Components for complete syntax.
Parent topic: Viewing Selective Traces
Disabling Selective Tracing
You can configure selective tracing, view traces, and disable selective tracing using WLST, as described in the following topics:
Parent topic: Configuring and Using Selective Tracing
Disabling Selective Tracing Using Fusion Middleware Control
To disable selective tracing using Fusion Middleware Control:
- From the navigation pane, right-click the domain name and choose Logs, then Selective Tracing.
- Select the Active Traces and Tracing History tab.
- In the Active Traces table, select the trace and click Disable.
Parent topic: Disabling Selective Tracing
Disabling Selective Traces Using WLST
To avoid excessive logging in the system, you can disable a selective trace when you have obtained the information that you need. To disable a selective trace, you use the WLST stopTracing command, passing it the trace ID or user. For example:
stopTracing(traceId="885649f7-8efd-4a7a-9898-accbfc0bbba3") Stopped 1 traces
You can also disable all traces by using the stopAll option. For example:
stopTracing(stopAll=1)
See stopTracing in the WLST Command Reference for Infrastructure Components for complete syntax.
Parent topic: Disabling Selective Tracing