Sailors sailing coast to coast across the seas always kept the records of their daily business in a book called a shipper's logbook. These contained all kinds of data, such as the ship's status, its location, the date and time, and a lot of other information about the ship and the crew.
In fact, computer systems maintain their status about many of these items too. These systems can give an overview, or unless configured in detail, about how your system was performing in the past and how it's performing right at this very moment.
So, let's take a deeper look into your Oracle WebLogic Server and also how to configure, maintain, and analyze your log files.
WebLogic uses a mechanism called Logging Services to give detailed information about your WebLogic domain, server instances, resources, and applications.
Each WebLogic Server instance maintains a server log. Because each WebLogic Server domain can run concurrent multiple instances of WebLogic Server, the logging services collect messages that are generated on multiple server instances into a single domain-wide message log. The domain log provides the overall status of the domain.
In fact, there are two main components that the logging mechanism depends on: the component that produces the logging and the other component that publishes the messages.
WebLogic uses the standard java.util.logging interface to let applications produce useful messages to the logging services. Applications can use two components:
weblogic.logging.NonCatalogLoggerAPIsWith NonCatalogLogger, instead of calling messages from a catalog, message text appears directly in your application code.
- Server Logging Bridge
WebLogic Server provides a mechanism by which your logging application can have its messages redirected to WebLogic logging services without the need to make code changes or implement any of the proprietary WebLogic Logging APIs.
In the previous diagram, above the dotted line you can see the interfaces that produce Logging Messages. These produced messages are forwarded to the Server Logger interface, which depending on the configuration of Logging transfers the message through the several interfaces to a log file.
Oracle WebLogic Server logging services provide facilities for writing, viewing, filtering, and listening to log messages. These log messages are generated by the Oracle WebLogic Server instances, subsystems, and Java EE applications that run on Oracle WebLogic Server or on client JVMs.
Oracle WebLogic Server subsystems use logging services to provide information about events such as the deployment of new applications or the failure of one or more subsystems. A server instance uses them to communicate its status and respond to specific events. Debugging can also be enabled on individual subsystems to include additional life cycle information.
Some of the main subsystems that use logging services are:
- Server
- HTTP
- JTS
- JMS
- JDBC
Oracle WebLogic Server supports a variety of logging frameworks and is able to consume these log messages and redirect/publish them to a variety of destinations such as domain log files.
When an Oracle WebLogic Server instance writes a message to the server log file, the first line of each message begins with #### followed by the message attributes. Each attribute is contained between angle brackets. The following is an example of a message in the server log file:
####<Sept 22, 2004 10:46:51 AM EST> <Notice> <WebLogicServer> <MyComputer> <examplesServer> <main> <<WLS Kernel>> <> <null> <1080575211904> <BEA-000360> <Server started in RUNNING mode>
The attributes each log file contains are as follows:
- Timestamp: The time and date when the message originated, in a format that is specific to the locale.
- Subsystem: The particular subsystem that was the source of the message (such as Management, Security, EJB, RMI, and JMS).
- Severity: The degree of impact or seriousness of the event reported by the message.
- Catalog ID: The unique ID assigned to this type of event, to reference in the online documentation.
- Server Name: The WebLogic Server instance that generated the message.
- Machine Name: The DNS name of the computer that hosts the WebLogic Server instance.
- Thread ID: The server thread that generated the message.
- User ID: The current security context, if any.
- Transaction ID: The current XA transaction context, if any.
- Diagnostic Context ID: Context information to correlate messages coming from a specific request or application.
- Raw Time Value: The timestamp in milliseconds.
- Message ID: A unique six-digit identifier.
- Message Text: A description of the event or condition.
Each log message has a severity level to determine the importance and urgency of a message. WebLogic Server delivers a severity level, from TRACE to EMERGENCY, which is converted to a log level when dispatching a log request to the logger. By default, servers forward only messages of the severity level NOTICE or higher.
The WebLogic Server subsystems generate many messages of lower severity and fewer messages of higher severity. For example, under normal circumstances, they generate many INFO messages and no EMERGENCY messages.
The following are the severity levels in WebLogic Server:
- TRACE: Messages from the diagnostics framework
- DEBUG: Detailed internal messages (if debugging is enabled)
- INFO: Normal operations
- NOTICE: INFO message of greater importance
- WARNING: Suspicious operation or configuration
- ERROR: Error-handling request, but no interruption in service
- CRITICAL: System or service error that may cause temporary loss or degradation of service
- ALERT: One or more services in an unusable state, requiring administrative attention
- EMERGENCY: Entire server in an unusable state