This chapter examines the following:
This section explores the ADP User Interface. Topics include:
To access the Enterprise Manager Application Dependency and Performance (ADP) feature, do the following:
From the Targets menu, select Middleware.
From the Middleware Features menu on the Middleware page, select Application Dependency and Performance.
ADP UI consists of the following core components:
Navigation Pane (left)
There are three types of workspaces in the ADP navigation pane: Monitoring, Configuration, and Registration. In the Monitoring workspace, you can navigate the managed environment and monitored applications in a tree.
Use the Monitoring workspace to traverse the ADP tree model and identify abnormal activities.
Use the Configuration workspace to create, modify, and review various configuration settings for ADP.
Use the Registration workspace to enable and disable request monitoring.
Main Display Window (right)
As you navigate through the ADP tree model and configuration categories, detailed performance information and configuration settings are displayed in the Main Display Window. You can refresh the Main Display Window at anytime by clicking the Refresh icon.
The Operational Dashboard displays the health indicators for various key entities in the managed environment. ADP uses traditional traffic light colors to represent the health of these various key entities.
For each component, ADP uses the following health indicators to provide a comprehensive view. These health indicators are:
Performance
The performance health indicator depicts the relative responsiveness of the monitored entity to the configured threshold.
Availability
The availability health indicator informs you to what extent a particular entity is available to service requests. The Availability arrow explains the availability of the particular entity: Red down arrow means the entity is not available whereas the Green up arrow means the entity is available.
Errors
The errors health indicator informs you if the number of errors and exceptions encountered by this entity are approaching or violating the configured threshold. If there is any errors in the server, the check mark is in red.
Load
The load health indicator depicts how many operations have been performed and requests have been served by a particular entity.
ADP is aware of clusters. As such, these indicators display overall health of a particular entity across the entire cluster.
In ADP, you can specify the length of the time the window information is to be displayed. To specify the length of this time window, select the appropriate length in the Time Frame list. The following Time Frame values are available:
1 hour
2 hours
4 hours
8 hours
12 hours
24 hours
Note:
The ADP default data collection interval is 60 seconds. As you adjust the data collection interval, ADP automatically adjusts the display time frames.ADP automatically adjusts information displayed to fit the specified time window. You can drill down to see detailed performance information for a specific range of time.
For example, visualize the drill down process with two screen shots of the same graph with different Time Frames of the average response time for Portal campaign. The first graph has a Time Frame of 24 hours. The second graph has a Time Frame of 1 hour. By increasing the granularity of the Time Frame, you are performing a drill down operation.
For example, an IT Operations staff noticed abnormally high response time with Portal campaign subsystem. The person decided to investigate further to evaluate the extent of the problem. By changing the Time Frame from 24 hours to 1 hour, this user is able to see that between 14:17 and 14:18, the Portal campaign response time jumped from an average of 1000 milliseconds to 5000 milliseconds. While the problem did not persist, it may warrant additional investigation.
Display Interval, located above the Main Display window, indicates the start and end time for the data displayed in the Main Display Window. Display Intervals change as you change the following settings:
Time Frame
Interval Context
Turning Off Time Frame Limitation
When you select a new Time Frame, the Display Interval automatically changes to fit the selected Time Frame. For example, if you were to change the Time Frame from 1 hour to 2 hours, the Start value of the Display Interval changes.
Display Interval can also be changed by setting the Interval Context. The settings for the Interval Context are:
End Time Is Current System Time
The default Interval Context for ADP is to use the current system time as End value for the Display Interval. In this default setting, you have a sliding Display Interval and can see the latest performance information in the Main Display Window.
End Time Is Fixed
You can also change the Interval Context setting to use a fixed time as the End value for the Display Interval. By selecting the fixed Interval Context, you can create a fixed time window to display performance data. The fixed time window is particularly useful for performing analytical tasks.
Date/Time Selector
When you select to fix the End time for the Interval Context, the ADP UI enables a pair of Date/Time Selectors to allow you to set Start or End values for the Display Interval. Click the icon next to the Start and End times to open up the Date/Time Selector.
The Date/Time Selector allows you to set a specific Display Interval to fit your needs. Additionally, the Date/Time Selector enables ADP to compare current performance trends with historical data.
Note:
Changing the start and end time do conceptually different things. Users are advised to always change their time frame by modifying the end time first, and then the start time. Changing the end time moves the window in time, whereas changing the start time increases/decreases the size of the window.To support the display of data for more than twenty four hours, ADP allows you to specify your own time frame for data display. To enable this feature, set Interval Context to End time is fixed and make sure the Use time frame: check box is unchecked. Turning off time frame limitation allows ADP to display eight days worth of data.
For example, when you specify the time frame to be eight days by adjusting the start and end times through the Date/Time Selector, ADP then adjusts its view to display eight days worth of data in a single graph. This feature allows you to perform trending analysis over time.
ADP displays performance information in various formats. Most commonly used display formats in ADP are tables and graphs.
On graphs, you can gain more information about a data item by pointing the mouse over the interested item.
Minimum and maximum response time measurements are stored in their database in addition to average response time measurements. The min and max metrics, if present, are displayed visually in the UI.
For tables, you can perform a table sort by clicking the blue up/down arrow located in the column headings.
While ADP intelligently selects relevant performance metrics based on its SOA Suite and ADF application framework metadata, you can further customize the monitoring environment by configuring additional custom metrics. In addition, you can use custom metrics in problem diagnostic situations where additional visibility is needed to pinpoint problem root cause.
To configure a new custom metric:
Click Custom Metric Configuration on the Configuration tab
Click the Create Custom Metric button.
On the Custom Metric File page, either choose an existing custom metric file or provide the name of a new custom metric file. Click Continue. ADP walks you through the configuration process.
Custom Metric Configuration page includes the following fields, see Table 39-1.
Table 39-1 Custom Metric Configuration Page
| Field | Description |
|---|---|
|
Name |
This text field is for defining the display name for the custom metric. |
|
Resource Name |
This list is for defining the resource where the custom metric will be collected. |
|
Class Name |
This text field is for defining the fully qualified class name (package + class) associated with the custom metric. |
|
Method Name |
This optional text field is for defining the method name associated with the custom metric. Usage:
Method field examples:
|
After you define the custom metrics, restart the application server instances associated with these customizations. The new custom metrics will be listed under the Custom Metrics node in the ADP navigation tree.
The newly configured custom metric provides class level performance data, for example invocation count and response time.
Functional View is a type of Application Schema Visualization - a visual way for ADP to represent the information stored in its Application Schema model. This view is designed to help you understand how business functions are assembled with various functional building blocks. Table 39-2 provides a list of functional views currently available in ADP.
| Entity Type | Description |
|---|---|
|
SOA Composite |
This functional view depicts the SOA services, references, and components in a SOA composite along with their associated wiring. |
|
BPEL Component |
This functional view depicts the activities associated with a BPEL component. |
Depending on the type of entity selected, ADP displays different functional views. Right-click and select Display Functional View to bring up the relevant Functional View associated with the selected entity.
Table 39-3 describes various types of metrics provided by ADP.
Note: All the ADP metric tables have a View drop-down list to change the order of the columns in the tables.
| Examples | Metric Type | Metric Description |
|---|---|---|
|
Active Sessions Completions Pending Requests Running Instances Max Capacity Messages High |
A count of the monitored entity at a point in time. ADP plots these snapshot counts in trend graphs. |
|
|
Requests Serviced Total Sessions [Processes] Aborted [Processes] Terminated [Method] Invocation Count Bytes Received |
A count of the monitored entity incrementally aggregated from the beginning of display time window. ADP shows these aggregated counts in summary tables. |
|
|
Response Time Elapse Time Connection Delay |
Calculated every sampling period (default 60 seconds), the average timing is calculated by dividing the total amount of time needed to complete the monitored business unit of work by the number of completed business units of work. ADP uses this data in the following two ways:
|
|
|
Min/Max |
Minimum and maximum response time measurements found per collection sampling intervals. These are stored in their embedded database in addition to average response time measurements. The default is 60 seconds. |
When ADP is pointed to an Oracle WebLogic domain or an Oracle SOA Suite cluster, it automatically discovers information about this particular domain including all deployed applications, configuration, resources, and others. ADP displays this information in the Monitoring tab under Oracle Enterprise Manager.
Each node represents a construct in the platforms monitored by ADP. Each construct is described in this section.
Note: Promote to dashboard can be configured in ADP to incorporate ADP metrics tables in the ADP dashboard page. The dashboard configuration can be selected for the entity type which is discovered by ADP and to display the entity metrics table on the dashboard.
This section includes the following topics:
To monitor the performance of service-oriented architecture applications (SOA), perform the following steps:
Navigate to Application Dependency and Performance.
From the Targets menu, select Middleware. On the Middleware page, click the SOA Infrastructure target. On the Home tab, select the Summary region and click the Application Dependency and Performance link.
Click the Monitoring tab.
ADP discovers all the deployed Composites on the configured Oracle WebLogic Domain.
A Composite node appears under the configured ADP Manager (for example, select Oracle Enterprise Manager, select SOAServer, then select Composites).
Under the Composites node, the following nodes appear:
SCA Partition
Composite
Services
Components
References
Wires
The performance metrics are displayed on the right-hand side panel when the respective node is selected.
To monitor the performance of Oracle Service Bus (OSB) applications, perform the following steps:
Navigate to Application Dependency and Performance.
From the Targets menu, select Middleware. On the Middleware page, click the OSB target. On the Home tab, select the Summary region and click the Application Dependency and Performance link.
Click the Monitoring tab, then select OSB in the tree.
ADP discovers all the deployed OSB proxy and business services on the configured Oracle WebLogic Domain.
An OSB node appears under the configured ADP Manager (for example, select Oracle Enterprise Manager, select servicbusServer, then select OSB).
Under the OSB node, the following nodes appear:
Business Services
Proxy Services
Pipeline
References
The performance metrics are displayed on the right-hand side panel when the respective node is selected.
The ADF node in the navigation tree contains information about all the ADF-based applications running in managed domains.
| Component | Description |
|---|---|
|
ADF Business Components |
ADF business component |
|
ADF Data Controls |
ADF data controls |
|
ADF Taskflows |
ADF task flows provide a modular approach for defining control flow in an application. See Section 39.2.3.1, "ADF Task Flows". |
|
JSF Pages |
JSF page definition files define the binding objects that populate the data in UI components at runtime. See Section 39.2.3.2, "JSF Pages". |
Instead of representing an application as a single large JSF page flow, you can break it up into a collection of reusable task flows. Each task flow contains a portion of the application's navigational graph. The nodes in the task flows are activities. An activity node represents a simple logical operation such as displaying a view, executing application logic, or calling another task flow. The transactions between the activities are called control flow cases. A task flow consists of activities and control flow cases that define the transitions between activities.
The following taskflows are available in ADF.
Table 39-5 Taskflow Activities
| Activity Name | Description |
|---|---|
|
Managed Beans |
A backing bean that is managed by the JSF framework and used during the JSF page lifecycle. |
|
Taskflow Method Calls |
Invokes a method, typically a method on a managed bean. |
|
Taskflow Views |
Displays a JSF page or page fragment. Multiple view activities can represent the same page or same page fragment. |
|
Taskflow URL Views |
Redirects the root view port (for example, a browserpage) to any URL-addressable resource, even from within the context of an ADF region. |
|
Taskflow Calls |
Calls an ADF bounded task flow from an ADFunbounded task flow or another bounded task flow |
|
Routers |
Evaluates an EL expression and returns an outcome based on the value of the expression. For example, a router in a credit check task flow might evaluate the return value from a previous method call and generate success, failure, or retry outcomes based on various cases. These outcomes can then be used to route control to other activities in the task flow. |
Oracle ADF provides a wide range of Web 2.0 capabilities, including discussion forums, wikis, blogs, content services, RSS, presence, instant messaging, linking, tagging, and search. Both developers and business users can easily add these services to their pages to maximize productivity.
Table 39-6 Taskflow Activities
| Activity Name | Description |
|---|---|
|
Managed Beans |
A backing bean that is managed by the JSF framework and used during the JSF page lifecycle. |
|
Taskflow Method Calls |
Invokes a method, typically a method on a managed bean. |
|
Taskflow Views |
Displays a JSF page or page fragment. Multiple view activities can represent the same page or same page fragment. |
|
Taskflow URL Views |
Redirects the root view port (for example, a browserpage) to any URL-addressable resource, even from within the context of an ADF region. |
|
Taskflow Calls |
Calls an ADF bounded task flow from an ADFunbounded task flow or another bounded task flow |
|
Routers |
Evaluates an EL expression and returns an outcome based on the value of the expression. For example, a router in a credit check task flow might evaluate the return value from a previous method call and generate success, failure, or retry outcomes based on various cases. These outcomes can then be used to route control to other activities in the task flow. |
A typical JSF application couples a backing bean with each page in the application. The backing bean defines properties and methods that are associated with the UI components used on the page. The UI component's value is bound to the bean's property.
A Managed Bean is a backing bean that is managed by the JSF framework and used during the JSF page lifecycle.
To monitor the performance of Application Development Framework (ADF) applications, perform the following steps:
Navigate to Application Dependency and Performance.
From the Targets menu, select Middleware. On the Middleware page, click the ADF target. On the Home tab, select the Summary region and click the Application Dependency and Performance link.
Click the Monitoring tab, then select the application in the tree.
ADP discovers all the deployed ADF artifacts on the configured Oracle WebLogic Domain release 11gR1.
An ADF node appears under the configured ADP Manager (for example, Oracle Enterprise Manager, select Server, then select ADF). The ADF node contains the following:
ADF taskflows
JSF Pages
Managed Beans
Business Components
The performance metrics for related components are displayed on the right-hand side panel when the respective component is selected.
Note:
The ADP link from the ADF target page only works if an ADP manager is deployed and the ADP agent is deployed to the WebLogic server for that target.The BPEL Processes node in the navigation tree contains information about all deployed Oracle BPEL processes within the managed domain. ADP organizes information for various process nodes into domains.
In the right-hand pane, you can view the minimum and maximum response time measurements stored in the database in addition to the average response time, arrivals, errors, and completions measurements. These metrics, if present, display visually in the window on the right pane.
When you select the root of the BPEL Processes tree, ADP displays the BPEL Processes Summary in the Main Display Window.
The BPEL Process Summary includes the following (Table 39-7):
Table 39-7 BPEL Process Summary Metrics
| Metrics | Description |
|---|---|
|
Domain |
Name of the OC4J domain container |
|
Process |
Name of the BPEL process |
|
Arrivals |
Total number of currently running instances for a specific BPEL process |
|
Response Time (ms) |
Average response time in milliseconds for a specific BPEL process |
|
Completions |
Total number of fulfilled requests for a specific BPEL process. A Completed status represents a BPEL process instance that has finished normally. |
|
Errors |
Total number of aborted instances of a specific BPEL process |
|
Min Response Time (ms) |
Minimum average response time in milliseconds for a specific BPEL process |
|
Max Response Time (ms) |
Maximum average response time in milliseconds for a specific BPEL process |
ADP presents these metrics in a table format in the Main Display Window when you select the BPEL Processes node. Graphical representations of two metrics, Arrivals and Completions, are displayed below the table.
When you click the plus (+) icon next to the domains sub-node under the main BPEL Processes node, ADP expands the tree to show all managed BPEL domains currently deployed on that particular Oracle SOA Suite instance.
You can see information specific to a particular process. By selecting a specific process, all information displayed in the Main Display Window changes to only show data relevant to this new context.
To see the BPEL process work flow associated with a BPEL process, select the node, right-click and select the Display Functional View option. ADP displays the appropriate functional work flow diagram and associated performance data in a new pop-up window.
See Table 39-8 for BPEL Functional View summary.
Table 39-8 BPEL Functional View Summary
| Column/Metric | Description |
|---|---|
|
Activity |
Name of a specific activity in the BPEL process |
|
Type |
Control Type for a specific node |
|
Arrivals |
Number of requests that have arrived for a specific node |
|
Response Time (ms) |
Average response time for a specific node |
|
Completions |
Number of completed requests for a specific node |
|
Errors |
Number of aborted instances for a specific node |
|
Response Time Min (ms) |
Minimum response time for a specific node |
|
Response Time Max (ms) |
Maximum response time for a specific node |
By looking at this summary table, you can determine which BPEL process node is running slowly and whether there are errors.
In addition to the summary, the following views are available for a node:
Delay Analysis view
Metadata view
Partner Links view
Partner Link Type Role view
Partner Link Bindings view
Modeled Entities view
Topology view
You can get to these views by selecting the appropriate tab.
Delay Analysis gives you a bird's eye view of a specific BPEL process. You can see what nodes in the BPEL process are taking up a majority of the average elapsed time. The red bar indicates the slowest BPEL process group or BPEL process node. The blue represents the time spent for the particular nodes.
The Metadata view displays the tables containing specific metadata associated with the selected active BPEL process being displayed in the left-hand pane. Information provided in this view includes caller and called class metadata information as well as general summarized metadata in relation to the BPEL process and the associated web services. Table 39-9 explains the metadata.
Table 39-9 Metadata View Summary
| Column/Metric | Description |
|---|---|
|
SummaryTable -Process |
Name of the BPEL process node |
|
SummaryTable -Web Service |
Name of the web service being called from the BPEL process |
|
SummaryTable -Version |
Version of the web service being called from the BPEL process |
|
SummaryTable -Location |
Location of the web service being called from the BPEL process |
|
Caller Table - Caller Class |
Class name for the caller class that is calling the BPEL process |
|
Caller Table - Caller Method |
Class method for the caller class that is calling the BPEL process |
|
Caller Table -Target Host |
Target host that the caller class targeted to instantiate the BPEL process |
|
Caller Table -Target Port |
Target port that the caller class targeted to instantiate the BPEL process |
|
Caller Table -Target URL |
Target URL that the call class targeted to instantiate the BPEL process |
|
Caller Table - Invocation Count |
Number of invocations of the BPEL process instantiated by the caller class |
|
Caller Table - Response Time |
Average response time of the BPEL process instantiated by the caller class |
|
Called Clients Table - Called Class |
Class name of the class that was called by the BPEL process |
|
Called Clients Table - Target URL |
Target URL of the class that was called by the BPEL process |
|
Called Clients Table - Invocation Count |
Number of invocations made from the BPEL Process to the called class. |
|
Called Clients Table - Response Time |
Response time of the called class |
The partner links view provides detailed information on the various roles related to how and why the partner link service is being utilized. The information provided includes both the caller and callee roles, as well as the partner link type. See Table 39-10.
Table 39-10 Partner Links View Summary
| Column/Metric | Description |
|---|---|
|
Partner Link |
Name of the partner link |
|
My Role |
Role in regards to the BPEL process calling the partner link service |
|
Partner Role |
Role of the partner link service |
|
Partner Link Type |
Partner link category (type) of the service being called |
See Table 39-11 describes the columns in the Partner Link Type Role view.
The Partner Link Bindings view provides insight into the actual roles and types of the partner link instances which represent web services that have been bound by the BPEL process. See Table 39-12.
Table 39-12 Partner Link Bindings View Summary
| Column/Metric | Description |
|---|---|
|
Partner Link Role |
Defines the web service role that the BPEL process will communicate with |
|
Partner Link Type |
Defines the web service type that the BPEL process will communicate with |
|
WebService PortType |
Name of the web service |
|
WebService Port Namespace ID |
URL of the webservice instance |
The modeled entities view consist of a list and count of the general entities as catalogued during the discovery phase of the resource configuration. The tables contain both a total entity count as well as a breakdown of the entity count by entity type. See Table 39-13.
Table 39-13 Modeled Entities Summary
| Column/Metric | Description |
|---|---|
|
Total Entities Modeled Table - Total |
Total entities (static label) |
|
Total Entities Modeled Table - Count |
Total number of entities catalogued during the discovery phase of the BPEL process |
|
Modeled Entities Table - Entity Type |
Entity type being catalogued as part of the discovery phase of the BPEL process |
|
Modeled Entities Table - Count |
Total number of entities catalogued during the discovery phase of the BPEL process for a particular entity type |
The Topology View utilizes the modeled entities that were captured during the discovery process to provide a bird's eye view of all of the various high-level relationships between BPEL processes, web services, and business services. You can toggle between static and dynamic relationship views using the tabs at the top of the Topology pane.
Expanding a particular BPEL process further, the first item you see is the Node Hierarchy node. By selecting the Node Hierarchy node, ADP provides a list of nodes associated with the specific process.
When you click the plus (+) icon next to a specific Node Hierarchy node, ADP expands the tree to show BPEL process nodes in the Node Hierarchy. Click an individual BPEL process node to see the load and performance of the selected node in the Main Display Window.
The BPEL process node information also includes the name of the method invoked. This information is displayed as part of the summary table at the top of the main view window.
The Oracle ESB node under Oracle Enterprise Manager contains information about all of the deployed Oracle ESB servers running in the managed domain. ADP organizes the information for various Oracle ESB nodes into various categories.
When you select the root of the ESB tree, ADP displays the ESB Summary in the Main Display Window.
The ESB Summary includes the following (Table 39-14):
Table 39-14 ESB Summary Metrics
| Metric | Description |
|---|---|
|
ESB System |
Name of ESB System |
|
ESB Service |
Name of the ESB Service identifier |
|
Arrivals |
Total number of ESB service instance arrivals |
|
Completions |
Total number of ESB service instance completions |
|
Response Time |
Total number of completed instances for a specific BPEL process. A Completed status represents a BPEL process instance that has finished normally. |
ADP presents these metrics in a table format in the Main Display Window when you select the ESB node. When you click the plus (+) icon next to the ESB Systems sub-node under the main ESB node, ADP expands the tree to show all managed ESB Systems currently deployed on that particular Oracle SOA Suite instance.
You can see information specific to a particular ESB System. By selecting a specific ESB System, all information displayed in the Main Display Window changes to only show data and the topology relevant to this new context.
By looking at the summary table, you can find out which ESB node is running slowly and whether there are errors.
Besides the summary, the following views are available for the Node Hierarchy node:
Service Details view
Service Parent Details view
Service Definition view
Service Operations view
Operation Routing Rules view
Topology view
You can get to these views by selecting the appropriate tab.
The Service Details view provides specific information related to the details of the bound service process instances. Instance IDs and other descriptive details are included as part of this view. See Table 39-15.
The Parent Service Details view provides specific information related to the details of the parent of the bound service process instances. Instance IDs, roles, and other descriptive details are included as part of this view. See Table 39-16.
Table 39-16 Service Parent Details View Summary
| Column/Metric | Description |
|---|---|
|
Service Name |
Name of the parent ESB service |
|
ParentGUID |
GUID of the parent ESB service |
|
ParentQname |
Canonical qualified name for the parent of the bound ESB service |
|
ParentType |
Parent type of the parent ESB service |
|
MyRole |
Role of the caller of the parent ESB service instance |
|
ParentRole |
Role of the callee of the parent ESB service instance |
The Service Definition view contains information regarding the bound ESB service including the Business Service (ESB) WSDL and Port Type as well as the associated URLs. See Table 39-17.
Table 39-17 Service Definition View Summary
| Column/Metric | Description |
|---|---|
|
Service Name |
Name of the ESB service |
|
BusinessServiceWSDL |
URL of the Business Service WSDL |
|
BusinessServicePortType |
Port type of the Business Service |
|
ConcreteServiceWSDL |
URL of the Concrete Service WSFL |
|
ConcreteServiceURI |
URI for the concrete service |
The Service Operations views provides details regarding the various method operations being executed. All information is provided in regards to the metadata associated with a specific business service instance. See Table 39-18.
Table 39-18 Service Operations View Summary
| Column/Metric | Description |
|---|---|
|
Service Name |
Name of the ESB service |
|
Name |
Service operation name being executed |
|
GUID |
GUID of the ESB service |
|
Qname |
Canonical qualified name for the bound ESB service |
|
Element |
Associated element within the ESB Service |
|
SchemaLocation |
Schema location for the associated ESB service |
|
Type |
Type of ESB service operation |
The Operation Routing Rules view provides various details regarding the operation routing rules for Business Service operations. This includes the specific instance business service names being utilized for operations. See Table 39-19.
The Services node in the navigation tree contains information about all external entry points into the managed domain. ADP currently monitors the following types of services:
HTTP
EJBs
JDBC
Selecting each service type reveals service summary in the Main Display Window.
The minimum and maximum response time measurements are stored in the database in addition to the average response time measurements. These metrics, if present, display visually in the window in the right pane.
ADP displays entry point activity summary associated with the selected EJB service.
Tip:
Setting thresholds at some of these entry points enables ADP to monitor the performance of key business services. When a violation event occurs, you can begin investigating from the Service node.Expanding the HTTP node under the Services node reveals a list of discovered HTTP based entry points into the managed domain. HTTP service end points include JSPs, struts actions, and servlet mappings. These discovered HTTP entry points are listed by their root context. When you select a specific HTTP entry point, ADP displays the associated summary in the Main Display Window.
When a specific file is selected, ADP displays more detailed performance data.
Method level performance data is displayed when you select a specific HTTP service entry point.
Table 39-20 HTTP Performance Summary
| Column/Metric | Description |
|---|---|
|
Servlet |
Name of the servlet associated with the selected service |
|
Method |
Name of the method invoked by external call |
|
Arrivals |
Total number of requests received by this method |
|
Invocation Count |
Total number of method invocations |
|
Response Time (ms) |
Average method response time in milliseconds |
To view the performance summary for EJBs invoked from outside the JVM, click the EJBs node.
Table 39-21 EJB Performance Summary
| Column/Metric | Description |
|---|---|
|
EJB |
Name of the EJB |
|
Invocation Count |
Number of times the EJB is called |
|
Response Time (ms) |
Average response time for the EJB in milliseconds |
|
Delay (ms) |
Overall delay contributed by the EJB in milliseconds |
Tip:
As a general rule, external calls that terminate in EJBs are RMI calls. Web services calls that ultimately terminate in EJBs use SOAP and enter the application server via HTTP.To bring up the performance summary for JDBC operations invoked from outside of the JVM, click the JDBC node.
Table 39-22 JDBC Performance Summary
| Column/Metric | Description |
|---|---|
|
SQL Statement |
Generalized SQL Statement executed by the JDBC operation |
|
Class |
Name of the class used in the JDBC operation |
|
Method |
Name of the method used in the JDBC operation |
|
Invocation Count |
Number of times the JDBC operation is called |
|
Response Time (ms) |
Average response time for the JDBC operation in millisecond |
|
Delay (ms) |
Overall delay contributed by the JDBC operation in milliseconds |
The Applications node in the navigation tree contains information about all deployed applications in the managed domain. By selecting the Applications node, ADP displays the Applications Summary.
The Applications Summary includes the following information (Table 39-23, "Applications Summary"):
Table 39-23 Applications Summary
| Column/Metric | Description |
|---|---|
|
Application |
Name of application |
|
Status |
Operations status for a specific application |
|
Response Time (ms) |
Average response time in milliseconds for a specific application. This is the average of response times of all JSPs and servlets contained in the deployment archive. |
|
Invocation Count |
Total number of invocations for a specific application. This is the total invocation count of all JSPs and servlets contained in the deployment archive. |
Tip:
Application is a packaging unit in Java EE. Each EAR, WAR, and JAR files deployed to the application server is considered an individual application. These metrics track performance and arrival rate of these entities.ADP presents these metrics in a table format in the Main Display Window when you select the Applications node. Graphical representations of the following metrics, Response Time, Invocation Count, and Active Sessions, are displayed below the table.
Expand the Applications tree by clicking the plus (+) icon next to Applications node. You can get more information about a specific application.
ADP displays performance summary for the selected application in the Main Display Window. You can obtain additional performance data by clicking different tabs in the Main Display Window.
The Applications Summary includes the following tabs (Table 39-24):
Table 39-24 Applications Summary Tabs
| Tab Name | Description |
|---|---|
|
Summary |
Includes performance data at the application level including time-based trend graphs of Application Response Time, Application Invocation Count, and Application Active Sessions. The invocation count and response time for the top 10 slowest servlets, the usual application entry points, are also included. |
|
Response Times |
Includes time-based trend graphs of component response times. Graphs include Servlet Response Time, EJB Response Time, and JDBC Response Time. |
|
Invocations |
Includes time-based trend graphs of component invocation counts. Graphs include Servlet Invocation Count, EJB Invocation Count, and JDBC Invocation Count. |
|
Errors/Exceptions |
Errors metrics associated with the selected portal. |
|
Transactions |
Transaction events associated with the selected portal and children below.By default, the Transactions tab is not enabled. |
|
Modeled Entities |
Includes a catalog of entities modeled by ADP. Only the modeled entities associated with the selected application are included. |
|
Instrumentation |
Includes performance data by different types of instrumentation probe points. There are different tabs available: Class, Method, and SQL. Each tab includes basic information such as Probe Point Name, Invocation Count, and Response Time. This detailed performance data can help you identify low-level bottlenecks. |
|
Topology |
Includes the topology view associated with the selected application. |
Under each named application node, ADP displays performance and other relevant information specific to that application. For example, by clicking the children nodes, the relevant data is displayed in the Main Display Window. Application response time and invocations measurements can be reached by clicking the panes in the Main Display Window.
In this section, we will further expand on the following nodes:
Services
Dependencies
Deployments
Workshop Projects
Web Applications
Stateless Beans
Stateful Beans
Entity Beans
Message Driven Beans
Note:
The number of children nodes available under each application node depends solely on the complexity of the selected application. Simple Java EE web applications will not have nodes like Workshop Projects, Stateless Beans, Stateful Beans, Entity Beans, and Message Driven Beans.The Services node includes all the external entry points associated with the selected application. When this node is selected, ADP displays a summary view in the Main Display Window. ADP displays the performance data associated with various entry points associated with the selected application.
Tip:
The children nodes under the Services node include entry point specific performance data.The Dependencies node shows a list of internal and external components and share resources that a specific application depends on for its normal operation. When the Dependencies node is selected, ADP displays all external references made by the application in the Main Display Window. The following is a list of columns and their descriptions (Table 39-25):
Table 39-25 Dependencies Column Descriptions
| Column/Metric | Description |
|---|---|
|
Name |
Display name of the component or resource used by the application. If this is undefined in the Deployment Descriptor, the reference name for the component is used. |
|
Reference |
Reference name of the component or resource used by the application. |
|
Reference Type |
Component or resource type. |
|
Referer Component |
Name of the component that is part of the application which obtained the reference to external component or resource. |
|
Referer Module |
Name of the module that is part of the application which obtained the reference to external component or resource. |
ADP displays all the references associated with components in the selected application.
The Dependencies node can be further expanded by clicking the plus (+) icon. The children nodes of the Dependencies node are organized by type. Here are the list of dependency types and their descriptions (Table 39-26):
| Dependency Type | Description |
|---|---|
|
Data Sources |
All shared data sources used by the application |
|
Entity Beans |
All entity beans used by the application |
|
Session Beans |
All session beans used by the application |
|
JMS Queues |
All JMS queues used by the application for publishing JMS messages |
|
JMS Topics |
All JMS topics subscribed by the application |
|
Web Services |
All web services used by the application |
When a specific node is selected, ADP displays relevant performance summary. These nodes can also be expanded by clicking the plus (+) icons. The expanded tree includes specific components and share resources used by the application.
The Performance summary view associated with the Data Sources node under Dependencies provides information on both connection pools and SQL statements.
For more information on the metric description, refer to Section 39.1.9, "Metric Types".
The Deployments node shows the architecture of the deployed application. When this node is selected, ADP shows all the modules deployed as part of this application. The default view in the Main Display Window shows the active module-level call path. Table 39-27 lists the tabs available as part of this summary view and their descriptions.
| Tab Name | Description |
|---|---|
|
Module Level Execution |
Shows the active calling relationships among various Java EE modules (EAR, WAR, JAR, and more). Shared resources are also included. This is the default Architecture View at the module level. |
|
Module Level |
Shows the potential calling relationships among various Java EE modules. Shared resources are also included. By default, the Module Level tab is not enabled. |
|
Instrumentation |
Includes detailed performance data at the method level. The table includes caller components, caller method, callee (target) component, callee module, invocation count, and response time. |
|
SQL Statement |
Includes all SQL statements executed as part of this application. It also includes performance information such as invocation count and response time. |
Active module-level call path is displayed as the default view for the Deployments node of a selected application.
Double-click a specific module to trigger ADP to display the architecture of the selected module.
Expand the Deployments node by clicking the plus (+) icon to reveal all the deployed modules in this application. Further expanding the nodes at the module level reveals components associated with the selected module. Further expanding the nodes at the component level reveals methods associated with the selected component.
When you select one of these children nodes (module, component, and method levels), ADP displays associated tabs for active call path diagram, static call path diagram, instrumentation and SQL statements.
Tip:
Use the active call path diagram as a guide to identify entities with performance data. If an entity does not have performance data, ADP displays No data available for the selected time frame in the Main Display Window.The Workshop Projects node includes performance information about modules and components created using the Oracle WebLogic Workshop. These modules and components include WebLogic Integration processes, WebLogic Integration web services, and WebLogic Portal pageflows.
Workshop Project node and its children nodes provide performance data associated with WLI processes, web services, and WLP pageflows.
When you select a specific children node, ADP displays detailed performance information.
The Web Applications node includes performance information related to the Web Applications modules and components associated with the selected application. Click the Web Applications node to reveal a performance summary in the Main Display Window. Click the plus (+) icon to expand the Web Applications node to reveal various web modules deployed as part of this application.
Click the plus (+) icon to expand on a specific web module and reveal different groupings for web components, for example, Pageflows, Struts Modules and Servlets. Clicking one of these nodes triggers ADP to display rolled up performance summary for the entire grouping. You can further expand these nodes by clicking the plus (+) icon to reveal more detailed information. Fully expanded Web Applications node contains all web modules organized by type.
Detailed performance information at the individual pageflow, struts action, and servlet levels will be displayed when you click the lowest level nodes.
The Stateless Beans node includes activity information related to the stateless EJB components associated with the selected application. Click the Stateless Beans node to reveal an activity summary in the Main Display Window. Click the plus (+) icon to expand the Stateless Beans node to reveal various stateless EJBs deployed as part of this application.
You can further select individual nodes to obtain detailed activity information. Selecting a specific Stateless Bean node triggers ADP to display detailed activity metrics.
The detailed view contains the following activity metrics (Table 39-28):
Table 39-28 Stateless Beans Detail View
| Column/Metric | Description |
|---|---|
|
EJB |
Name of the stateless EJB. |
|
In Use |
Number of instances for a specific stateless EJB currently being used from the free pool. [Snapshot Count] |
|
Idle |
Number of instances for a specific stateless EJB currently in the idle state in the free pool. These bean instances are available for use. [Snapshot Count] |
|
Waits |
Number of threads currently waiting for a specific stateless EJB bean instance from the free pool. [Snapshot Count] |
|
Timeouts |
Total number of threads that have timed out waiting for an available bean instance from the free pool. [Aggregated Count] |
Note:
The metrics reported in the Stateless Beans node are reported by the MBean (Management Bean) of the EJB container. These activity metrics can be used for checking the overall health of the EJB container. When the EJB container is restarted, these metrics are reset.The Stateful Beans node includes activity information related to the stateful EJB components associated with the selected application. Click the Stateful Beans node to reveal an activity summary in the Main Display Window. Click the plus (+) icon to expand the Stateful Beans node to reveal various stateful EJBs deployed as part of this application.
You can further select individual nodes to obtain detailed activity information.
The Stateful EJB Summary includes the following tables:
Stateful EJB Cache
Stateful EJB Transactions
Stateful EJB Locking
Stateful EJB Cache table includes the following information (Table 39-29):
Table 39-29 Stateful EJB Cache
| Metrics | Description |
|---|---|
|
EJB |
Name of the Stateful EJB |
|
Hits |
Total number of times an attempt to access the Stateful EJB instance from the cache succeeded [Aggregated Count] |
|
Accesses |
Total number of attempts to access the Stateful EJB instance from the cache [Aggregated Count] |
|
Size |
Number of beans instances from this Stateful Home currently in the EJB cache [Snapshot Count] |
|
Activations |
Total number of beans from this Stateful Home that have been activated [Aggregated Count] |
|
Passivations |
Total number of beans from this Stateful Home that have been passivated [Aggregated Count] |
Tip:
Passivation (serializing EJB state information to disk) and activation (reconstitute EJB state information from disk) are resource intensive operations. Ideally, Oracle recommends low level of activity in these metrics.Stateful EJB Transactions table includes the following information (Table 39-30):
Table 39-30 Stateful EJB Transactions
| Metrics | Description |
|---|---|
|
EJB |
Name of the Stateful EJB |
|
Commits |
Total number of transactions that have been committed for this Stateful [Aggregated Count] |
|
Rollbacks |
Total number of transactions that have been rolled back for this Stateful [Aggregated Count] |
|
Timeouts |
Total number of transactions that have timed out for this EJB [Aggregated Count] |
Tip:
High number of EJB Transaction Rollbacks may indicate problems with the data used; for some reason the target database is unable to commit the change. High number of EJB Transaction Time-outs may indicate problems accessing the database including network outage, database lock contention, and database outage.Stateful EJB Locking table includes the following information (Table 39-31):
Table 39-31 Stateful EJB Locking
| Metric | Description |
|---|---|
|
EJB |
Name of the Stateful EJB |
|
Entries |
Number of Stateful EJB instances currently locked [Snapshot Count] |
|
Lock Accesses |
Total number of attempts to obtain a lock on an Stateful EJB instance [Aggregated Count] |
|
Current Waiters |
Number of Threads that currently waiting for a lock on an Stateful EJB instance [Snapshot Count] |
|
Total Waiters |
Total number Threads that have waited for a lock on an Stateful EJB instance [Aggregated Count] |
|
Timeouts |
Total number Threads that have timed out waiting for a lock on an Stateful EJB instance [Aggregated Count] |
Tip:
Pay attention to Current Waiters and Time-outs. These metrics can indicate possible performance problems caused by EJB Locking. Ideally, 0s should be displayed for these metrics.ADP presents these metrics in a table format in the Main Display Window when you select the Stateful Beans node. Graphical representations of two metrics, Stateful EJB cache access, and Stateful EJB lock access, are displayed below the table.
By looking at the activities related to Stateful EJBs, you can determine if there any abnormal activities associated with Stateful EJBs.
Note:
The metrics reported in the Stateful Beans node are reported by the MBean (Management Bean) of the EJB container. These activity metrics can be used for checking the overall health of the EJB container. When the EJB container is restarted, these metrics are reset.The Entity Beans node includes activity information related to the Entity EJB components associated with the selected application. Click the Entity Beans node to reveal an activity summary in the Main Display Window. Click the plus (+) icon to expand the Entity Beans node to reveal various Entity EJBs deployed as part of this application.
You can further select individual nodes to obtained detailed activity information. Selecting a specific Entity Bean node triggers ADP to display detailed activity metrics.
The Entity EJB Summary includes the following tables:
Entity EJB Activity
Entity EJB Cache
Entity EJB Transactions
Entity EJB Locking
Entity EJB Activity table includes the following information (Table 39-32):
Table 39-32 Entity EJB Activity
| Metrics | Description |
|---|---|
|
EJB |
Name of the Entity EJB. |
|
In Use |
Number of instances for a specific Entity EJB currently being used from the free pool. [Snapshot Count] |
|
Idle |
Number of instances for a specific Entity EJB currently in the idle state in the free pool. These bean instances are available for use. [Snapshot Count] |
|
Waits |
Number of Threads currently waiting for a specific Entity EJB instance from the free pool. [Snapshot Count] |
|
Timeouts |
Total number of Threads that have timed out waiting for an available bean instance from the free pool. [Aggregated Count] |
Tip:
Pay attention to Waits and Timeouts metrics. Activities in the Waits metric and increasing count in the Timeouts metric are signs that requests are waiting to be serviced by the EJB container. Ideally, 0 should be indicated for these metrics.Entity EJB Cache table includes the following information (Table 39-33):
| Metrics | Description |
|---|---|
|
EJB |
Name of the Entity EJB |
|
Hits |
Total number of times an attempt to access the Entity EJB instance from the cache succeeded [Aggregated Count] |
|
Accesses |
Total number of attempts to access the Entity EJB instance from the cache [Aggregated Count] |
|
Size |
Number of beans instances from this EJB Home currently in the EJB cache [Snapshot Count] |
|
Activations |
Total number of beans from this EJB Home that have been activated [Aggregated Count] |
|
Passivations |
Total number of beans from this EJB Home that have been passivated [Aggregated Count] |
Tip:
Passivation (serializing EJB state information to disk) and activation (reconstituting EJB state information from disk) are resource intensive operations. Ideally, Oracle recommends a low level of activity in these metrics.Entity EJB Transactions table includes the following information (Table 39-34):
Table 39-34 Entity EJB Transactions
| Metric | Description |
|---|---|
|
EJB |
Name of the Entity EJB |
|
Commits |
Total number of transactions that have been committed for this EJB [Aggregated Count] |
|
Rollbacks |
Total number of transactions that have been rolled back for this EJB [Aggregated Count] |
|
Timeouts |
Total number of transactions that have timed out for this EJB [Aggregated Count] |
Tip:
High numbers of EJB Transaction Rollbacks may indicate problems with the data used; for some reason the target database is unable to commit the change. High numbers of EJB Transaction Timeouts may indicate problems accessing the database including network outage, database lock contention, database outage, and more.Entity EJB Locking table includes the following information (Table 39-35):
Table 39-35 Entity EJB Locking
| Metric | Description |
|---|---|
|
EJB |
Name of the Entity EJB |
|
Entries |
Number of Entity EJB instances currently locked [Snapshot Count] |
|
Lock Accesses |
Total number of attempts to obtain a lock on an Entity EJB instance [Aggregated Count] |
|
Current Waiters |
Number of Threads that currently waiting for a lock on an Entity EJB instance [Snapshot Count] |
|
Total Waiters |
Total number Threads that have waited for a lock on an Entity EJB instance [Aggregated Count] |
|
Timeouts |
Total number Threads that have timed out waiting for a lock on an Entity EJB instance [Aggregated Count] |
Tip:
Pay attention to Current Waiters and Timeouts. These metrics can indicate possible performance problems caused by EJB Locking. Ideally, 0s should be displayed for these metrics.When you select the Entity Beans node, ADP presents these metrics in a table format in the Main Display Window. Graphical representations of the following metrics, Entity EJB in use, Entity EJB cache access, and Entity EJB lock access, are displayed below the table.
Expand the Entity Beans tree by clicking the plus (+) icon next to Entity Beans node. You can get the same summary as previously described for a specific Entity EJB.
By looking at the activities related to Entity EJBs, you can determine if there any abnormal activities associated with Entity EJBs.
Note:
The metrics reported in the Entity Beans node are reported by the MBean (Management Bean) of the EJB container. These activity metrics can be used for checking the overall health of the EJB container. When the EJB container is restarted, these metrics are reset.The Message Driven Beans node includes activity information related to the message driven EJB components associated with the selected application. Click the Message Driven Beans node reveals an activity summary in the Main Display Window. Click the plus (+) icon to expand the Message Driven Beans node to reveal various message driven EJBs deployed as part of this application.
You can further select individual nodes to obtained detailed activity information.
The Message Driven EJB Summary includes the following tables:
Message Driven EJB Activity
Message Driven EJB Transactions
Message Driven EJB Activity table includes the following information (Table 39-36):
Table 39-36 Message Driven EJB Activity
| Metric | Description |
|---|---|
|
EJB |
Name of the Message Driven EJB. |
|
In Use |
Number of instances for a specific Message Driven EJB currently being used from the free pool. [Snapshot Count] |
|
Idle |
Number of instances for a specific Message Driven EJB currently in the idle state in the free pool. These bean instances are available for use. [Snapshot Count] |
|
Waits |
Number of Threads currently waiting for a specific Message Driven EJB instance from the free pool. [Snapshot Count] |
|
Timeouts |
Total number of Threads that have timed out waiting for an available bean instance from the free pool. [Aggregated Count] |
Tip:
Pay attention to Waits and Timeouts metrics. Activities in the Waits metric and increasing count in the Timeouts metric are signs that requests are waiting to be serviced by the EJB container. Ideally, 0 should be indicated for these metrics.Message Driven EJB Transactions table includes the following information (Table 39-37):
Table 39-37 Message Driven EJB Transactions
| Metric | Description |
|---|---|
|
EJB |
Name of the Message Driven EJB |
|
Commits |
Total number of transactions that have been committed for this EJB [Aggregated Count] |
|
Rollbacks |
Total number of transactions that have been rolled back for this EJB [Aggregated Count] |
|
Timeouts |
Total number of transactions that have timed out for this EJB [Aggregated Count] |
Tip:
High numbers of EJB Transaction Rollbacks may indicate problems with the data used; for some reason the target database is unable to commit the change. High numbers of EJB Transaction Timeouts may indicate problems accessing the database including network outage, database lock contention, database outage, and more.ADP presents these metrics in a table format in the Main Display Window when you select the Message Driven Beans node. Graphical representation of the Message Driven EJB in use metric is displayed below the table.
By looking at the activities related to Message Driven EJBs, you can determine if there are any abnormal activities associated with Message Driven EJBs.
Note:
The metrics reported in the Message Driven Beans node are reported by the MBean (Management Bean) of the EJB container. These activity metrics can be used for checking the overall health of the EJB container. When the EJB container is restarted, these metrics are reset.The Resources node under Oracle Enterprise Manager contains information for the managed domain organized by logical clusters, machines, servers, and more. You can look for low-level technology metrics organized by technology subsystems for a specific WebLogic Server.
The Resources tree includes the following nodes (Table 39-38):
Table 39-38 WebLogic Resources Tree
| Example Node | Description |
|---|---|
|
CSS Domain |
Name of the WebLogic Domain configured |
|
b-15/192.168.128.15 |
ID of the physical machine |
|
cgServer |
Name of the WebLogic Server configured |
|
Applications |
Performance measurements of all deployed applications running on this server |
|
JDBC |
Information of all configured JDBC resources for this server |
|
JMS Servers |
Information of all JMS destinations configuration for this server |
|
Execute Queues |
Information of all Execute Queues configured for this server |
|
JVM |
JVM information including Heap Size for this server |
|
JRockit |
JRockit information including Heap Size for this server |
|
Modeling Status |
Entities modeled by ADP for this server |
|
ADP Modules |
Status of the ADP Java Agent Module for this server |
Expand these nodes by clicking the plus (+) icon next to the node name to get more information.
If the ADP OS Agent is deployed on the machine, clicking on the physical machine ID would show OS metrics collected by the OS Agent. These OS metrics include CPU Usage, Disk Usage, and Physical Memory Usage.
The Resources node under Oracle Enterprise Manager contains information for the managed domain organized by logical clusters, machines, servers, and more. You can look for low-level technology metrics organized by technology subsystems for a specific Oracle AS Server.
The Resources tree includes the following nodes (Table 39-39):
Table 39-39 Oracle Resources Tree
| Example Node | Description |
|---|---|
|
Managed System Resource Name |
Top-level Resource name, for example, oc4j_soa |
|
Oracle AS Server |
Machine name which can be navigated to both within or outside a cluster, for example, oc4j_soa@192.168.1.119 which includes both the server name and the host server IP address |
|
Applications |
Performance measurements of all deployed applications running on this server |
|
JDBC |
Information of all configured JDBC resources for this server |
|
JMS Servers |
Information of all JMS destinations configuration for this server |
|
Thread Pools |
Performance information about all threads used by the container to process requests |
|
JVM |
JVM information including Heap Size for this server |
|
BPEL Processes |
Performance measurements about BPEL Processes deployed in the container |
|
ESB |
Performance measurements about ESB services deployed in the container |
|
Modeling Status |
Modeled entities for the container |
|
ADP Modules |
Status of the ADP Java Agent Module for this server |
|
Applications |
Performance information about the applications deployed in the container |
Clicking the physical machine ID would show OS metrics. These OS metrics include CPU Usage, Disk Usage, and Physical Memory Usage.
The Custom Metrics node under Oracle Enterprise Manager contains all the custom metrics you defined. Currently ADP supports custom metrics for Java classes. When Custom Metrics node is selected, ADP displays various summaries. You can select individual entities to get more detailed performance information.
Expanding the Custom Metrics node reveals a list of Java classes with custom metrics configured.
The following is a list of columns in the Custom Class Performance table and their descriptions (Table 39-40):
Table 39-40 Custom Class Performance
| Column/Metric | Description |
|---|---|
|
Caller Class |
Fully qualified name of the class that is making the inbound call |
|
Caller Method |
Method name in the class that is making the inbound call |
|
Class |
Fully qualified name of the class that is the destination of the inbound call |
|
Invocation Count |
Total number of times the inbound call is made |
|
Response Time (ms) |
Average response time of the inbound call in milliseconds |
Status in the navigation tree contains information for the ADP environment for the monitored WebLogic domain, WebSphere cell, or Oracle AS cluster. Select Status to see the ADP Java Agent status for the WebLogic domain.
The ADP Java Agent status includes the following (Table 39-41):
Table 39-41 ADP Java Agent Status
| Column/Metric | Description |
|---|---|
|
Server |
Name of the WebLogic server, WebSphere cell, or Oracle AS cluster |
|
Container Status |
Operational status of the WebLogic, WebSphere, or Oracle AS server (running or not) |
|
Agent In Sync |
Version synchronization between ADP and ADP Agent status (true or false) |
|
EJB Installed |
ADP EJB installation status (true or false) |
|
Agent Installed |
ADP Java Agent installation status |
|
Agent Activated |
ADP Java Agent activation status |
|
Agent Status |
ADP Java Agent operational status |
|
Server Type |
Identifies server as administration, individual, or clustered server |
|
Admin URI |
Location of the domain admin server |
|
Manager RMI Registry Host |
Host name of the ADP RMI registry |
|
Manager RMI Registry Port |
Port number of the ADP RMI registry |
|
EJB Major Version |
ADP EJB major version |
|
EJB Minor Version |
ADP EJB minor version |
|
EJB Build ID |
ADP EJB build number - for version synchronization check |
|
Agent Major Version |
ADP Java Agent major version |
|
Agent Minor Version |
ADP Java Agent minor version |
|
Agent Build ID |
ADP Java Agent build number - for version synchronization check |
Click the Modeling Status node under Status to see a table of all modeled entities in the managed domain. This table shows all the managed clusters, servers, and applications in the ADP environment. Mismatches between the Modeling Status table and your environment are indications of configuration problems.
You can use this information to debug and resolve ADP configuration issues.
Service Component Architecture (SCA) provides a set of features and services that simplify the process of detecting the presence of Service-Oriented Architecture (SOA) components.
| Composite | Description |
|---|---|
|
Services |
Metrics related to Services defined on the SOA composite. |
|
Wires |
Metadata related to Wires defined in the SOA composite |
|
References |
Metrics related to References defined in the SOA composite |
|
Components |
Metrics related to Components within the SOA composite |
The following components make up the Service Component Architecture:
| Component | Description |
|---|---|
|
Decision Services |
Metrics related to components in the Decision Services engine |
|
Mediators |
Metrics related to components in the Mediator engine |
|
Human Workflows |
Metrics related to components in the Human Workflow engine |
|
BPEL |
Metrics related to components in the BPEL engine |
Using the Configuration tab you can set up the resources you want to monitor using ADP.
The configurations explained in this section are:
A running ADP manager must be registered in Enterprise Manager. After the registration, Enterprise Manager continues to keep the manager as a valid manager even if it is down. When this occurs, the Enterprise Manager UI displays the ADP manager as Unreachable.
The Database Configuration page lists the databases accessible to ADP which you want to monitor. You can configure a database to be used by ADP, edit an existing database configuration, delete a database configuration, and enable a configuration.
The Resource Configuration node in the Configuration tree enables you to create resources (for example, target application server domains) that can be monitored by ADP.
In ADP, thresholds configured for various measurements are called Service Level Objectives (SLOs). A service level objective is a measurable attribute, for example, availability. Service Level Agreements (SLA) are made up of SLOs.
Configuring SLOs is a key activity for establishing and maintaining an effective performance monitoring system. To configure a SLO, click the Configuration tab and select the Service Level Objective Configuration option.
ADP categorizes SLOs into the following types:
Performance
Depicts the relative responsiveness of the monitored entity to the configured threshold.
Availability
Informs you to what extent a particular entity is available to service requests.
Errors
Informs you if the number of errors and exceptions encountered by this entity are approaching or violating the configured threshold.
Load
Depicts how many operations have been performed and requests have been served by a particular entity.
ADP is aware of clusters. As such, these indicators display overall health of a particular entity across the entire cluster.
To configure a SLO, perform the following steps:
From the Targets menu, select Middleware. On the Middleware page, select Application Dependency and Performance from the Middleware Features menu. Ensure the Configuration tab is highlighted.
Select SLO Blackout Configuration.
You can view any existing SLO blackout.
Use this window to create, delete, or view the details of existing blackouts.
When you select Service Level Objectives Configuration, ADP displays the Service Level Objective Configuration window. This window allows you to apply existing SLOs or create new ones. When you click Create New SLO, ADP guides you through the process of setting up a new SLO.
The steps for SLO creation are as follow:
Either select a SLO file or create a new SLO file. ADP can store SLO configurations in different files to improve configuration portability.
Define the SLO Entity Type. ADP automatically selects the appropriate entity type for you based on the selected monitoring element. For example, if you want to set a SLO on a Portal Desktop element, ADP automatically sets the Entity Type for you.
Other information is filled in by default. Normally, there is no need to modify the SLO Entity values.
When you are done setting the SLO Entity Type values, click Create New SLO to go to the second step of the SLO creation process, Defining the SLO Parameters. Note: The (*) character means Select All. It is recommended that you do not use the (*) character.
Note: SLOs are hierarchical which allows you to set service levels at any level within the modeled hierarchy of an application.
Follow these steps to define the SLO parameters:
Navigate to Application Dependency and Performance.
From the Targets menu, select Middleware. On the Middleware page, click the target of choice. On the Home tab, select the Summary region and click the Application Dependency and Performance link.
Expand the Configuration tab. Select Service Level Objective Configuration.
Either create a new SLO or edit an existing SLO.
Select the performance metric.
Define the monitoring window size, which determines how long the condition must persist before generating an alert.
Set threshold values for the SLO.
Select what actions to take when a trigger is fired. A list of preconfigured actions is available in the view pane.
Add new actions by going to the Action Configuration node in the Configuration Workspace.
Click Save to set the SLO for this monitored element.
You can delete unwanted SLOs for any element from this window.
ADP categorizes SLOs as Performance, Availability, Error, and Load.
Right-click on any tree node and select View Service Level Objective Events to open a new window. You can see all the SLO violation events triggered for the selected entity. ADP automatically applies a filter to show only relevant events.
Once new SLOs are added, ADP updates the relevant graphs to visually display these new thresholds. Table 39-44 explains the different line types.
| Line Description | Description |
|---|---|
|
Solid Red Line |
A violation threshold that triggers on high. |
|
Solid Yellow Line |
A cautionary threshold that triggers on high. |
|
Dashed Red Line |
A violation threshold that triggers on low. |
|
Dashed Yellow Line |
A cautionary threshold that triggers on low. |
You can prevent having unwanted alerts being fired during planned or unplanned down time. The SLO Blackout Configuration node in the Configuration tree enables you to create time periods when information will not be monitored for a specific SLO. You can define blackouts by a SLO file, an individual SLO, or by entity.
You can prevent having unwanted alerts being fired during planned or unplanned down time. SLO Blackout Configuration enables you to create time periods when information will not be monitored for a specific SLO. You can define blackouts by a SLO file, an individual SLO, or by entity.
To create and maintain SLO blackouts, perform the following steps:
Navigate to Application Dependency and Performance.
From the Targets menu, select Middleware. On the Middleware page, click the target of choice. Select Application Dependency and Performance from the Middleware Features menu.
Expand the Configuration tab. Select SLO Blackout Configuration.
You can view any existing SLO blackout.
Use this window to create, delete, or view the details of existing blackouts.
Click Create SLO Blackout to view the detail window.
On the SLO Blackout File page, type the name of the blackout in the New SLO Blackout File field. Click Continue.
On the SLO Blackout Configuration page, fill in the fields. Refer to Table 39-45 for details.
Table 39-45 SLO Blackout Configuration
| Column/Metric | Description |
|---|---|
|
Blackout Name |
Type in the name. |
|
Description |
Type in the description of the SLO you are creating. |
|
Blackout By SLO File |
Use to blackout at the file level. The SLO files display in a list where you can select them or cancel out of the window. This option restricts the blackout to the SLO file name. |
|
Blackout By SLOs |
Use to blackout at the SLO level. The SLOs display in a list where you can select them or cancel out of the window. This option restricts the blackout to the SLO name. |
|
Blackout By Entity |
Use to blackout at the entity type level. Click the Blockout by Entity: button to view the list of entity types. Select the entity. This option restricts the blackout to the entity type selected. |
|
year, month, date, hour, minute, duration |
Use the guidelines to the right of these columns to enter the appropriate information. |
|
recurring |
Select how often you would like to run this blackout event from the list. |
Viewing SLO Blackout Summary List
Click SLO Blackout Summary List.
View the details on the existing SLO Blackout events.
Click Show SLO Blackout List to return to the previous window.
Select an existing event on the list.
Click Delete SLO Blackout.
Confirm that you want to delete the entry and click Yes.
ADP is designed to propagate threshold violation events up the hierarchy. Therefore, when a SLO is set on a lower level metric, the higher level health indicator light becomes activated. Additionally, the health indicator light for the application server that hosts this component also becomes active. Oracle calls this containment approach to SLO event propagation. When a lower level SLO is violated, the violation event propagates all the way up the hierarchy and changes the status of all containers for this event.
Use the Enterprise Manager Incident console to check for events fired as a result of SLO violations in ADP.
To access the ADP alerts:
From the Enterprise menu, select Monitoring, then select Incident Manager.
In the Views region, select Events without incidents.
Look for events with target type "Application Deployment" and "Application Dependency and Performance Alert". These are the ADP alerts.
There are cases where additional instrumentation is needed based on your specialized requirements. Custom metrics allow you to instrument a class or method of your choice and receive performance metrics collected by the ADP agent.
To create a metric configuration, do the following:
From the Targets menu, select Middleware. In the Related Links sections, select Application Dependency and Performance.
Click the Configuration tab, choose the configuration in which you are interested. Click Custom Metric Configuration.
In the right pane, click the Create Custom Metric button.
On the Custom Metric File page, choose whether to use an existing .xml file or a new file. If you choose a new file, the ADP Manager will create the new .xml file. Click Continue.
On the Custom Metric Configuration page, provide the following information:
Resource name is a monitored WebLogic domain or Oracle Application Server or WebSphere cell.
You created a name when you configured ADP to monitor. The same name is used here during custom metric configuration.
Class name is the name of the implementation class in the code. You are required to enter a fully qualified class name.
Method name is the name of the implementation method in the code.
After you define the custom metrics, restart the application server instances associated with these customizations. The new custom metrics will be listed under the Custom Metrics node in the ADP navigation tree.
The newly configured custom metric provides class level performance data, for example, invocation count and response time.
The managers perform complex mathematical modeling and statistical calculations with summarized data from all Java Agents.
Using the Registration tab, you can add, edit, and remove Managers configured to Enterprise Manager. By accessing ADP through Remote Method Invocation (RMI), you can manipulate all the managers configured to Enterprise Manager through a secured protocol.
In ADP, the Configuration tab lists all the managers currently configured to Enterprise Manager. By using the Configuration for Managers feature, you can access Application Dependency and Performance through Remote Method Invocation (RMI). You can then manipulate all the managers configured to Enterprise Manager through a secured protocol. The following sections provide additional information.
The Configuration tab displays only if the Enterprise Manager user is an Administrator as defined by examining the user's role.
The first time the Registration tab displays there are no managers in the Managers tree. To add a new manager, perform the following steps:
Navigate to the Application Dependency and Performance feature.
From the Targets menu, select Middleware. In the Related Links section, click Application Dependency and Performance.
In the Registration tab, click the Managers node in the tree.
Type the new manager information in the Main Display window.
Decide whether this manager should be monitored.
Request monitoring provides end-to-end visibility into requests, localizes end-user performance problems to specific application deployments, and provides a platform for context-based drill down diagnostics.
When you select Enable Request Monitoring, ADP creates and sets up targets for collecting request performance data. If you do not select Enable Request Monitoring, the ADP manager is only registered in Enterprise Manager.
Note:
The grayed out information represents configuration data for connecting to the ADP manager by way of a secure protocol, for example Key Store, Trust Store, and passwords. This information is extracted from the ADP manager by way of the RMI call.If you enable request monitoring on an existing manager, click Upload to populate the manager configuration properties to the ADP target in Request Monitoring.
Click Test Connect to test the connection to the new manager. Should the test connection fail, this may be because the manager is not running or the manager is not yet installed.
Click Add.
Once the manager is added, the name of the manager will display in the Configuration tab under the Managers node in the tree.
To add a previously configured manager, perform the following steps:
Click + (plus sign) next to the Managers node in the tree, then select the subnode for the manager you want to edit.
After you make changes to the manager information, click Update. This results in the manager entries in the Enterprise Manager repository to be updated with the new values.
If a manager is configured before using this Enterprise Manager configuration page, Enterprise Manager continues to keep the manager as a valid manager even though the manager may be down or permanently removed.
The list of managers is not refreshed.
To remove a configured manager, perform the following steps:
Navigate to Application Dependency and Performance.
From the Targets menu, select Middleware. In the Related Links section, click Application Dependency and Performance.
Click the Registration tab.
Click + (plus sign) next to the Managers node in the tree, then select the subnode for the manager you want to remove.
Click Remove in the main pane.
Deleting a manager from Enterprise Manager does not uninstall and remove the manager from the remote host where the manager is located and may be running. Remove only deletes the manager entry from the Enterprise Manager repository.
To shut down the manager after the Remove operation, execute the acshut.sh/.bat command from the command line.
To disable a configured manager:
Click + (plus sign) next to the Managers node in the tree, then select the subnode for the manager you want to disable.
Deselect Enable Request Monitoring.
Click Update.
When you deselect the Enable Request Monitoring option, the manager settings are preserved. The UI displays these managers as disabled. There will not be any further information under the disabled manager in the tree.
ADP provides a grammar for the emctl tool which can be used to start, stop, and list the ADP Engines. The details of the grammar and its usage patterns are explained in Table 39-46.
Table 39-46 Extended ADP emctl Commands
| Command | Description |
|---|---|
|
emctl extended oms adp list |
Queries and lists all the ADP Managed servers from the Repository. |
|
emctl extended oms adp start -server=<server_name1>,<server_name2>... For example: emctl extended oms adp start -server=EMADPENGINE,MYADPDMGR |
Starts the ADP Managed servers mentioned in command line arguments. The servers could be running on the same local host on which the OMS is running or can be running on a remote host. |
|
emctl extended oms adp start -all |
Starts all ADP Managed servers on the same local host on which the OMS is running. |
|
emctl extended oms adp start -global |
Starts all ADP Managed servers, even if they are running on remote hosts (remote to this OMS host). |
|
emctl extended oms adp stop -server=<server_name1>,<server_name2>... For example: emctl extended oms adp stop -server=EMADPENGINE,MYADPMGR |
Stops the ADP Diagnostics Managed servers mentioned in command line arguments. The servers could be running on the same local host on which the OMS is running or can be running on a remote host. |
|
emctl extended oms adp stop -all |
Stops all ADP Managed servers that are running on the same local host on which the OMS is running. |
|
emctl extended oms adp stop -global |
Stops all ADP Managed servers, even if they are running on remote hosts (remote to this OMS host). |
|
emctl extended oms adp status -server=<server_name1>,<server_name2>... For example: emctl extended oms adp status -server= EMADPENGINE,MYADPMGR |
Shows the status of the ADP Diagnostics Managed servers mentioned in command line arguments. The servers could be running on the same local host on which the OMS is running or can be running on a remote host. |
|
emctl extended oms adp status -all |
Status of all the ADP Engines in this domain. |
|
emctl extended oms adp -help |
Shows the online help for the ADP Diagnostics commands. |