|
|
This section describes how to monitor, log, and audit WLOC services and resources.
The WLOC Controller and each Agent generate log messages that provide information about events such as service deployments, action failures, and other events. These messages are saved in log files that, by default, are located in the log sub-directory where the Agent or Controller was installed.
In addition, the Controller and Agents output messages to standard out. You can filter this output by message severity. For example, you can configure that only messages of WARNING severity or higher are output to standard out.
You can configure the following aspects of the logging feature:
The severity of messages to write to the log file. See Message Severity.
|
|
Path name of the log file. The path can be absolute or relative to the Controller or Agent installation directory.
To include a time and date stamp in the file name when the log file is rotated, add
java.text.SimpleDateFormat variables to the file name. Surround each variable with percentage (%) characters.
For example, if the file name is defined to be
myserver_%yyyy%_%MM%_%dd%_%hh%_%mm%.log, the log file will be named myserver_yyyy_mm_dd_hh_mm.log.
|
|
Rotation style to use for rotating log files. Valid options include By Size and By Time. For more information about log file rotation, see Rotating Log Files.
|
|
Maximum log file size (in KBs) before the current log file is rotated and a new log file is created. This value is valid only if the Rotation type was set to By Size.
|
|
The severity of log file messages to write to standard out. See Output to Standard Out and Standard Error and Message Severity.
|
Log messages can be viewed as follows:
The default location of Controller logs is the logs subdirectory where the Controller was installed.
The default location of Agent logs is the logs subdirectory where the Agent was installed.
| Note: | Do not modify log files by editing them manually. Modifying a file changes the timestamp and can confuse log file rotation. In addition, editing a file might lock it and prevent updates. |
When a Controller or Agent writes a message to its 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 Controller’s log file:
####<Oct 25, 2007 5:32:09 PM EDT> <Info> <LOCExecuteEngine> <> <>
<[ACTIVE] ExecuteThread: '1' for queue: 'weblogic.kernel.Default
(self-tuning)'> <> <> <> <1193347929031> <BEA-2010502> <Action
Succeeded:EmailNotificationAction([WLS-Cluster,ID=7111863992976504417],
WLS-Cluster,ID=-4438336769125385457) for event com.bea.adaptive.execute.internal.SyntheticServiceEvent@63bb71.>
In this example, the message attributes are: Locale-formatted Timestamp, Severity, Subsystem, Machine Name, Server Name, Thread ID, User ID, Transaction ID, Diagnostic Context ID, Raw Time Value, Message ID, and Message Text. For information about how these attributes are used, see Log Message Attributes.
If the message includes a stack trace, the stack trace is included in the message text.
WLOC uses the host computer’s default character encoding for the messages it writes.
In addition to writing messages to log files, a Controller or Agent can print a subset of its messages to standard out. Usually, standard out is the shell (command prompt) in which you are running the Controller or Agent. However, some operating systems enable you to redirect standard out to some other location.
You can filter this output by message severity. For example, you can configure that only messages of WARNING severity or higher are output to standard out. You can also configure whether WLOC prints stack traces to standard out.
When a Controller or Agent writes a message to standard out, the output does not include the #### prefix.
The log messages contain a consistent set of attributes as described in Table 8-2. In addition, if your application uses WebLogic logging services to generate messages, its messages will contain these attributes.
Indicates the degree of impact or seriousness of the event reported by the message. See Message Severity.
|
|
The severity attribute of a WLOC log message indicates the potential impact of the event or condition that the message reports. Table 8-3 lists the severity levels of log messages by severity, from lowest to highest.
By default, the Controller and each Agent renames (rotates) its log file when the file grows to a size of 500 kilobytes. Each time the log file reaches this size, the WLOC renames the log file and creates a new file-name.log to store new messages. By default, the rotated log files are numbered in order of creation file-namennnnn. You can configure WLOC to include a time and date stamp in the file name of rotated log files; for example, file-name-%yyyy%-%mm%-%dd%-%hh%-%mm%.log.
You can rotation file size, interval, and other properties based on the information in Table 8-1 and Table 8-4.
Some file systems place a lock on files that are open for reading. On such file systems, if your application is tailing the log file, or if you are using a command such as the DOS tail -f command in a command prompt, the tail operation stops after the server has rotated the log file. The tail -f command prints messages to standard out as lines are added to a file. For more information, enter help tail in a DOS prompt.
To help you and Oracle Customer Support diagnose problems with a WLOC environment, WLOC can output debug log messages that provide a detailed description of events in the runtime environment.
You can configure WLOC to output debug messages from all WLOC components or from specific components or scopes. WLOC writes debug messages to its log files and you can configure WLOC to print them to standard out.
By default, the WLOC Audit Service is enabled and writes audit events to an audit log file. The default name of the file is audit.log located in the logs directory where the Controller or Agent was installed. The current Controller audit log is exposed in the Administration Console. The Controller’s rotated audit logs and all Agent logs must be examined by directly accessing the file.
You can configure the Audit Service in the Administration Console. For the Controller, this is performed on the Controller’s Audit tab. For an Agent, it is performed on the Audit tab of the individual Agent. You specify name and rotation settings for Audit logs using the same settings as those used for Controller logs. For a description of these fields, see Table 8-1. In addition, you can specify the audit types and whether or not to enable auditing as described in Table 8-4.
|
For more information, see Audit Event Types.
|
The WLOC Audit Service generates and records audit events as described in Table 8-5.
The WLOC Audit Service uses message identifiers numbered 2014100 through 2014199 for all audit entries. Audit records begin with the #### marker and each field uses the < prefix and > suffix. Table 8-6 describes audit record fields.
|
Also see Audit Event Types.
|
|
####<Aug 20, 2007 2:11:24 PM EDT> <Info> <LOCAudit> <seacoast1> <Thread-19> <1187633484747> <ControllerAction> <BEA-2013411> <Configured Pipeline configName with Pipeline Identifier PipeID successfully completed execution at time Aug 20, 2007 2:11:24 PM EDT. Execution elapsed time was 10,000 milliseconds.>
For all active resources, the WLOC Administration Console provides flexible tools for designing and displaying charts and graphs. For active services, resource pools, JVMs, and MBean servers, you can specify a chart that displays:
| Note: | WLOC does not support monitoring Open MBeans. |
The Administration Console can display CPU and memory charts that indicate the performance of a service. For services managed by Plain Agents, you need to start up the JVM’s management server when you start the service’s processes. For information about how to do this, see JVM Arguments for Processes.
| Note: | The service must be using a JRockit JVM. |
For more information, see “ Monitor Resources” in the WLOC Administration Console Online Help.
By default, events are displayed at the bottom of the Administration Console page in the Task and Events viewer. This viewer displays up to the last 20 events that have occurred and is active no matter which tab is currently selected in the console. This viewer provides the same ability to filter messages that appear in it as provided on the Events page. You can also create custom viewing tabs with unique filters.
You can also can view events using the Events tab in the Console.
In addition, you may define Administrative policies that will cause the Console to generate console messages based on some constraint. For additional information, see Administrative Policies.
|