| Oracle® Web Services Manager Administrator's Guide 10g (10.1.3.3.0) Part Number E10299-01 |
|
|
View PDF |
| Oracle® Web Services Manager Administrator's Guide 10g (10.1.3.3.0) Part Number E10299-01 |
|
|
View PDF |
This chapter describes the information collected by Oracle Web Services Manager (Oracle WSM). This chapter includes the following sections:
The Oracle WSM components generate the following types of information:
Low-level event and state logs
High-level performance metrics
Each Oracle WSM component sends event execution and component status information to a local file dedicated to just that component. Such information is useful for monitoring the performance of your Oracle WSM system or debugging components that are not acting as expected. At various levels, this feature reports when the Oracle WSM Policy Manager starts or when a specific method is being executed, and it records a stack trace when certain errors occur.
The application log files can be found in the following location:
ORACLE_HOME/j2ee/instance/log
The variable instance is the name of the OC4J instance into which Oracle WSM is installed. If you install the standalone version of Oracle WSM, the default value of the instance is home.
There, you will find the log files shown in Table 8-1:
Table 8-1 Oracle WSM Application Log Files
| Log File Name | Contains Log Messages for |
|---|---|
|
ccore.log |
Oracle Enterprise Manager 10g Web Services Manager Control |
|
coreman.log |
Oracle Web Services Manager Monitor |
|
gateway.log |
Oracle Web Services Manager Gateway |
|
policymanager.log |
Oracle Web Services Manager Policy Manager |
|
clientagent.log |
Oracle Web Services Manager Client Agents |
|
serveragent.log |
Oracle Web Services Manager Server Agents |
By default, when you install Oracle WSM, the log files for the four components, Web Services Manager Control, Oracle WSM Monitor, Oracle WSM Gateway, and Oracle WSM Policy Manager are automatically created. The log files for the Oracle WSM agents are created only if you create and deploy client or server agents.
The maximum size of the log file is 10 megabytes, by default. When the log file reaches this maximum, a 1 is appended to the end of the file and messages continue to be logged to the application log file. For example, ccore.log would be renamed ccore.log.1, and messages would continue to be logged to ccore.log. By default, one backup file is created. Therefore, when ccore.log is renamed ccore.log.1, it overwrites any existing backup file with the name ccore.log.1.
You can configure the following characteristics of the log files: location and name of the log file (File), log level (priority value), log file size (MaxFileSize), and number of backup log files (MaxBackupIndex), by specifying the parameter in the parentheses in the logging.xml configuration file. Oracle WSM uses the Log4J technology developed by the Apache Group. Refer to the product documentation (http://logging.apache.org) for more information on configuring the log file parameters.
After you change any of the parameters in the logging.xml file, you must redeploy the application for the changes to take effect. See Oracle Web Services Manager Deployment Guide for information on deploying applications.
Logging Configuration Files
Each application has its own logging configuration file, named logging.xml, which you can use to configure logging. The location of the configuration files is as follows:
The logging configuration file for all Oracle WSM components (except Oracle WSM Agents) is found at:
ORACLE_HOME/owsm/config/application/logging.xml
The variable application is the name of the Oracle WSM application: ccore, coreman, gateway, policymanager.
The logging configuration file for OC4J agents (that is, server agents for an Oracle Web service and J2EE client agents) can be found at:
ORACLE_HOME/owsm/config/interceptors/component_ID/config/agent_type/logging.xml
The variable component_ID, is the component ID that is assigned to the agent when it is registered, and agent_type is clientagent or serveragent, specifying whether it is a client or server agent.
You can control the amount of low-level event and state information sent to file by specifying one of the following hierarchical logging levels:
SEVERE – Only events serious enough to cause a component failure are reported. Typically, these events are accompanied by a stack trace.
WARNING – Program activity that has not caused program termination, but which could potentially affect system performance or data integrity.
INFO – Confirmation of events that are supposed to occur (such as component startup, database connection, and so on). By default, the log level is set to INFO.
ALL – All events logged with SEVERE, WARNING, and INFO log levels are reported.
Note:
These values are case-sensitive and must be specified in uppercase.The log files allow you to specify a different logging level for each class. The following entries from the logging.xml file for Web Services Manager Control show the logging level set to INFO:
<category name="com.cfluent.webui">
<priority value="INFO" class="com.cfluent.ccore.util.logging.LogLevel"/>
</category>
<category name="com.cfluent.pingengine">
<priority value="INFO" class="com.cfluent.ccore.util.logging.LogLevel"/>
</category>
<root>
<priority value="INFO" class="com.cfluent.ccore.util.logging.LogLevel"/>
<appender-ref ref="FILE"/>
</root>
The logging level is specified with the priority value parameter. In most instances, you will not need to configure different log levels for specific classes. To change the log level for the entire component, do a search and replace to change the priority level for all classes to the desired level.
To change the log level for all Oracle WSM components except the third-party agents, see "Logging Configuration Files". To change the log level for third--party agents, see the "Changing the Log Level for Third-Party Agents" section.
Changing the Log Level for Third-Party Agents
Third-party agents are deployed in containers other than OC4J (for example, IBM WebSphere or BEA WebLogic). The procedure for changing the logging level for these agents is different from other Oracle WSM components. For third-party agents, the runtime configuration file for these agents is modified. Generally, Oracle recommends that you do not modify runtime files because these settings are overridden if and when the component is redeployed. However, in the case of third-party agents, it is cumbersome to edit the source configuration files and reinstall the agents for what is generally a temporary change to the log level while a problem is being debugged. Therefore, in this limited instance, Oracle recommends changing the log level in the runtime configuration files as described in the following:
Server Agents – The logging configuration file for server agents deployed on third-party containers is found in a directory where the Web service application is deployed. Navigate to the \WEB-INF folder for the deployed Web service application. Then navigate to the \WEB-INF\config\serveragent\logging.xml file.
J2SE Client Agents – The logging configuration file for J2SE client agents is found at:
\oracle\client\owsm\config\interceptors\component_ID\config\clientagent\logging.xml
The variable, component_ID, is the component ID that was assigned to the client agent when it was registered. After you change the log level, restart the client application.
Policy enforcement points (PEPs) send raw data to the Oracle WSM Monitor, where it is aggregated and compiled to produce high-level indicators pertaining to Web service availability, authentication and authorization results, request latency, and security violations. This information is useful to administrators who want to understand who is accessing the Web services managed by Oracle WSM and how these requests are being handled.
There are two general types of performance metrics:
Invocation Metrics – Collected each time a service is invoked.
Flow Metrics – Used to track transactions across an entire business process. Before this type of data can be collected, managed applications must be coded so that they embed flow IDs into all the SOAP message headers they generate.
For high-level performance metrics, your only option is to turn the feature on or off for all metrics. You cannot specify that individual metrics be collected or compiled.
As a feature of policy enforcement, agents and gateways log information from application messages through the use of logging steps specified in agent or gateway enforced policies. See Chapter 5, "Managing Oracle Web Services Manager Policies" for more information on configuring policy steps.
You can configure logging using one or both of the following:
Log step in the request pipeline that logs information from the service request.
Log step in the response pipeline that logs information from the service response.
You can add a Log step after any policy step within a pipeline and specify the level of logging for each Log step. Therefore, you can control the amount of information gathered.
You can set the logging function to send log data to one of the following:
Files located on the same computer as the enforcement component.
A database repository located on the network.
By default, the output is sent to the Oracle WSM Database. Optionally, you can send output to both the Oracle WSM Database and a local file.
By default, log files are stored in a logs directory; each log file name includes the time that the log reached its maximum size and log messages were written to the file.
To meet performance requirements, you should locate the message logs topologically close to the PEP. This implies that a highly distributed environment will require multiple distributed logs.
To send the log entries to a file, edit the cfluent.messagelog.type and cfluent.message.file.logDirectory properties for the policy enforcement point. For more information on editing these properties, see "Making Changes to Your Policy Enforcement Points".
The Asyncwriter writes log messages to the Oracle WSM Database. By default, the Asyncwriter has a buffer for 1000 log entries. If messages are being sent to the Asyncwriter at a faster rate than the Asyncwriter can write the messages to the database, some of these messages will be lost. This is likely to happen in the case where you are stress testing your Oracle WSM system. If this is the case, then increase the value of the cfluent.messagelog.asynwriter.maxEntries property for the policy enforcement point. See "Making Changes to Your Policy Enforcement Points" for more information on editing properties for Oracle WSM components.
