Skip navigation.
Downloads | Product Documentation | Support

Administration Guide

# Audit and Log Information

This chapter describes the auditing framework, performance profiling, and logging capabilities provided with the AquaLogic Data Services Platform (DSP). It contains the following sections:

- Auditing
- Monitoring the Server Log
- Monitoring a WebLogic Domain
- Using Other Monitoring Tools

For information on data service monitoring, see Monitoring Applications.

# Auditing

The auditing framework system is used to collect auxiliary runtime data using a normal XQuery operation in a DSP application. This information may be used for security auditing, performance profiling and other purposes.

## Audit Data Structure

The data structure comprises a sequence of audit records containing an unordered collection of audit properties. Each audit record contains properties of a specific type, usually identified using a hierarchal name. Each audit record corresponds to an operation performed by DSP. For example, access to a relational data source may generate a record of "evaluation/wrappers/relational" type that includes the following audit properties: sql, datasource, returnedRows, evaluationTime, parameters, message, and exception.

Any individual property may be configured to be collected. Each property has an individual intrinsic severity level that can be used to configure an overall threshold of what properties to collect. In certain cases, like when an exception occurs, some properties may be added to the record even if they are not configured to be collected. Typically, this information would be identifiers for a failed data source or update operation.

On the other hand, a property configured for collection need not necessarily be collected. This might be attributed to any one of the following reasons:

- Data might be unavailable due to internal implementation logic.
- A property is collected by an audit based on the need to record internal conditions, for external analysis.
- If an exception is encountered. This will result in an alternate execution path and impact the information being collected.

Elements of the data structure collected can be individually configured to be:

- Submitted to the WebLogic Server auditing framework and processed by an auditing provider.
- Written to an application server or system logging stream.
- Transferred to a client application.

Note: Auditing occurs whenever the engine is invoked and the Auditing option is enabled. Timestamps and other collected data enable you to match auditing information with particular query operations.

Use the DSP Console to configure application audits such as setting the global audit severity level and overriding audit settings for particular properties of interest.

The Auditing Tab (Figure 9-1) opens a page where you can select properties to be included in the DSP XQuery engine analysis, update, deployment, and re-configuration event audits. Auditing can be enabled or disabled for individual aspects of a query such as parameters or exceptions. There are also some global auditing options that inherently apply to every aspect of the auditing process.

Note: By default, the audit report generation utility is turned off. Before you begin generating reports for the first time, you need to specify the audit settings described in the subsequent sections. With auditing enabled, performance may be affected, depending on the audit levels and the number of properties being audited.

Figure 9-1 Auditing Options

## Setting Global Audit Properties

Table 9-1 describes available global auditing options. Click the respective check box in the DSP Console to select and implement the desired audit options.

Table 9-1 DSP Global Auditing Options

Options | Description
--- | ---
Enable Auditing | Determines whether the auditing is activated or not. Note: When auditing is enabled, performance can be affected to a degree, depending on the audit level and the number of items being tracked.
Audit Queries | Determines whether the auditing is activated or not, during a query evaluation.
Audit Administrative Actions | Determines whether the auditing is activated or not during administrative operations such as application deployment and configuration changes.
Audit Updates | Determines whether auditing is activated or not during update operations.
Severity Level | Determines the level of information to be captured by the auditing process. See Auditing Severity Levels section for more information.
Send Audit events Asynchronously | Determines whether the events are processed synchronously or asynchronously.
Enable Logging of Audit Events | Determines whether the auditing information is to be included in the application server log file. Note: If you enable this option (logging), ensure that the Log Level value in the General tab is set to either Info or Debug. Any other value will result in the log file not accepting any information.

## Setting Individual Auditing Properties

This section helps you determine which properties you want to audit and to what level. You can propagate generic audit settings through the Configure all Properties row, details of which are listed in Table 9-2. Or, you can set the audit settings at the individual properties level, details of which are shown in Table 9-1.

Table 9-2 Configuring all Audit Properties

Option | Description
--- | ---
Allow return to Client | Click this checkbox to ensure the property-specific audit information is returned to the client API.
Auditing Mode | This drop-down list has three options, which are generic to all the properties. The options are At Default Level, Always, and Never. By selecting At Default Level, levels of all the individual properties will be set to pre-determined default levels. See Table 9-1 for more information on each level.

Note: After you set and apply individual auditing property settings, any changes you make on the individual properties will override the initial settings for that property only.

Table 9-1 lists the audit levels that you can set on each individual property. All levels listed in the table are not applicable to all the properties. Typically, each property has only three levels to choose from.

Table 9-1 Setting Individual Audit Properties

Level | Description
--- | ---
Always | In this setting, the audit information of the property is always collected.
Never | In this setting, the audit information of the property is always ignored.
At Info Level | In this setting, the audit information is collected if the global threshold level is Information or lower.
At Warning Level | In this setting, the audit information is collected if the global threshold level is Warning or lower.
At Failure Level | In this setting, the audit information is collected if the global threshold level is Failure or lower.
At Debug Level | In this setting, the audit information is collected if the global threshold level is Debug.

All the individual properties are categorized into four overall types (Admin, Common, Query and Update), depending on the corresponding operation that generates the audit data.

### Admin

The audit information in this section pertains to the information exchanged while performing administration tasks such as configuration and application deployment. Only changes to the application made in the DSP Console are collected during audit.

Table 9-3 Administrator Properties

Property | Description
--- | ---
Configuration
notification | Records notification of deployed access control resource. For example: `notification: jmx.attribute.change property: MAXNUMBEROFQUERYPLANCACHED value: 101`
plancacheflushed | Notifies when the query plan was flushed. For example: `plancacheflushed: true`
property | Records any instance of the property that was changed in the DSP Console. For example: `notification: jmx.attribute.change`
value | Records a new value instance, for example: `value: 101`
Deployment
application | Records the deployed application name. For example: `application: RTLApp`

### Common

The audit information in this section pertains to the generic transaction related information. It includes generic information on the event, such as: event type, application name, user id, user access rights, date, and time.

Table 9-4 Common Properties

Property | Description
--- | ---
Application
name | Records the deployed application name. For example: `name: RTLApp`
eventkind | Records the type of event or operation, it could be a query or an update and so on. For example: `eventkind: evaluation`
principals | Records the groups to which the user belongs. For example: `principals: weblogic Administrators IntegrationAdministrators PortalSystemAdministrators`
user | Records the user id, for example: `user: weblogic`
server | Records the application server's unique id. For example: `server: cgServer`
exception | Records the exception message, if one occurred. For example: `exception: ld:DataServices/ApparelDB/CUSTOMER_ORDER_LINE_ITEM.ds, line 77, column 7: {err}FORG0005: expected exactly one item, got 0 items`
transactionid | Records the unique transaction id for the event or operation.
Security Access
resourcetype | Records the type of resource used, like dataservice, application, submit and so on. For example: `resourcetype: function`
resource | Records the request for resource identifier. For example: `resource: <ld type="function"><app>RTLApp</app><ds>ld:DataServices/CustomerDB/ADDRESS.ds</ds><res>{ld:DataServices/CustomerDB/ADDRESS}ADDRESS:0</res></ld>`
decision | Records the security access settings for the application, for example: `decision: PERMIT`
Time
duration | Records the time used to complete the audit event, in milliseconds. Calculates the time difference from initiation of the audit to its completion. For example: `duration: 2834`
timestamp | Records the time when the audit event was initiated, for example: `timestamp: Tue Feb 14 09:21:02 IST 2006`

### Query

The audit information in this section pertains to all the information collected during query evaluation. The information includes the query itself, its result, the execution time, and details on the data source queried.

Note: When using the streaming APIs, or when using the `RequestConfig.OUTPUT_FILENAME` feature, the results of the query are not audited since they are presumed to be very large. This means the AuditEvent dispatched to the audit provider, as well as the DataServiceAudit returned to the client, will not contain a value for the audit property Query/Service/results.

Table 9-5 Query Properties

Property | Description
--- | ---
Adhoc
query | Records the query that was executed.
result | Records the results obtained after execution of the query.
variablenames | Records names of the variables passed to the query.
variables | Records the external parameters or variables passed to the query.
Cache Data
forcedrefresh | Boolean value where `TRUE` indicates the data is from a current data source or `FALSE` if it is from a cache.
functionid | Records the name of the function.
remainttl | Indicates the time remaining, in seconds, before the query cache is refreshed.
retrieved | Indicates whether the data was obtained from the query cache or not.
Queryplan | Note: Queryplan audit properties are not collected when a function is executed from Test View in Workshop. This is because the function cache is not utilized for functions executed in Test View.
found | Indicates whether the query plan cache has been located or not.
inserted | Indicates whether the query plan cache has been inserted or not.
Failover
exception | In the event of a failover, this records the exception that caused it.
function | Records the function name which can be either `fn:bea:timeout` or `fn:bea:fail-over`. For example: `function: {http://www.bea.com/xquery/xquery-fncts}timeout-with-lbl`
label | Records the user-defined label, if any. For example: `label: lab`
sourcecolumn | Records the source column of the function call. For example: `sourcecolumn: 2`
sourcefile | Records the source file of the function call. For example: `sourcefile: [ad-hoc]`
sourceline | Records the source line of the function call. For example: `sourceline: 4`
timeout | Records the time-out that was exceeded, if applicable. For example: `timeout: 0`
Function | Note: Function audit properties are collected only when the individual functions of a data service are selected for auditing. See Auditing Functions for more information.
name | Records the name of the audited function. For example: `name: {ld:DataServices/CustomerDB/CUSTOMER}getCustomer`
parameters | Records the parameters passed through the audited function. For example: `parameters: CUSTOMER1`
result | Records the result after executing the audited function. For example: `result: <ns0:CUSTOMER`
Performance
compiletime | Records the query compilation time, in milliseconds. For example: `compiletime: 19`
evaltime | Records the query evaluation time, in milliseconds. For example: `evaltime: 90`
Service
dataservice | Records the name of the data service, for example: `dataservice: ld:DataServices/RTLServices/ApplOrder.ds`
function | Records the function name of the data service, for example: `function: getCustomer`
parameters | Records the parameters passed through the query, for example: `parameters: 1 foo`
query | Records the complete text of the executed query on the data service, for example: `query: import schema namespace t1 = "urn:retailerType" at "ld:DataServices/RTLServices/schemas/ApplOrder.xsd"; declare namespace ns0="ld:DataServices/RTLServices/ApplOrder";`
result | Records the results of the executed query, for example: `ORDER_10_0 CUSTOMER0 2001-10-01 GROUND`
Wrappers File
exception | Records an exception, if any, when a function invoked belongs to a data service created over a File data source. For example: `exception: com.bea.ld.wrappers.df.exceptions.DFException: {bea-err}DF0004: [ld:DataServices/Demo/Valuation.csv]: Expected end of line at (row:2, column:3).`
name | Records the unique function name. For example: `name: ld:DataServices/Demo/Valuation.csv`
time | Records the time taken to query, in milliseconds. For example: `time: 20000`
Java
exception | Records an exception, if any, when a function invoked belongs to a data service created over a Java class. For example: `exception: {ld:DataServices/Demo/Java/Physical/PRODUCTS}getFirstProduct:0, line 4, column 5: {bea-err}JFW0401: Class or Method not found exception : {ld:DataServices/Demo/Java/Physical/PRODUCTS}getFirstProduct`
name | Records the name of the service. It is always recorded if an exception property was added. For example: `name: public static int Demo.Java.JavaSource4West.echoInt(int)`
parameters | Records the external parameters passed to the service. For example: `parameters: 11`
result | Records the results of the executed query. For example: `result: 11`
time | Records the time taken to execute the query, in milliseconds. For example: `time: 20000`
Procedure
datasource | Records the name of the data source, for example: `datasource: newDS`
exception | Records an exception, if any, when a function invoked belongs to a data service created over a stored procedure. For example: `exception: weblogic.xml.query.exceptions.XQueryDynException: {err}XP0021: "-ss": can not cast to {http://www.w3.org/2001/XMLSchema}decimal}`
name | Records the procedure identifier. It is always recorded if an exception property was added. For example: `name: WIRELESS.SIDEEFFECT_REG_PACKAGE.READ2`
parameters | Records the external parameters passed to the data service method. For example: `parameters: s 2.2 22.0 ss`
rows | Records the number of rows returned after execution of the procedure, for example: `rows: 0`
time | Records the time taken to execute the procedure, in milliseconds. For example: `time: 170`
Relational
exception | Records the relational database query exception, if any. For example: `exception: com.bea.ld.wrappers.rdb.exceptions.RDBWrapperException:`...
parameters | Records the external parameters passed through to the data service method, for example: `parameters: ORDER_10_0 ORDER_10_1`
rows | Records the number of rows returned from the relational database, for example: `rows: 60`
source | Records the database source name. It is always recorded if an exception property was added. For example: `source: cgDataSource1`
sql | Records the SQL statement used for the query, for example: `sql: SELECT '1' AS c15, t2."LINE_ID" AS c16, t2. FROM "RTLAPPLOMS"."CUSTOMER_ORDER_LINE_ITEM" t2 WHERE ((? = t2."ORDER_ID") OR (? = t2."ORDER_ID")`
time | Records the time spent executing the query, in milliseconds. For example: `time: 5000`
WS
exception | Records an exception, if any, when a function invoked belongs to a data service created over a web service. For example: `exception: {bea-err}WSW0101: Unable to create Call : {ld:DataServices/ElectronicsWS/getCustomerOrderResponse}getCustomerOrder`
operation | Records the data service method that is executed. For example: `operation: getCustomerOrder`
parameters | Records the parameters passed through to the data service method. For example: `parameters: <ns0:getCustomerOrder xmlns:ns0="http://www.openuri.org/">`
result | Records the result returned after the query is executed. For example: `result: <ns:getCustomerOrderResponse xmlns:ns="http://www.openuri.org/"> <CustOrders xmlns="http://temp.openuri.org/SampleApp/CustOrder.xsd"> <ORDER> <ORDER_ID>ORDER_1_0</ORDER_ID> <CUSTOMER_ID>CUSTOMER1</CUSTOMER_ID>`
time | Records the time spent executing the query, in milliseconds. For example: `time: 50000`
wsdl | Records the web service description. For example: `wsdl: http://localhost:7001/ElWS/cntrls/ElDBTest.jws?WSDL`

#### Auditing Functions

By default, auditing for all directly invoked functions can be enabled through the /query/service record in the application Audit tab. However, to limit auditing to specific functions, set all properties of the /query/service record to NEVER and then enable audit for individual functions by selecting the Enable Audit check box as shown below.

If auditing for a function is enabled, all external calls to this function are audited. If the Enable Audit of Indirect Calls check box is selected, all calls originating from other data services are also audited.

Note: Enabling audit of indirect calls may disable query optimization for that function, and decrease performance.

### Update

The audit information in this section pertains to all the information related to performing an update function. It includes information on the time taken to update the source, when it was started, the unique transaction id and so on.

Table 9-6 Update Properties

Property | Description
--- | ---
Extension
id | Records the id of the source being updated.
time | Records the time spent, in milliseconds, for the update.
Relational
exception | Records the update exception, if any.
parameters | Records the parameters passed during the update of the relational database.
rowsModified | Records the number of rows updated in the relational database, on successful completion.
source | Records the data source name. It is always recorded if an exception property was added.
sql | Records the SQL statement used during the update of the relational database.
time | Records the time spend, in milliseconds, in updating the relational database.
Service
dataservice | Records the data service used for the update.
sdoCount | Records the number of top level SDOs that were submitted for the update.
time | Records the total execution time, in milliseconds, for the update.

Table 9-7 DDSP Record and Property Auditing Options

Option | Description
--- | ---
Audit Level | Every audit property is set to one of the following audit levels: Always. This setting over-rides the default audit level but not the global enabled/disabled setting. Default. Follows the global default severity level setting. Never. Ignores the global default severity level setting. Note that, in some error and failure cases, auditing of a properties behavior may be reported or ignored, despite its audit level setting.
May Be Returned | Determines if a particular property may be returned to the client application.
Description | Provides a brief description of the property.

## Auditing Severity Levels

Severity levels are similar to those provided with WebLogic Server security. For WebLogic Server details, see "Message Severity" section in:

>     http://e-docs.bea.com/wls/docs81/ConsoleHelp/logging.html#1037756

Table 9-8 DSP Audit Severity Levels

Level | Description
--- | ---
Debug | This setting is often referred to as "verbose". Any audit property that can be added to the audit report is collected.
Information | Properties with information or higher conditions are collected for the audit report.
Warning | Properties with warning or higher conditions are collected for the audit report.
Failure | Properties with error or more higher conditions are collected for the audit report.

## Retrieving Audit Information

You can record the audit information collected in the following ways.

- WebLogic Server Security Framework. Each audit event is by default reported to the WebLogic Server Security Framework.
- DSP Client API. You can create a DSP client API to record the information collected during audit.
- DSP Performance Profiling. You can use the DSP audit provider for performance profiling by recording audit events generated by an application.

Values of the audit properties are represented as Java objects of types: String, Integer, java.util.Date, Boolean, or String [].

### WebLogic Server Security Framework

Each audit event is sent to the WebLogic Server Security Framework as an instance of the `weblogic.security.spi.AuditEvent` interface, where:

####

`getEventType()` | Returns the event type, in this case `DSPaudit`.
`getFailureException()` | Returns the exception type, if one is encountered.
`getSeverity()` | Returns the event severity level.
`toString()` | Returns the audit event details in an XML formatted representation.

Depending on the configuration, each event can be sent to the WebLogic Server audit API asynchronously and buffered by the DSP application.

The weblogic.security.spi.AuditEvent interface is implemented in the ld.server.audit.DSPAuditEvent interface, which collects all the information in the form of a list, where each entry is an instance of com.bea.dsp.DSPAuditEvent.

DSPAuditEvent adds the following interface:

####

`getAllRecords()` | Returns all records as a list of `com.bea.ld.DSPAuditRecord`.
`getRecords(String recordType)` | Returns all records of a particular type as a list of `com.bea.ld.DSPAuditRecord`.
`getProperty(String propertyId)` | Returns all values for a particular property, across multiple records.
`getApplication()` | Returns the DSP application identifier.
`getUser()` | Returns the user name of the application server user.
`getTimeStamp()` | Returns the time when the event was created.
`getEventKind()` | Returns the event type, which can be `EVALUATION_EVENT`, `CONFIGURATION_EVENT` or `UPDATE_EVENT`.
`getVersion()` | Returns the event version, for example `2.1` for the DSP 2.1 release.

com.bea.ld.DSPAuditRecord has the following API:

####

getRecordType() | Returns the type of record, for example common/time/duration.
getAuditProperties() | Returns all properties in the record. Maps from String identifier to Object value.

A sample security services audit provider is included that demonstrates use of this API.

### DSP Client API

You can use the com.bea.ld.DataServiceAudit client side instance as part of the com.bea.dsp.RequestConfig class, to collect the audit information from the client API. This class collects the audit information and returns it when the operation is successful. If the operation fails for any reason, the com.bea.ld.QueryException class can be used to collect the information as part of the exception thrown.

Note: When using Streaming APIs, auditing will not be complete until the returned XMLInputStream has its close( ) method called. This means that the AuditEvent will not be dispatched to the audit provider by the server, and the RequestConfig.getDataServiceAudit() method will return null, until close( ) is called.

Following are the four steps, with code examples, that need to be performed in order to retrieve audit information.

#### Initializing the RequestConfig Class

You need to initialize the RequestConfig class as shown in the code example below:

`RequestConfig requestCfg = new RequestConfig();
requestCfg.enableFeature(RequestConfig.RETURN_DATA_SERVICE_AUDIT);
requestCfg.enableFeature(RequestConfig.RETURN_AUDIT_PROPERTIES);
requestCfg.setStringArrayAttribute(RequestConfig.RETURN_AUDIT_PROPERTIES, new String[]
{"query/service/dataservice"});`

#### Passing the RequestConfig Object

You need to pass the RequestConfig object to the invoked operation. The code example below uses getCustomer as the invoked operation.

`CUSTOMERDocument [] custDocRoot1 = (CUSTOMERDocument [])custDS.invoke("getCustomer", params, requestCfg);`

#### Filtering Audit Data

You need to filter the data and ensure there is no unsecured access to it. Only those audit properties that are configured in the Data Services Platform Console to be allowed to return to the client, will be returned to the client application.

#### Retrieving Data Service Audit

You need to retrieve the data service audit from the RequestConfig object, as shown in the code example below:

>     DataServiceAudit query = requestCfg.retrieveDataServiceAudit();

#### Retrieving Audit Properties

RequestConfig.RETURN_AUDIT_PROPERTIES is an array of string identifiers for audit properties. If you set this request attribute those specified properties will be collected for this particular evaluation even if they are not configured to be collected through the administration console. They will be returned only if it is allowed. If the RETURN_DATA_SERVICE_AUDIT request attribute is not enabled, only those properties will be returned.

RequestConfig.RETURN_DATA_SERVICE_AUDIT configures all collected audit information (that is allowed to be returned to the client application) to be returned.

### DSP Performance Profiling

Performance profiling allows you to store select audit information in a relational database. Relational databases supported by the DSP audit provider are: Oracle, DB2, PointBase, Sybase, and MS SQL.

Information about audit events are stored as records in a table. A table can be used to record audit events for DSP applications running on a server, or for applications running on shared servers in a cluster.

You can deploy the DSP audit provider for performance profiling using the WebLogic Administration Console and configure it using the DSPProfiler MBean. Configuration parameters you need to set at the time of deployment are described in Table 9-9.

Table 9-9 Configuration Parameters for Performance Profiling

Parameter | Description
--- | ---
Data Source | Name of the JDBC data source.
Table | Name of the table in the JDBC data source that logs query execution information.
Source Table | Name of the table in the JDBC data source that logs source access information.
Summary Table | Name of the table in the JDBC data source that logs aggregated information (summary).
Event Buffer | Size of the internal event buffer. Determines the number of events a buffer stores before the profiler starts processing events.
Collect Execution Aggregate | Stores aggregates (by function) of individual query executions in memory; eventually writes the aggregate to the database.
Aggregate Group Size | Number of events processed by the profiler before the aggregates are written to the database. Default value is 10.
Collect Execution Detail | Writes a row to the database for every query execution, including aggregate of source access within the query. Useful in application development environment.
Collect Source Detail | Writes a row to the database for every source access in a query. Collect Execution Detail needs to be configured for this parameter to take effect.

#### Creating a Performance Profiler

This section lists the steps needed to create a performance profiler.

1. Create a table to store the following audit properties:

- `common/time/timestamp`
- `query/service/function`
- `query/performance/evaltime`
- `common/application/user`
- `common/application/name`
- `common/application/server`

In addition to the above mentioned properties, you will also need to store:

- information about the audit event exception, if any.
- audit event severity level, which can be of types I (Information), W (Warning), S (Success), E (Error), F (Failure).

2. Modify the CLASSPATH to include a pointer to the JAR file.
3. Start WebLogic Server.
4. In the Audit page, configure the database tables as required.
5. In the Security Providers page of the WebLogic Administration Console, configure a DSP audit provider. See Table 9-9 for details.
6. Restart your WebLogic Server.
7. Run the data service application and use the applicable database visualizer to view the results.

#### Using the Sample Performance Profiler

A DSP audit provider sample file `profiler.zip`, is available in the DSP root installation directory. The zip file contains the following files:

- `README.txt` lists steps to use the sample audit provider).
- `dsp_profile.sql` files - Contains table definitions.
- `build.xml` - Defines build configurations.
- `DSPProfilerMBean.xml` - MBean definition file for the DSP profiling auditor.
- `DSPProfilerImpl.java` - Sample java code that implements the weblogic.security.spi.AuditProvider and weblogic.security.spi.AuditChannel interfaces.

# Monitoring the Server Log

Server log files contain information about the time spent to compile and execute a query. The log is in the following location:

>     <BeaHome>\user_projects\domains\<domainName>\<serverName>\<server>.log

For more information about WebLogic Server logs, see "Viewing the WebLogic Server Logs" at:

http://e-docs.bea.com/wls/docs81/logging/viewing.html

You can configure the log levels, by application, using the General application configuration page. For more information, see General Application Settings. The log levels include:

- Error. Runtime exceptions.
- Notice. Possible errors that do not affect runtime operation, as well as error level events.
- Information. Start/stop events, unsuccessful access attempts, query execute times, and so on, as well as error and notice level events.

Debug logging occurs by default for any server in development mode. Client applications can contribute to the server log through the WebLogic Logger facility. For more information, see "Using WebLogic Logging Services at:

http://e-docs.bea.com/wls/docs81/logging/use_log.html

Query strings are echoed in the server log as a debug-level log message when the log level is set to Information in the DSP Administration Console and the WebLogic Administration Console is set to log debug messages to stdout.

# Monitoring a WebLogic Domain

You can use the WebLogic Server Administration Console to monitor the health and performance of the domain in which WebLogic is deployed, including resources such as servers, JDBC connection pools, JCA, HTTP, the JTA subsystem, JNDI, and Enterprise Java Beans (EJB).

The domain log is located in the following directory:

>     <BeaHome>\user_projects\domains\<domainName>\<domainName>.log

For more information, see Monitoring a WebLogic Server Domain in Configuring and Managing WebLogic Server.

# Using Other Monitoring Tools

You can use performance monitoring tools, such as the OptimizeIt and JProbe profilers, to identify Data Services Platform application "hot spots" that result in either high CPU utilization or high contention for shared resources.

For more information, see Tuning WebLogic Server Applications. For a complete list of performance monitoring resources, see Related Reading in WebLogic Server Performance and Tuning.