LOGGING SERVICES IN WEBLOGIC

Weblogic components or subsystems generate log files containing information that record all types of
events or messages such as startup and shutdown information, deployment of new applications, failure
of one or more subsystems, errors occurred, warning messages, and access information on HTTP
requests.

Generally Logs can be help in the discovery of:
1) Any problems encountered while servicing or executing the requests on server
2) Records servers activity on daily including time intervals
3) The IP addresses of users accessing an application
4) Frequently accessed resources or subsystems or components
5) The amount of data sent and received

These log messages are generated by the Oracle WebLogic Server instances/servers, subsystems,
and Java EE applications that run on Oracle WebLogic Server or on client JVMs
Debugging can also be enabled on individual subsystems to include additional information to trace
out the problems

The main subsystems that use logging services are:
Server Logs
Domain Logs
Transaction Logs
HTTP Logs
Different Server Logs:
There are different types of Server logs generated in weblogic system.
Server_name.log
Server_name-diagnostic.log
Server_name.out
Domain_name.log
Application_name.log
Access.log
Transaction Logs

Server_name.log: Logs all on going activities on server and keeps records of all messages. Subsystems
and applications generate log messages to communicate its status.
The below one is an example of a message in a log file: which includes the #### prefix and
Timestamp, Severity, Subsystem, Server Name/Machine Name/Thread ID, User, Transaction ID, Message
ID or catalog ID, Message Text.

####<Nov 11, 2002 2:07:57 PM EST> <Notice> <WebLogicServer> <MyComputer>
<MedRecServer> <main> <kernel identity> <> <BEA-000360> <Server started in RUNNING mode>

By default Server logs are stored in DOMAIN_HOME/servers/server_name/logs/
Server_name-diagnostic.log: This log file records mainly information related to applications deployed
on server and their errors messages.


Server_name.out: It will be generated If you use Node Manager to start Managed Server from WebLogic
server administration console otherwise stdout or stderr messages written to a server_name.log.
The server log records information about events such as the startup and shutdown of servers, the
deployment of new applications, or the failure of one or more subsystems and it may include startup
information such as JVM heap and the CLASSPATH settings as well as runtime infrastructure issues
errors. And includes all JDBC and JMS logs The below one is example:

<Nov 11, 2002 2:07:57 PM EST> <Notice> <WebLogicServer> <BEA-000360> <Server started in RUNNING mode>

Domain_name.log: The domain log file provides a central location from which to view the overall status
of the domain and resides in the administration server logs directory. The default name and location for
the domain log file is DOMAIN_NAME/servers/ADMIN_SERVER_NAME/logs/DOMAIN_NAME.log

Application_name.log: These custom logs will be generated by specific applications deployed on server
if it is defined by developer and contains messages or information or errors to that particular application
only.

Access.log: Separate log file called access log record all HTTP requests processed by the server because
server does not store HTTP requests in the server log file or the domain log file. The access logs contains
basic information about every HTTP requests or transactions handled by the server, applications are
being accessed and by whom. This can be achieved by enabling HTTP logging and it enabled by default.
The format contains the below following fields: Host name, Remote log name, Remote user and time,
Request, Response code or status, Number of transferred bytes
Configuration for access.log: Environment > Servers > select any server > Logging > HTTP
Example:
10.37.20.201 - - [26/Jun/2014:23:29:34 +0200] "POST /app-app/IncomingService HTTP/1.1" 200 991

Transaction Logs: Each server instance, including the administration server, has a default store which is
a file-based or Database store, each server has a transaction log [TLOG] which stores information
about committed or uncommitted transactions in persistence store. WebLogic Server uses the
transaction log when recovering from system crashes or network failures. Using the transaction
information from the transaction logs, the server makes an attempt to complete all in-flight,
uncommitted transactions from the time the server failed. Ex: WLS_WLS_OSB2000000.DAT
Locate or configure default persistent store for Transaction Recovery -Weblogic console: +Servers >
Server1 > Configuration > Services: Default store section.
Note: One cannot directly view the transaction log the file is in a binary format.
Log Level or Message Severity
The log levels of log messages from WebLogic Server subsystems, starting from the lowest level of
impact to the highest


Messages range
There are will be catalog numbers for every message for component or subsystem which is below are
the few message ranges for components, reference taken from WebLogic version 10.3.3

Message Catalog Cross-Reference
BEA-280060 is called a message catalog number which will be help mostly for to find out the cause
and action needs to be taken for an issue. BEA-code can search in google to find out the description of it.
Below is example of BEA-280060 catalog number:

CONFIGURING ROTATION AND VIEWING LOGS FROM CONSOLE
By default, WebLogic comes with standard log configuration and Rotation. if you need to configure or
modify the existing values below are the steps:
To configure logs:
1) Login into WebLogic Console > Environment >select Servers.
2) In the Servers table, click the name of the server instance whose logging you want to configure.
3) Select Logging > General.
4) Retain or modify the default values.


Log Rotation:
Log rotation is useful to prevent excessive log file growth.
Rotation mechanism is done by types, we can enable only one type at a time.
1) Size based 2) Time interval based
Each time when server log file reaches its defined size or time based, the server renames the
current log file and creates a new SERVER_NAME.log to store new messages.
By default, in production mode weblogic rotates log file on sized based with limit 5 MB in size.
That means when log file reaches 5 MB in size then it creates a new file
In development mode by default Log file are rotated at server startup

Configuring Log Rotation:
From above after navigating to General tab you will find Rotation section. Here you can make changes
to Rotation type By Size or By Time.
To rotate Domain Logs: Click on Domain Structure (domain_name) > Logging.
For size based you need to specify the file size and for Time based need to specify the Rotation
interval



Note:
1) You need to restart the servers to take changes effect for log rotation
2) Log rotation of server_name.out should be done by manually using shell scripts if needed
3) By default server_name.log is 5MB and server-diagnostic.log is 10MB in size.
To view logs from weblogic console:
Log files can be viewed from weblogic console rather than unix terminals but we cannot view as best as
from terminals.
1) Login to WebLogic Console > Expand Diagnostics > Select Log Files.
2) In the Log Files table, select the radio button next to the name of the log you want to view.
3) The page displays the latest messages or contents of the log file; up to 500 messages in reverse
4) Select the radio button next to the log record you want to view.



CONFIGURING LOG FILTERS
The WebLogic Server provides the facility of filtering the messages i.e., omits or skips the specified
messages from server log while server writes the messages. This can be achieved by below techniques.
1) Changing the Log Level for Loggers.
2) Setting a Message Filter for Loggers.

1) Changing the Log Level for Loggers: By default logger publishes messages of all severity levels from
lowest to highest impact DEBUG, INFO, WARNING, ERROR, NOTICE, CRITICAL, ALERT, EMERGENCY.
For example, suppose if you set a Logger level to NOTICE, the Logger publishes only type of NOTICE,
CRITICAL, ALERT, EMERGENCY messages only.
There are separate settings for Server Log file, Standard out log and Domain Log which can be change
log level individually from WebLogic administration console.
1. Login to weblogic console > Environment and select Servers.
2. Under Servers, click the name of the server instance whose logging you want to configure.
3. On the Logging: General page, click Advanced.
4. Under Message Destinations sections:




2) Setting a Message Filter for Loggers: When you set log level filter on logger it effects on all handlers
or subsystems but when you set a message filter on a logger that affects only the behavior of the
specific handler.
Example: below are the steps for creating a log filter to avoid message oracle.jps.deployment from log
file and applying the created filter to logger and this can be applied from weblogic console.

1. Login to weblogic console > domain_name > Configuration Tab > log Filters SubTab.







Another Example of Log filter for filtering out all messages containing the Message Id 320114
(MSGID != 320114)

Applying created log filter: After creating the Log filter like above it can be applied from below steps.
Navigate to: Environment > Servers > Select any server > Logging Tab > General SubTab. > Advanced



Expand > Advanced


From the above, you can set the created LogFilter from list to apply the rule. This can be set individually
for Server.log, Server.out and Domain logs.

Below is the chart of column names that can be used for log filter.

WLDF: [Weblogic Diagnostics Framework]
A WLDF also can be used for log filtering which includes a query language for constructing watch rule
expressions, Data Accessor query expressions, and log filter expressions. The syntax is a small and
simplified subset of SQL syntax.

WebLogic SNMP LogFilter Configuration:
SNMP is Simple Network Management Protocol (SNMP) which can be used for Log filtering and
monitoring weblogic servers

For above topics please go through the Oracle documents if you want learn on this [Not explained in this
document]
DEBUG LOGS ON SERVER:
Weblogic server provides debugging the subsystems or components to avail additional information
when a problem exists on server. This can be set from weblogic console dynamically without any
restarts this helps to fix the servers issues easily.
For example if you are facing issues or problems with JDBC connection, to know additional information
causing problem with JDBC connection then DEBUG can be enabled from weblogic console.
Steps:
1) Login to weblogic console > Environment > Servers [select any Server] > Debug Tab.
2) Select the component to DEBUG in this example selecting JDBC Conn and push the Enable button
to activate dynamically.


NOTE:
1) Debug can be enabled and disabled dynamically either from +Default or +Weblogic from debug
Tab at any time for sub components provided by WebLogic server
2) When DEBUG is enabled the logs will be generated or rotated with in short period of time due
to server writes additional information in logs and this causes more disk usage, so please check
the storage capacity before you enable the debugging
3) Best practice is to stop the debugging logs after collecting the additional information from logs
from troubleshooting process.

LOGGING IN SOA:
Most Oracle Fusion Middleware components write diagnostic log files in the Oracle Diagnostic Logging
(ODL) format. This means ODL logs entries in a consistent, structured way using predefined fields and
name/value pairs.
ODL-formatted log files can be viewed through the Web-based Oracle Enterprise Manager which
gives more flexible on logs to work with them.
The entries are written to the server diagnostic log file and you can download them on client system
The ODL framework provides support for managing log files, including log file rotation. The
maximum log file size and the maximum size of log directories can also be defined
Log Configuration:
Log configuration done by through
1) SOA EM Console 2) Through WLST command 3) Editing logging.xml
1) SOA EM Console:
Log configuration can be done to particular server (For ex: only for admin server or SOA server), just you
need to do is Right-click on that particular server from weblogic domain in SOA EM Console and select
Log Configuration



This page is to configure basic and advanced log configuration settings.

Types of Loggers in SOA:
There are two types of loggers in SOA
1. Runtime loggers
2. Persistent loggers

1. Runtime loggers: Runtime loggers are activated automatically or dynamically when changes are made
to log level during runtime or become active when a particular feature area is used. But their log levels
are not saved or remained after component or server restarts. To save modified log level settings even
after restarts check the box of Persist log level state across component restarts as shown below.



2. Persistent Logger: Loggers with persistent Log level state those become active when a component
or server is restarted. Their configuration details are saved in a logging.xml file and automatically their
log levels are persisted or saved across component restarts.


Specify Custom Loggers:
For Example, Suppose desired loggers are not existed in Runtime or Persistent Loggers after your search
they can be added manually from Specify Loggers section by giving Logger name and Diagnostic level
but to affect these settings servers need restart.
In below screenshot after searching logger oracle.bam.server is not existed in either Runtime or
Persistent Loggers. So after backing up to logging.xml this can be added by in name field and select
logging level from dropdown list to requirement then press enter then it will add entry into loggong.xml
file and push apply button to save settings. But to effect servers needs to restart.


It is not recommended that you set the level to FINIEST at a parent level as it will generate a lot
of logging.
Make sure you apply the change to take effect
2) Through WLST Command:
In this document explained few basic examples with Logging can be done through WLST commands
In the Use with WLST column, Online means the command can only be used when connected to
a running server. Offline means the command can only be used when not connected to a running server.
Online or offline means the command can be used in both situations.
listLoggers - Get the list of loggers and the level of each logger. Used with Online
setLogLevel - Set the level for a given logger. Used with Online
getLogLevel - Get the level for a given logger. Used with Online

Navigate and invoke from MiddlewareHome/Oracle_SOA1/common/bin/wlst.sh
Connect to required server: connect('username', 'password', 't3://Listenaddress:portno')
wls:/bpm_domain/serverConfig> domainRuntime()

1) listLoggers: Lists loggers and their levels. An empty level is used to indicate that the logger does not
have the level set.
Syntax: listLoggers(target, pattern, runtime)
Target-- The name of WebLogic server which you want to list all the logger value
Pattern-- A regular expression that is used to filter logger names
Runtime-- A Jython boolean value (0 or 1) that determines if the operation is to list runtime
loggers or config loggers. The default value is 1.
Examples:
The following example lists all of the loggers:
listLoggers()

The following example lists all of the loggers that start with the name oracle.*.
listLoggers(pattern="oracle.*")

The following examples list all loggers for the WebLogic server server1:
listLoggers(target="server1")



The following example lists all config loggers:
listLoggers(runtime=0)
wls:/bpm_domain/domainRuntime> listLoggers(runtime=0)
------------------------------------------------------+-----------------
Logger | Level
------------------------------------------------------+-----------------
<root> | WARNING:1
oracle | NOTIFICATION:1
oracle.adf | <Inherited>
oracle.adf.controller | <Inherited>

2) setLogLevel: Sets the log level to given logger.
Syntax: setLogLevel(target, logger, addlogger, level, runtime, persist)
Logger-- A logger name. An empty string denotes the root logger. This option is required and has
no default. The command throws an exception if the logger does not exist, unless the
addLogger option is also used.
addLogger-- Jython boolean value (0 or 1) that determines if the logger should be created if it
does not exist.
Level--The level name. It can be either a Java level or an ODL level.
Persist -- A Jython boolean value (0 or 1) that determines if the level should be saved to the
configuration file. The default value is 1.

Examples:
The following example sets the log level to NOTIFICATION:1 for the logger oracle.my.logger:
setLogLevel(logger="oracle.my.logger", level="NOTICATION:1")

The following example sets the log level to TRACE:1 for the logger oracle.my.logger and specifies that
the level should be saved to the configuration file:
setLogLevel(logger="oracle.my.logger", level="TRACE:1", persist=0)

The following example sets the log level to WARNING for the config logger oracle.my.logger on the
WebLogic server server1:
setLogLevel(target="server1", logger="oracle.my.logger", level="WARNING", runtime=0)

The following example sets the log level to SEVERE foor the logger oracle.adf.share.security on the
adminserver and addlogger is for logger should be created if does not exist
setLogLevel(target="AdminServer", logger="oracle.adf.share.security", level="SEVERE", addLogger=1)

3) getLogLevel: gets the level of a given loggername or None if the logger does not exist and An empty
string indicates that the logger level is null.
Syntax: getLogLevel(target, logger, runtime)
Target-- The name of WebLogic server which you want to get the logger value
Logger-- A logger name. An empty string denotes the root logger (i.e., parent logger)
Runtime-- A Jython boolean value (0 or 1) that determines if the operation is to list runtime
Loggers or config loggers. The default value is 1 (runtime).



Examples:
The following example returns the level for the logger oracle:
-getLogLevel(logger='oracle')
wls:/bpm_domain/domainRuntime> getLogLevel(logger='oracle')
NOTIFICATION:1

The following example returns the level for the logger oracle, specifying only config loggers:
-getLogLevel(logger='oracle', runtime=0)
wls:/bpm_domain/domainRuntime> getLogLevel(logger='oracle', runtime=0)
NOTIFICATION:1

The following example returns the level for the logger oracle on the Oracle WebLogic Server server2:
-getLogLevel(logger='oracle', target='server2')
-getLogLevel(logger='oracle.adf.share.security', target="AdminServer")
3) Editing logging.xml file
The other method of setting log level is directly by editing the logging.xml file which is located at
user_projects/domain_home/config/fmwconfig/servers/WLS_SOA1/logging.xml where each server has
its own logging.xml file. Take backup before you edit the file.
Open the logging.xml you will find below format.
<logger name='oracle' level='NOTIFICATION:1'/>
<logger name='oracle.adf'/>
<logger name='oracle.adf.desktopintegration'/>
<logger name='oracle.adf.faces'/>

When you need to add custom logger with log level just go to that particular server logging.xml and add
to the last line of file. For example below oracle.bam.server logger is added.
<logger name='oracle.bam.server' level='NOTIFICATION:1'/>
</loggers>
</logging_configuration>
Advantages with Fusion Middleware Control
Viewing Log Files and searching Log Files and Their Messages from SOA EM Console
Changing Log File Locations and Downloading Log Files Using SOA EM Console
Configuring Log File Rotation and Setting the Log Level information Written to Log Files
Specifying the Log File Format and configuring Selective Tracing using SOA EM Console.












Diagnostic Message Types and Log Level


Example of ODL format messages