| Oracle® Enterprise Manager Administration 10g Release 5 (10.2.0.5) Part Number E14586-03 |
|
|
PDF · Mobi · ePub |
| Oracle® Enterprise Manager Administration 10g Release 5 (10.2.0.5) Part Number E14586-03 |
|
|
PDF · Mobi · ePub |
This chapter describes how to configure services in Oracle Enterprise Manager 10g Grid Control Console. It contains the following sections:
This table provides a summary list of all the service management features and their requirements.
Table 14-1 Summary of Service Management Tasks
A system is the set of infrastructure components, for example hosts, databases, and application servers that work together to host your applications. Before you create a service, you must specify the system that will be used to host your service. Refer to the Enterprise Manager Online Help for details on defining systems.After you have selected the system, you must mark one or more components as key components that are critical to running your service. These key components are used to determine the availability of the service and identify possible causes of service failure for root cause analysis.
Before you create a service, you must be familiar with the concepts of service management as described in the Oracle Enterprise Manager Concepts. You must also do the following:
Install the Management Agent on the hosts on which the components of your service have been installed.
Discover all the components for your service so that they can be listed as Enterprise Manager targets.
Define systems on which the service is to be hosted.
To create a service, click the Targets tab and Services subtab. The Services main page is displayed. Select a service from the Add drop-down list and click Go. The following screen is displayed:
Follow the steps in the wizard to create your service. This involves the following:
Identifying the type of service to be created. You can define different types of services based on your requirement. Some of the services that you can define are Generic Service, Web Application, Aggregate Service, and Forms Application. A Generic Service is used to monitor a variety of different protocol based services. A Web Application is used to monitor Web transactions. Enterprise Manager provides additional monitoring and diagnostics features for Web applications. A Forms Application is used to monitor Forms transactions. Each Forms transaction can consist of one or more actions that can be monitored. You can also define other services that are specific to an application such as the OCS Service. You can combine one or more services to form an Aggregate Service.
Selecting a system target that hosts this service and then marking the system's key components that are critical for running the service. These key components are used to determine the availability of the service and identify possible causes of service failure. For more information on defining systems and monitoring them, refer to the Service Management chapter in Oracle Enterprise Manager Concepts.
Setting up the availability definition for the service. This can be service test-based or system-based. If you select service test, the service's availability is based on the execution of the service test by the one or more key beacons. If availability is based on system, availability is based on the status of one or more key components of the system.
Adding one or more beacons to monitor service tests. Click Add to add one or more beacons for monitoring the service. It is recommended that you use beacons that are strategically located in your key user communities in order for them to proactively test the availability of the service from those locations. If no beacons exist, click Create to create a new beacon.
Note:
Beacons marked as key beacons will be used to determine the availability of the service. The service is available if one or more service tests can be successfully executed from at least one key beacon.For Web applications, you can compare the performance of the service test execution from each remote beacon against the local beacon.
Defining the metrics that will be used to measure the performance of the service. Performance metrics can be based on service tests or system components. After defining the metrics, you can specify the critical and warning thresholds. You can also specify the metric that is to be displayed in a graphical format on the Service Home page.
Defining the metrics that will be used to measure the user demand for the service. Usage metrics can be based on one or more system components. After defining the metrics, you can specify the critical and warning thresholds. You can also specify the metric that is to be displayed in a graphical format on the Service Home page.
Note:
You can define usage metrics for system-based services only.After you have completed all the steps in the wizard, click Finish to create your service. Refer to the Enterprise Manager Online Help for more details on these pages.
After you have created the service, you can configure it further by selecting an option from the Monitoring Configuration page. To configure a service, select a service from the Services main page and click Configure to go to the Monitoring Configuration page. The following screen is displayed.
The following options are available:
Availability Definition
Performance Metrics
Usage Metrics
Apart from these options, for Web applications, the end-user and request performance monitoring features can also be configured. For more information, refer to the following sections:
You can modify the availability definition (service test-based or system-based) for the selected service. If availability is based on service tests, you can specify whether the service should be available when:
Note:
A service test is considered available if it can be executed by at least one key beacon. If there are no key beacons, the service test will have an unknown status.If availability is based on the key system components, you can specify whether the service should be available when:
All key components are up (Default)
At least one key component is up
You can also mark one or more components as key system components that will be used to compute the availability of the service. Key system components are used to determine the possible root cause of a service failure. For more information, refer to "Root Cause Analysis Configuration".
You can also indicate whether the service test is a key test by enabling the Key Service Test checkbox. Only key service tests are used to compute the availability of the service. You can then select the beacons that will be used to execute the key tests and determine the availability of the service.
Performance metrics are used to measure the performance of the service. If a service test has been defined for this service, then the response time measurements as a result of executing that service test can be used as a basis for the service's performance metrics. Alternatively, performance metrics from the underlying system components can also be used to determine the performance of the service. You can do the following:
Add a performance metric for a service test. After selecting a metric, you can choose to:
Use the metric values from one beacon. Choose this option if you want the performance of the service to be based on the performance of one specific location.
Aggregate the metric across multiple beacons. Choose this option if you want to consider the performance from different locations. If you choose this option, you need to select the appropriate aggregation function:
Table 14-2 Beacon Aggregation Functions
| Function | Description |
|---|---|
|
The maximum value of the metric from data collected across all beacons will be used. Use this function if you want to measure the worst performance across all beacons. |
|
|
The minimum value of the metric from data collected across all beacons will be used. Use this function if you want to measure the best performance across all beacons. |
|
|
The average value of the metric will be used. Use this function if you want to measure the 'average performance' across all beacons. |
|
|
The sum of the metric values will be calculated. Use this function if you want to measure the sum of all response times across each beacon. |
Add a performance metric for the underlying system components on which the service is hosted. After selecting a metric for a target, you can choose to:
Use the metric from a specific component. Choose this option if you want the performance of the service to be based on the performance of one specific system component.
Aggregate the metric across multiple components. Choose this option if you want to consider the performance from multiple components. If you choose this option, you need to select the appropriate aggregation function.
Table 14-3 System Aggregation Functions
| Function | Description |
|---|---|
|
The maximum value of the metric across all components will be used as the value of this performance metric for the service. |
|
|
The minimum value of the metric across all components will be used as the value of this performance metric for the service. |
|
|
The average value of the metric across all components will be used. |
|
|
The sum of values of metrics across all components will be calculated. |
Note:
When a system is deleted, performance metrics associated with the system will not be collected.Edit a performance metric that has been defined. For service test-based performance metrics, you can modify the beacon function that should be used to calculate the metric values. For system-based performance metrics, you can modify the target type, metric, and whether the aggregation function should be used. You can also modify the Critical and Warning thresholds for the metric.
Delete a performance metric that has been defined.
Usage metrics are used to measure the user demand for the service. Usage metrics are collected based on the usage of the underlying system components on which the service is hosted. You can do the following:
Add a usage metric. After selecting a metric for a target, you can choose to:
Use the metric from a specific component. Use this option if you want to monitor the usage of a specific component.
Aggregate the metric across multiple components. Use this option if you want to statistically calculate the usage across multiple components. If you choose this option, you need select the appropriate aggregation function.
Table 14-4 Aggregation Functions - Usage Metrics
| Function | Description |
|---|---|
|
The maximum value of the metric across all components will be used as the value of this usage metric for the service. |
|
|
The minimum value of the metric across all components will be used as the value of this usage metric for the service. |
|
|
The average value of the metric across all components will be used. |
|
|
The sum of the values of metrics across all components will be calculated. |
Edit a usage metric that has been defined.
Delete a usage metric that has been defined.
Business metrics are used to measure the performance of business in an organization. These metrics are based on business indicators that can assess the business performance. You can define one or more system based metrics and specify critical and warning thresholds for these metrics. You can define business metrics for Generic Services and Aggregate Services.
Note:
This option is available only if one of the system components is a service and has business metrics associated with it.You can do the following:
Add a business metric. After selecting a metric for a target, you can choose to:
Use the metric from a specific component. Use this option if you want the business metric to be based on the performance of one specific system component
Aggregate the metric across multiple components. Use this option if you want to measure the business performance from multiple components. Select the appropriate aggregation function from the drop down list. If you choose this option, you need select the appropriate aggregation function.
Table 14-5 Aggregation Functions - Usage Metrics
| Function | Description |
|---|---|
|
The maximum value of the metric across all components will be used as the value of this business metric for the service. |
|
|
The minimum value of the metric across all components will be used as the value of this business metric for the service. |
|
|
The average value of the metric across all components will be used. |
|
|
The sum of the values of metrics across all components will be calculated. |
Edit a business metric that has been defined.
Delete a business metric that has been defined.
You can define system based metrics only. You can configure non-system based metrics by using the Data Exchange feature which facilitates data transfer between Enterprise Manager Grid Control and other external monitoring systems. For details, refer to the Oracle Enterprise Manager Integration Guide.
You can add additional service tests and specify one or more beacons that will execute these service tests. To add a service test or modify an existing service test, click the Service Test and Beacons link on the Monitoring Configuration page. The Service Tests and Beacons page appears. You can do the following:
Add one or more service tests for your service. Select the Test Type and click Add. Some of the test types that can be defined are FTP, Web Transaction, DNS, SOAP and others. The Create Service Test page is displayed. Refer to the Enterprise Manager Online Help for details on the various types of service tests.
Note:
While defining a SOAP (Simple Object Access Protocol) service test, if the WSDL URL to be accessed is outside the company's intranet, proxy settings need to be added to the
$OMS_HOME/sysman/config/emoms.properties file.
For example, to set up www-proxy.us.oracle.com as proxy, specify the values as follows:
proxyHost=www-proxy.us.oracle.com proxyPort=80 dontProxyFor=us.oracle.com,oraclecorp.com
The proxyUser,proxyPwd,proxyRealm,and proxyPropsEncrypted properties are used to configure an authenticated proxy. After you have modified the proxy settings, you must restart the Oracle Management Service for the changes to be effective.
After you have created the service test, you must enable it. If your service test is not enabled, it will not be executed by any of the beacons.
Create, add, or remove a beacon. When you identify the beacon locations, select locations on your internal network or on the Internet that are important to your e-business. These are typical locations where your end users are located. For example, if your business is hosted in Canada and you have customers in the United States, use a beacon installed on a host computer in the United States to measure the availability and performance of your applications.
After you have created the service test, you can verify it by clicking Verify Service Test.
Note:
You can define one or more service tests as key tests. These key tests are used to monitor the availability and performance of your service. Only service tests that are enabled can be designated as key tests. To set up a service test as a key test, click the Availability Definition link at the bottom of the page.For more details on creating different types of service tests, refer to the Enterprise Manager Online Help.
This section lists additional beacon related configuration tasks.
Configuring SSL Certificates for the Beacon: To configure SSL certificates for Web transaction and Port Checker service tests, follow the steps given below:
Configuring Dedicated Beacons: Beacon functionality on an agent requires the the use of an internal Java VM. The use of a Java VM can increase the virtual memory size of the agent by several hundred megabytes. Because of memory constraints, it is preferable to create beacons only on agents that run on dedicated hosts. If you are running large numbers of tests (e.g., several hundred per minute) on a given beacon, you may also wish to install that beacon's agent on a dedicated host. To take full advantage of dedicated hardware, edit the agent's $ORACLE_HOME/sysman/config/emd.properties file. as follows:
Set the property, ThreadPoolModel=LARGE. This allows the agent to simultaneously run many threads.
Set the property, useAllCPUs=TRUE. This allows the agent to run on multiple CPUs simultaneously.
Append -Xms512m -Xmx512m to the agentJavaDefines property. This increases the Java VM heap size to 512 MB.
Configuring a Web Proxy for a Beacon: Depending on your network configuration, the beacon may need to be configured to use a Web proxy. To configure the Web proxy for a beacon, search for the beacon in the All Targets page. Select the beacon you wish to configure and click Configure. Enter the properties for the Web proxy. For example, to set up www-proxy.us.oracle.com as the beacon's Web proxy, specify the values as the following:
Proxy Host: www-proxy.us.oracle.com Proxy Port: 80 Don't use Proxy for: .us.oracle.com,.oraclecorp.com
Note:
You cannot play Siebel service tests and Web Transaction (Browser) service tests on the same machine.To run a Web Transaction (Browser) service test, you need beacons that are running on an 10.2.0.4 or later Management Agent on Windows. The beacon drives an Internet Explorer process. This process runs as the same user as the Management Agent service.
Verifying Web Transaction (Browser) test involves the following 3 steps:
Navigate to the Service Tests and Beacons page and select a Web Transaction (Browser) test from the list.
Click Verify Test. The Verify Service Test page is displayed.
Select a Windows beacon and click Perform Test.
One of the common problems that you may encounter is that the Perform Test does not respond immediately.
There may be several reasons for this delay. Complicated tests may take longer to run. However, the most probable cause for delayed response is when the Internet Explorer process from the beacon is waiting for manual confirmation, which is invisible when run as a process that does not interact with desktop.
You may need to change the browser settings on the beacon machine. These settings need to be changed for the Local Service account and are account specific. Therefore, any changes to the Internet Explorer process that was opened from the Start menu on the beacon machine, will not affect the Internet Explorer process instantiated from the beacon which runs in an invisible window. To make the Internet Explorer window instantiated from the beacon visible:
Login as administrator to the Windows machine on which the Management Agent is running.
From the Start menu, click Run, type services.msc and click Enter.
Find the Management Agent in the list of Windows services, e.g. OracleServiceagent1.
Right click the Management Agent and select Properties.
Click the Log On tab.
Click the Select Allow service to interact with desktop checkbox and click OK.
Right click the Management Agent and select Stop, and then select Start.
To check Internet Explorer on the Management Agent machine for any dialog confirmations. For example, SSL Certificates and security warnings.
Use the previous procedure to make the Internet Explorer process instantiated from the beacon visible.
Launch Enterprise Manager (from any machine), and navigate to the Service Tests and Beacons page of the corresponding service target.
Select the Web Transaction (Browser) service test, and click Verify Service Test.
From the Verify Service Test page, select the beacon running on the Windows, and click Perform Test.
If it is a SSL Certificates issue, From the Windows machine on which the Management Agent is running, you will see an Internet Explorer window open and a Security Alert with a View Certificate option is displayed.
Select the Certificate Path tab, click the root certificate, which should have a red cross next to the name, and click the View Certificate button.
Click Install Certificate and proceed with the Certificate Import Wizard. (Click Next and Yes for any prompts).
Note:
Other security warnings may also pause the Internet Explorer automation process. Typically, these security warnings have a check box that allow you disable the display of all future warning messages for all Web sites. These warnings may have already been dismissed on the machine where the transaction was recorded.Once this manual step has been performed, the Internet Explorer process should be in auto-pilot mode until the service test is completed. The warning message will not be displayed when you play back the service test next time.
Click Perform Test again to make sure the entire service test is completed automatically the second time.
To make the Internet Explorer window instantiated from the beacon invisible, you can repeat the steps 1 to 5, uncheck the Select Allow service to interact with desktop checkbox and continue with step 7.
To configure the proxy setting for Web Transaction (Browser) service tests:
Make the Internet Explorer process instantiated from the beacon visible.
Launch Enterprise Manager (from any machine), and navigate to the Service Tests and Beacons page of the corresponding service target.
Select the Web Transaction (Browser) service test, and click Verify Service Test.
From the Verify Service Test page, select the beacon running on the Windows, and click Perform Test.
From the Windows machine where the Management Agent is running, you should see two Internet Explorer windows open. From either of the windows, select the Tools > Internet Options.
Click the Connections tab and then click LAN Settings, and make all relevant changes there. These changes apply to all service tests running on this beacon.
Close both the Internet Explorer windows.
Click Perform Test again to make sure the entire service test is completed automatically the second time.
Make the Internet Explorer process instantiated from the beacon invisible.
Note:
At any one time, each test run launches two Internet Explorer windows. One of the windows schedules the steps during playback. The other window actually shows the site being played back.You can use Root Cause Analysis (RCA) to filter a set of events to determine the cause of a higher level system, service, or application problem. RCA can help you to eliminate apparent performance problems that may otherwise appear to be root causes but which are only side effects or symptoms of the actual root cause of the problem, allowing you to more quickly identify problem areas. You can view the RCA results on the Home page or Topology page of any service that is currently down. The Topology page allows you to see a graphical representation of the service, system and component dependencies with the targets highlighted that RCA has implicated as causing the service failure.
Before running RCA, you can choose to:
Configure the tool to run automatically whenever a service fails.
Disable RCA by changing the default Analysis Mode to Manual.
Define component tests for the service and thresholds for individual tests.
To configure Root Cause Analysis, follow these steps:
From the Service Home page, click Monitoring Configuration.
From the Monitoring Configuration page, click Root Cause Analysis Configuration.
If the current mode is set to Automatic, click Set Mode Manual to disable RCA. If you choose to perform the analysis manually, you can perform the analysis from the Service home page at anytime by choosing Perform Analysis if the service is down. If the current mode is set for Manual, click Set Mode Automatic to enable RCA when the state of the service and its components change
Click the link in the Component Tests column of the table for the key component you want to manage. You can then manage component tests for the service on the Component Tests page by adding, removing, or editing tests. Refer to the Enterprise Manager Online Help for details on defining component tests.
Note:
When you disable RCA and set it back to automatic mode, RCA does not store the previous history results for you, thus providing no history for later reference.Root Cause Analysis (RCA) can provide you with great value by filtering through large amounts of data related to your services and identifying the most significant events that have occurred that are affecting your service's availability. If you are constructing your own services to manage in Enterprise Manager it is important that the services are defined with some thought and planning in order to get the most out of RCA.
The first item to consider in getting the most from RCA is the set of dependencies that your service has on other services or system components. Be sure to identify all of the system components that your service utilizes in order to accomplish its task. If you omit a key component and the service fails, RCA will not be able to identify that component as a possible cause. Conversely, if you include components in the service definition that the service does not actually depend on, RCA may erroneously identify the component as a cause of service failures.
When building service dependencies, keep in mind that you can take advantage of the aggregate service concept that is supported by Enterprise Manager. This allows you to break your service into smaller sub-services, each with its own set of dependencies.
Your services may be easier to manage in the modular fashion, and RCA will consider not only the status of a sub-service (a service that you depend on) but also on any of the system components or service that the sub-service depends on in turn and provides you with the power to encapsulate the services a key component exposes to you in the form of a managed service that your service may then depend on.
The second item to consider in getting the most from RCA is the use of component tests. As you define the system components that your service depends on, consider that there may be aspects of these components that may result in your service failure without the component itself failing. Component tests allow RCA to test the status not only of the target itself but also the status of its key aspects.
The RCA system allows you to create component tests based on any metric that is available for the key component. Remember, this includes any user-defined metrics that you have created for the component, allowing you great flexibility in how RCA tests the aspects of that component should your service fail.
You can record a transaction using an intuitive playback recorder that automatically records a series of user actions and navigation paths. You can play back transactions interactively, know whether it is internal or external to the data center, and understand the in-depth break-out of response times across all tiers of the Web application for quick diagnosis.
You must install the transaction recorder in your computer to record transactions. The transaction recorder is also used for playing back and tracing transactions. The transaction recorder is downloaded from the Enterprise Manager Grid Control server the first time any of these actions is performed. The transaction recorder requires some Microsoft libraries to be installed in your computer. If these libraries are not present during installation, they are automatically downloaded and installed from the Microsoft site. Make sure that your computer has access to the Internet to download these files. After the installation has been completed, you may need to restart your computer to make the changes effective.
For each service, you can define the frequency (which determines how often the service will be triggered against your application) and the performance thresholds. When a service exceeds its performance thresholds, an alert is generated.
To define metrics and thresholds, click Monitoring Settings for Tests link on the Service Tests and Beacons page. The Metric and Policy Settings page is displayed. Click the Monitoring Settings link. The Monitoring Settings - Thresholds page appears.
View By Metric, Beacon - In this view, you can click Add Beacon Overrides to override the default threshold values for one or more beacons. In this case, the default thresholds will only be used for beacons without any overrides. Any new beacons added to the service will use the default thresholds. Click Add Metric to add one or more metrics.
View By Beacon, Metric - In this view, you can click on the Default icon to toggle between Edit and View modes for a specific metric. In the Edit mode, you can modify the parameters of the metric. You can also modify the parameters of the metric for a specific beacon. In the View mode, the default parameters of the metric will be used.
Apart from these procedures, you can also define metrics at the step, and step group level for Web transactions. You can choose either of the following views:
View By Step, Metric, Beacon: In this view, you can click Add Beacon Overrides to override the default threshold values for one or more beacons. In this case, the default thresholds will only be used for beacons without any overrides. Any new beacons added to the Web transaction will use the default thresholds. Click Add Metric to define thresholds for one or more metrics. Alerts are generated only if the value of the Data Granularity property is set to 'Transaction' for the service tests. For more information on the Web transaction properties, refer to the Create / Edit Service Test - Web Transaction help page in the Enterprise Manager Online Help.
View By Step, Beacon, Metric: In this view, you can click on the Default icon to toggle between Edit and View modes for a specific metric. In the Edit mode, you can modify the parameters of the metric for a specific beacon. In the View mode, the default parameters of the metric will be used. Alerts are generated only if the value of the Data Granularity property is set to ' Step'.
To define the default collection frequency and collection properties, click the Collection Settings tab on the Monitoring Settings page. You can do the following:
Specify the default collection frequency for all the beacons. To override the collection frequency for a specific beacon, click Add Beacon Overrides.
Specify the collection properties and their corresponding values for one or more beacons.
Refer to the Enterprise Manager Online Help for more details on the defining the collection intervals and performance thresholds.
Aggregate services consist of one or more services, called subservices. A subservice is any service created in Enterprise Manager. The availability, performance, business criteria, and usage for the aggregate service depend on the availability, performance, business criteria, and usage for the individual subservices comprising the service. To create an aggregate service, navigate to the Services main page, select Aggregate Service from the Add drop-down list and click Go. The Add Aggregate Service page appears. Creating an Aggregate Service involves the following:
Specifying the name and time zone for the service.
Adding the services that make up this aggregate service.
Establishing the availability definition for the aggregate service. Availability of an aggregate service depends on the availability of its constituent subservices. The availability for a subservice may depend on the successful execution of a service test or on the availability of the system components on which the subservice runs, depending how the subservice was defined.
Defining the metrics used to measure the performance of your aggregate service. You can add performance metrics from single subservices, or based on statistical aggregations of more than one metric. Once you have selected the performance metrics, you can set the thresholds used to trigger critical and warning alerts, or remove metrics you no longer want.
Defining the metrics used to measure the usage of your aggregate service. Usage metrics can be based on the metrics of one or more system components. You can add usage metrics from single subservices, or based on statistical aggregations of more than one metric. Once you have selected the usage metrics, you can set the thresholds used to trigger critical and warning alerts, or remove metrics you no longer want.
Defining the metrics that are used to measure of the performance of business in the organization. These metrics are based on business indicators that can assess the business performance.You can add business metrics from single subservices, or based on statistical aggregations of more than one metric. Once you have selected the business metrics, you can set the thresholds to trigger critical and warning alerts, or remove metrics you no longer want.
After you have created an aggregate service, you can add or remove its constituent subservices, modify the availability definition and add or delete performance or usage metrics. Refer to the Enterprise Manager Online Help for details on these operations.
WARNING:
If you delete or remove a subservice from an aggregate service, the aggregate service performance, usage, and business metrics may be affected if they are based on a deleted subservice's metrics.
Enterprise Manager allows you to monitor the response time data generated by actual end-users as they access and navigate your Web site. You can gather end-user performance data and monitor the performance of the pages within your Web application. The Web servers such as OracleAS Web Cache, Oracle HTTP Server, and Apache HTTP Server collect the end-user performance data and store it in the log file. Enterprise Manager processes this data and uploads it to the Management Repository. You can then view and analyze this data on the Page Performance page.
To gather the end-user performance data, you must configure one of the following Web servers so that Website activities are logged and stored in the correct format.
After you have configured one of these Web servers, you can enable the collection of end-user performance data. You can then view the end-user performance data on the Page Performance page in Enterprise Manager.
Before you configure the Web server, you must do the following:
Create a Web application target that contains one of these Web servers.
Make this Web server as a key system component for your Web application. If this Web server is a part of the Redundancy Group, make sure that the Redundancy Group is a key system component of your Web application. To enable end-user performance monitoring, you must configure the specific Web server within the Redundancy Group.
Note:
If you are using the Oracle HTTP Server Based on Apache 2.0, the Redundancy Group is referred to as the HTTP Server HA Group.The following sections provide instructions on configuring the Web server for End-User Performance Monitoring:
To enable End-User Performance Monitoring, you can use either of the following Apache server versions:
Oracle HTTP Server Based on Apache 2.0
Apache HTTP Server 2.0 or higher (This can be downloaded from http://www.apache.org)
Before configuring either of these Apache server versions, you must perform the following steps:
In the Agent Home page, select either Oracle HTTP Server or Apache HTTP Server as a target type.
Add the target of the corresponding type and make sure the following properties are set in the Monitoring Configuration page:
For Oracle HTTP Server, fill in the version number (stdApache10.1.2), Log file directory and Log file name.
For Apache HTTP Server 2.0, fill in the install home directory, Log file directory and Log file name.
Note:
If the Oracle HTTP Server is installed before the Management Agent has been installed, and is up and running during agent installation, then the target will be discovered automatically. Otherwise you need to manually create the Oracle HTTP Server target and specify the following properties: Machine name, Port number, Version of the Apache Server, Oracle home path, Log file directory (for EUM), Log file name (for EUM) where EUM refers to End-User Performance Monitoring.Make sure you have created the Web application with this Web server target. For details on creating a Web application, refer to the pre-requisites in the "Configuring End-User Performance Monitoring" section.
To configure the Apache server and enable collection of end-user performance data, follow the steps given below:
Navigate to the Web Application Home page in the Grid Control Console and click Monitoring Configuration.
Click Manage Web Server Data Collection. You will see a table which lists the Web Servers including Oracle HTTP Server Based on Apache 2.0 or higher, Apache HTTP Server version 2.0 or higher, or OracleAS Web Cache.
Select the Oracle HTTP Server or Apache HTTP Server from the table and click Configure. Enter the host credentials required for modifying the Apache configuration file.
After logging in, you will see a table containing the list of sites that are being hosted by the Apache server. These include a list of virtual hosts defined by the user in the Apache Configuration file. The up and the down arrows under the Monitoring Status column shows the corresponding site is currently being monitored. For each site, check or uncheck the Enable Monitoring checkbox to indicate whether this site is to be monitored. For the site that is to be monitored, enter the log file name in the text box to indicate the location in which the end-user performance data is to be stored. By default, the log file will be created under the logs/directory under Apache root directory. To save the log file in a different directory, enter a file name with the absolute path.
Make sure that the log file name and the location you specify here match the Log file name and Log file directory in the Monitoring Configuration page of the Oracle HTTP Server or Apache HTTP Server target.
You can also use the one button accelerator to enable all sites or disable all sites all at once.
To selectively disable or enable certain URLs on a specific site, select the site, click Set URLs. Click Insert Before or Insert After to create a URL rule and place it in the desired place among all URL rules. A URL rule contains a URL Pattern, URL Pattern Type, and a check box indicating if this URL is to be monitored or not. For example, a URL rule with URL Pattern "abc" and URL Pattern Type "Ends With" and Monitor unchecked means that any URL ending with "abc" will not be monitored by End-User Performance Monitoring. The user can also delete a URL rule, move a URL rule up or down to increase or decrease its priority.
After you have made the configuration changes, click OK to go to the Apache Restart page. Restarting the Apache server will finalize all configuration changes, and end-user performance data will be logged by the Apache server.
After you have configured the Apache server, you will return to the Manage Web Server Data Collection page. You can now enable the collection of end-user performance data. For more details, refer to "Starting and Stopping End-User Performance Monitoring". If you do not see data after End-User Performance Monitoring has been enabled, refer to the "Verifying and Troubleshooting End-User Performance Monitoring".
To set up the Third Party Apache HTTP Server 2.0, follow these steps:
Install the third party Application Server.
Install Apache HTTP Server 2.0.
Install the plug-in for the Apache HTTP Server 2.0 that was provided by the Application Server.
Ensure that the Web application works with the Apache HTTP Server2.0 server. You can then follow the steps to configure the Apache server and enable collection of end-user performance data.
Enterprise Manager uses data from Oracle Application Server Web Cache to gather statistics about the performance of pages within your Web applications. As a result, you must configure Oracle Application Server Web Cache to ensure that it logs your Web site activity and that the data is in the correct format.
When Oracle Application Server Web Cache is properly configured, Enterprise Manager can begin collecting the end-user performance data and load it into the Oracle Management Repository.
See Also:
"Configuring End-User Performance Monitoring" in the Oracle Application Server Web Cache Administrator's Guide.The following sections describe how to configure and collect end-user performance data if you are using the OracleAS Web Cache:
To configure the OracleAS Web Cache for End-User Performance Monitoring, follow the instructions in the following sections:
Navigate to the Web Application Home page in the Grid Control Console and click Monitoring Configuration.
Click Manage Web Server Data Collection. Enterprise Manager displays the Manage Web Server Data Collection page.
Select the Web Cache target and click Configure. Enterprise Manager displays the login dialog box for the Oracle Application Server Control.
Tip:
If the login dialog box does not appear or if you see an error message in your browser window, navigate to the Web Cache Home page. Click Administer in the Related Links section. You will be prompted for the user name and password for the Application Server Control. Click Administration and scroll down and click End-User Performance Monitoring.Enter the username and password for the Application Server Control user or the ias_admin account. The password for the ias_admin account is defined during the installation of Oracle Application Server.
After you have logged into Oracle Application Server Control, you can then configure the Oracle Application Server Web Cache using the Set Up End-User Performance Monitoring page. Check the Enable End-User Performance Monitoring checkbox and click OK to enable End-User Performance Monitoring at the Web Cache level.
At the site-level configuration section, select a site and check Enable Monitoring for that site.
Tip:
Disabling End-User Performance Monitoring at the Web Cache level will override site-level settings.From the drop-down list, select the Access Log Format as access log:WCLF for each site you want to monitor. If this format is not in the list, click Use Required Log Format. This automatically picks up the End-User Performance Monitoring log format.
Click the link under the URLs to Monitor column. The URLs To Monitor page is displayed. Click Add Another Row to create a URL rule and place it in the desired place among all URL rules. A URL rule contains a URL Pattern, URL Pattern Type, and a check box indicating if this URL is to be monitored or not. For example, a URL rule with URL Pattern "abc" and URL Pattern Type "Ends With" and Monitor unchecked means that any URL ending with "abc" will not be monitored by End-User Performance Monitoring. The user can also change the priority of the URL rule by clicking Reorder. Click OK to save the changes and return to the Set Up End-User Performance Monitoring page.
After you have configured the Web Cache in the Set Up End-User Performance Monitoring page, click OK to save the changes. You will then return to the Web Cache Administration page in Oracle Application Server Control. Click Restart to restart the Web Cache. For more detailed information about configuring these options, click Help on the Set Up End-User Performance Monitoring page.
Close the Application Server Control browser window and return to the Manage Web Server Data Collection page in the Grid Control console. You can now enable the collection of end-user performance data. For more details, refer to "Starting and Stopping End-User Performance Monitoring". If you do not see data after end-user performance has been enabled, refer to "Verifying and Troubleshooting End-User Performance Monitoring".
To configure the Oracle Application Server Web Cache Manager 9.0.4, follow the instructions given in these sections:
Navigate to the Web Application home page in the Grid Control console and click Monitoring Configuration.
Click Manage Web Server Data Collection. Enterprise Manager displays the Manage Web Server Data Collection page.
Select the Web Cache target and click Configure. Enterprise Manager displays the login dialog box for the Web Cache Manager.
Tip:
If the login dialog box does not appear or if you receive an error message in your browser window, you may have to start the Oracle Application Server Web Cache Manager. For more information about starting and using Oracle Application Server Web Cache Manager, refer to the Oracle Application Server Web Cache Administrator's Guide.Enter the username and password for the Web Cache administrator account. The first time you log in to the Oracle Application Server Web Cache administrator account, the password is administrator. The password for the ias_admin account is defined during the installation of Oracle Application Server.
Enable OracleAS Web Cache logging for End-User Performance Monitoring:
Select Logging and Diagnostics and then select End-User Performance Monitoring in the OracleAS Web Cache Manager navigator frame.
You can enable monitoring for a particular Web cache or for an entire site.
To enable monitoring for a particular Web cache, select the Web cache from the Cache-Specific End-User Performance Monitoring section and click Enable.
Be sure to enable the Web cache that you are using as a front-end to your Web application.
To enable monitoring for the entire site, select the site from the Site-Specific End-User Performance Monitoring section and click Enable.
Configure Oracle Application Server Web Cache to use the Web Cache Log Format (WCLF):
Select Logging and Diagnostics and then select Access Logs in the OracleAS Web Cache Manager navigator frame.
In the Cache-Specific Access Log Configuration table, click Edit Selected and enable the access log for your selected cache.
In the Site-Specific Access Log Configuration table, make sure that the Format style of the selected Site Name is WCLF and that it is enabled.
Click Apply Changes at the top of the Web Cache Manager window and restart OracleAS Web Cache by clicking Restart on the Web Cache Manager Cache Operations page.
Close the Web Cache Manager browser window and return to the Manage Web Server Data Collection page in the Grid Control console. You can now enable the collection of end-user performance data. For more details, refer to "Starting and Stopping End-User Performance Monitoring". If you do not see data after end-user performance has been enabled, refer to "Verifying and Troubleshooting End-User Performance Monitoring".
If you are managing an earlier version of the Oracle Application Server using the Oracle Enterprise Manager 10g Grid Control Console, you can monitor your Web applications with End-User Performance Monitoring, but you cannot configure your Oracle Application Server Web Cache instance from within the Grid Control console.
Instead, you configure End-User Performance Monitoring for Oracle Application Server Web Cache 9.0.2 and 9.0.3 by running the chronos_setup.pl script on the computer that hosts your Oracle HTTP Server.
Before you begin, consider the following:
The chronos_setup.pl script is installed in the bin directory of your Management Agent home when you install the Management Agent using the instructions in Oracle Enterprise Manager Grid Control Installation and Basic Configuration.
You must run the chronos_setup.pl script as an operating system user with the privilege to write to the document root of your Oracle HTTP Server.
If you have trouble running the script, run it with no arguments to display the help text.
To enable End-User Performance Monitoring for Oracle Application Server Web Cache 9.0.2 or Oracle Application Server Web Cache 9.0.3, you must run the chronos_setup.pl script three times, each time with a different argument:
Once to configure the document root for each Web server in your Web site
Once to configure Oracle Application Server Web Cache
Once to start collecting response time data
The following sections describe each step of enabling End-User Performance Monitoring for Oracle Application Server Web Cache 9.0.2 or Oracle Application Server Web Cache 9.0.3.
When you run the chronos_setup.pl script with the webserver argument, the script:
Creates a new directory inside the document root. The directory is called:
oracle_smp_chronos
Installs two files into the oracle_smp_chronos directory:
oracle_smp_chronos.js oracle_smp_chronos.gif oracle_smp_eum_init.js oracle_smp_eum_main.js
The oracle_smp_chronos.js must be installed in the document root of each Web server that serves content for your Website.
Note:
If you have more than one document root, you must run the
chronos_setup.pl script on each document root.For example, if Oracle Application Server Web Cache and your Web server are on different machines and an Oracle Management Agent is present on the Web server machine, you must run the chronos_setup.pl script with the webserver option on the Web Server host to configure the document root for the remote Web server.
If Oracle Application Server Web Cache and your Web server are installed on different machines and you have no plans to install a Management Agent or to monitor the Web server, you will need to create a directory called oracle_smp_chronos under the Web server document root directory, and using FTP, place the oracle_smp_chronos.js file in the oracle_smp_chronos directory.
To configure the document root for each Web server:
Change directory to the /bin directory in the Management Agent home directory.
For example:
$PROMPT> cd AGENT_HOME/bin
Make sure you have write access to the Web server document root directory and then run the script as follows:
$PROMPT> perl chronos_setup.pl webserver location_of_the_webserver_DocumentRoot
An example of a Document Root is as follows:
$ORACLE_HOME/Apache/Apache/htdocs
To find the location of the document root, you can perform either of these steps:
Log in to the Oracle Application Server Release 2 (9.0.2) Enterprise Manager Web site and navigate to the Oracle HTTP Server Home Page. The document root is displayed in the General section of the HTTP Server Home Page.
Use a text editor or a command-line search utility to search for the term DocumentRoot in the following Oracle HTTP Server configuration file:
$ORACLE_HOME/Apache/Apache/conf/httpd.conf
To configure Oracle Application Server Web Cache for End-User Performance Monitoring, you run the chronos_setup.pl script with the webcache argument. The script sets up Oracle Application Server Web Cache for End-User Performance Monitoring, and stops and restarts Oracle Application Server Web Cache automatically.
To configure Oracle Application Server Web Cache for End-User Performance Monitoring:
Make sure you have write access to the Oracle Application Server Web Cache directory.
For example, if Web Cache is installed in an Oracle Application Server home directory, you will need access to the IAS_HOME/webcache directory.
Change directory to the /bin directory in the Management Agent home directory.
For example:
$PROMPT> cd /private/agent_home/bin
Run the script as follows:
$PROMPT> perl chronos_setup.pl webcache webcache_installation_directory
Note:
After runningchronos_setup.pl, if you cannot restart Oracle Application Server Web Cache, back out of the configuration process by copying the following files back to their original name and location:
internal.xml<timestamp>
webcache.xml<timestamp>
To start End-User Performance Monitoring, you run the chronos_setup.pl script with the collection argument. The script creates a collection file for the specified target and restarts the agent.
To start End-User Performance Monitoring:
Log in as the user who installed the Management Agent so you have write access to the following directory:
AGENT_HOME/sysman/emd/collection
Change directory to the /bin directory in the Management Agent home directory.
For example:
$PROMPT> cd AGENT_HOME/bin
Locate the name of the Oracle Application Server Web Cache target.
You can locate the name of the target in one of three ways:
From the Oracle Enterprise Manager 10g Grid Control Console, locate the Oracle Application Server Web Cache target on the Targets tab. The name listed in the first column of the Target table is the name you must enter as an argument to the chronos_setup.pl script. Note the use of spaces and underscores.
Search the contents of the targets.xml configuration file, which lists all the targets managed by the Management Agent. Locate the Oracle Application Server Web Cache entry in the file and use the NAME attribute for the Web Cache target. The targets.xml file is located in the following directory of the Management Agent home:
AGENT_HOME/sysman/emd/targets.xml
Use the emctl config agent listtargets command to list the target names and target types currently being monitored by the Management Agent.
See Also:
"Listing the Targets on a Managed Host".Start the collection for the Oracle Application Server Web Cache target by running the script as follows:
$PROMPT> perl chronos_setup.pl collection webcache_targetname
Note:
If the name of the Oracle Application Server Web Cache target includes spaces, you must use quotation marks around the nameOracle Application Server Web Cache is available as a standalone download from the Oracle Technology Network (OTN). The standalone version of Oracle Application Server Web Cache allows you to improve the performance and reliability of your Web server even if you are not using Oracle Application Server.
If you are using standalone Oracle Application Server Web Cache with a third-party Web server, you can still manage Oracle Application Server Web Cache using the Oracle Enterprise Manager 10g Grid Control Console. As a result, you can also use End-User Performance Monitoring to monitor the Web applications that your users access through Oracle Application Server Web Cache.
Configuring End-User Performance Monitoring for standalone Oracle Application Server Web Cache involves the following steps, which are described in the following sections:
To install the standalone version of Oracle Application Server Web Cache:
Navigate to the Oracle Technology Network (OTN):
http://otn.oracle.com/software/content.html
Locate and select the Oracle Application Server Web Cache download option and follow the links for your operating system.
Use the instructions on the OTN Web site to download Oracle Application Server Web Cache.
Use the instructions in the Web Cache readme file to install Oracle Application Server Web Cache in its own Oracle Home.
End-User Performance Monitoring uses data from Oracle Application Server Web Cache to gather statistics about the performance of pages within your Web applications. As a result, Enterprise Manager obtains End-User Performance Monitoring data only when Oracle Application Server Web Cache is configured to improve the performance and reliability of your Web server.
See Also:
Oracle Application Server Web Cache Administrator's Guide for complete instructions for configuring Oracle Application Server Web CacheSpecifically, you must perform the following Oracle Application Server Web Cache configuration tasks:
Change the default listening port of your HTTP Server (for example, 7777) to a new port number (for example, 7778) and restart the HTTP Server.
See Also:
"Specifying Listening Addresses and Ports" in the Enterprise Manager Online Help if you are using Oracle HTTP Server and managing the server with Enterprise Manager.Oracle HTTP Server Administrator's Guide for information about modifying the httpd.conf file if you are not managing the server with Enterprise Manager.
Start Oracle Application Server Web Cache and its administration tools.
Configure Oracle Application Server Web Cache so it receives requests on the default port previously assigned to your Web server (for example, 7777).
Configure Oracle Application Server Web Cache so it so it sends cache misses to your newly defined Web server default port number (for example, 7778), which is also referred to as the origin server.
Create an Oracle Application Server Web Cache site and map the site to your origin server.
Apply the changes and restart Oracle Application Server Web Cache.
Test the installation to be sure Oracle Application Server Web Cache and your Web server are working properly.
After you have installed and configured Oracle Application Server Web Cache and tested the configuration to be sure your Web site data is being cached, you can then enable End-User Performance Monitoring.
The procedure for enabling End-User Performance Monitoring is similar to the procedures documented earlier in this chapter. Use the Oracle Application Server Control for Web Cache 10.1.2 or Oracle Application Server Web Cache Manager for Web Cache 9.0.4 to configure End-User Performance Monitoring, and use Grid Control to start End-User Performance Monitoring, as described in "Starting and Stopping End-User Performance Monitoring".
End User Performance Monitoring feature automatically recognizes all pages with extensions htm, txt, jhtml, shtml, jsp, and asp. However, additional configuration is required if a Web Application has pages with extensions that are not recognized automatically. For example, for Web Applications that have pages with .do extension, you will have to make additional configuration so that they get recognized.
To configure end-user performance monitoring for Web page extensions that are not recognized automatically, do these:
Access the Web Cache or HTTP Server Home Page.
From the Related Links section, click Monitoring Configuration.
To specify single page extensions, provide the following value in the property Additional Optional Properties (for EUM)
pageext <appropriate page extension
For example, if the Web page has the extension .do, then provide the following:
pageext do
To specify multiple page extensions, provide the following value:
pageext <appropriate page extension>/<appropriate page extension>
For example, if the Web pages have the extentions .do and .html, then provide the following:
pageext do/html
By default, Page Performance reports the performance data for the pages identified by URIs without any query parameters. For example, if the complete URL for petstore search page is /petstore/search?cat=cats, then Page Performance reports data only for /petstore/search.
This works fine if the Web Application pages can be identified by URI uniquely without any query parameters. However, it is not possible to identify the pages if a Web Application has the same URI that is used for all pages. For example, the petstore search page URL /petsore?pageid=search and the petstore cart page URL /petsore?pageid=cart.
To configure end-user performance monitoring for Web pages that have the same URI, do these:
Access the Web Cache or HTTP Server Home Page.
From the Related Links section, click Monitoring Configuration.
Provide the following value in the property Page Identifying Parameters (for EUM)
<query parameter name>
For example, if the URI for the petstore search page is /petsore?pageid=search, the specify the following:
pageid
The query parameters specified can be applicable to all URI paths, or specific to particular URI paths.
For example, if you want all URIs that have a query parameter called 'target' or 'event' to be reported with those query parameters, then specify the following:
target,event
For example, if you want the URIs that have '/em' as the path and have 'target' or 'event' to be reported with those query parameters, then specify the following:
/em:target,event
For example, if you want the URIs that have '/em' as the path to be reported, then specify the following:
/em/console:event
To show how the reported data will look like, here is an example. Consider that the following are the URIs for the application:
/portal/page?tab=home&event=login&id=12312312
/portal/page?tab=home&event=submit&id=553634
/portal/page?tab=admin&event=update&id=23423234
/portal/page?tab=admin&event=cancel&id=6784532
If you do not specify anything, then you will see one URI, that is, "/portal/page".
If you specify 'tab', then you will see two URIs, that is, "/portal/page?tab=home" and "/portal/page?tab=admin".
If you specify 'tab,event', then you will see four URIs (and EUM data for each), that is, the following:
"/portal/page?tab=home&event=login"
"/portal/page?tab=home&event=submit"
"/portal/page?tab=admin&event=update"
"/portal/page?tab=admin&event=cancel"
After you have configured the Web server to enable collection, you can then start collecting end-user performance data.
Navigate to the Web Application home page in the Grid Control console and click Monitoring Configuration.
Click Manage Web Server Data Collection. Enterprise Manager displays the Manage Web Server Data Collection page.
In the Interval (minutes) column, enter the interval at which Enterprise Manager will collect performance data.
Check the Collection Enabled checkbox.
Click Apply, review the changes and confirm by clicking Apply again. End-User Performance Monitoring collection is enabled and data will soon be uploaded to the database and shown under the Page Performance page.
To stop collecting end-user performance data:
Navigate to the Manage Web Server Data Collection page.
Clear the check box in the Collection Enabled column of the table and click Apply.
Click Apply again to confirm the changes.
To verify that End-User Performance Monitoring is working properly:
Wait a period of time to allow Enterprise Manager to begin collecting end-user performance data and to start loading the data into the Management Repository. Specifically, you should wait until the next upload of data from the Management Agent to the Management Service. The Management Service then loads the data into the Management Repository. For more information about how Enterprise Manager gathers and uploads to the repository, see Oracle Enterprise Manager Concepts.
Navigate to the Web Application home page, select a Web application and navigate to the Page Performance tab. Verify that there is data in the Slowest Response Times table.
Another way to verify the existence of end-user performance data, is to note the value of the Number of Unprocessed Samples. Samples for an hour that has not ended are referred to as Unprocessed Samples. For example, data is processed for the time period between 10 am to 11 am, 11 am to 12 pm and so on. Therefore, data from 10 am to 11 am will be considered as Unprocessed Samples if the 11 am boundary has not been crossed or if there is no incoming end-user traffic after 11 am. If this is a non-zero value, click Process Samples. End-user performance data is displayed in the Slowest Response Times table.
If you still do not see any data on the Page Performance page, consider the following troubleshooting tips:
Be sure you have completed all the steps required to configure End-User Performance Monitoring. Make sure that the Web server you are using to collect end-user performance data, is either OracleAS Web Cache or Oracle HTTP Server Based on Apache 2.0 (stdApache10.1.2), or Apache HTTP Server (2.0 or higher). You can see the Web server version in the Monitoring Configuration page.
To monitor Web pages from a third party Application Server, follow the instructions for installing an Apache 2.0 server with the Application Server.
Install End-User Performance Monitoring after installing the plug-in for the Application Server.
When using the Apache Configuration page, log in using the same account used to install Apache.
If the Apache server is running on a port less than 1024, the server must be started as root. Apache can be started as root with a lower privileged account by changing ownership of bin/httpd to root and setting its setuid flag. When Apache is started as root, the 'User' and 'Group' directives in httpd.conf need to be set to the user who installed the Apache server.
Note:
Only pages with a Content-Type header of text or HTML will be monitored. Pages that pass through the Apache Server with a Content-Encoding header (like gzip) will not be monitored because the JavaScript tag cannot be added to these pages.If your Web site uses IFrames and End-User Monitoring is not working on those pages, you will need to switch to the newer JavaScript version with IFrame support. In the <apache root>/conf/eum.conf file, follow the directions for enabling IFrame support.
Be sure there is enough activity on your site. If no user is visiting and using your Web application, there may be no end-user performance data to collect or to upload to the Management Repository.
Be sure you have waited long enough for the Management Agent on the Web server host to upload data to the repository. Check the Management Agent home page to determine the last time the Management Agent successfully uploaded data to the Management Repository.
Check the html source of the URLs that you wanted to monitor: make sure the tag <SCRIPT SRC="/oracle_smp_chronos/oracle_smp_chronos.js"></SCRIPT> has been appended to the HTML source of these URLs.
If it is present, proceed to the next step.
If it is not present, check the configuration of your OracleAS Web Cache, Oracle HTTP Server, or Apache HTTP Server. Make sure that all configurations are correct, the site has been enabled, and the Web server has been successfully restarted after saving any configuration changes.
Go to the OracleAS Web Cache or Apache server target home page, click Monitoring Configuration, and check if the log file in the defined Log file directory contains any recent data.
If it does not have data, go to the next step.
If the log file does contain data and the Web server is OracleAS Web Cache, login to Oracle Application Server Control or Web Cache Manager and make sure that the access log is in WCLF or End-User Performance Monitoring format.
Verify that the OracleAS Web Cache / Apache server Monitoring Configuration properties that specify the location and name of the log file are accurate.
Check the Web Server target Home page for any collection errors. Often, the collection error will provide information describing why performance data cannot be collected.
Navigate to the All Metrics page for the Web server target and check to be sure the APM Mining Performance Details metrics are being collected successfully.
For enabling End-User Performance Monitoring for third-party application servers like IBM WebSphere Application Server, BEA WebLogic Managed Server, and JBoss Application Server, after you configure one of the Web servers as explained in this chapter, you have to enable the Application Server Diagnostics Pack for the Web applications hosted on these servers.
To do so, perform the following steps:
Click Setup on the top-right corner of the Grid Control console and navigate to the Overview of Setup page.
Click Management Pack Access from the panel to the left.
On the Management Pack Access page, select the All Targets option in the View Options section of this page.
Select Web Application from the Search menu, and click Go. The table lists all the Web applications monitored.
For the Web application for which you want to enable End-User Performance Monitoring, check Application Server Diagnostics Pack and Pack Access Agreed, and then click Apply.
Now return to the Web Application Home Page and click Page Performance to see the end-user performance monitoring data that has been collected.
Note:
End-User Performance Monitoring for a Web application is not supported if the J2EE container hosting that application is SSL enabled. This applies to Oracle J2EE containers, that is OC4J, and any non-Oracle J2EE containers for third-party application servers like BEA WebLogic Managed Server, IBM WebSphere Application Server, or JBoss Application Server. To activate End-User Performance Monitoring for such a Web application, disable SSL for that J2EE container.For information about configuring SSL for Oracle Application Servers, refer to the Security Guide for your Oracle Application Server release. Documentation for all the Oracle Application releases is available from the Oracle Technology Network: http://www.oracle.com/technology/documentation/index.html.
For information about configuring SSL for third-party servers, refer to your third-party documentation.
A Forms Application target in Enterprise Manager can be used to model and monitor a specific Forms application. To use a Forms Application target, you must ensure that the following prerequisites are met:
Install the Management Agent on the hosts on which the components of your Forms Application have been installed.
Verify that all the components for your Forms Application has been discovered so that they can be listed as Enterprise Manager targets.
Create a system that contains all the components that are required for the Forms Application that is to be monitored. The system can contain an Oracle HTTP Server, Apache HTTP Server or an OracleAS Web Cache. For more details on creating a system, refer to Setting up the System.
After you have created a system for the Forms Application, you can create a Forms Application target using the Create Service Wizard. See Creating a Service for details. Before you create a service, you must be familiar with the concepts of service management as described in the Oracle Enterprise Manager Concepts.
After you have set up the Forms Application target, you can use it to do the following:
Record and monitor a Forms transaction. See Recording and Monitoring Forms Transactions for details.
Measure the End-User Performance of Forms actions such as Commit, Query, Runform, Callform, Openform, and Newform. See Monitoring the End-User Performance of Forms Applications for details.
A Forms transaction consists of a set of user actions within a single application when using Forms. For example, an Update Employee Salary transaction may consist of several user actions like open salary form, update salary form, and save salary form. You can record multiple Forms transactions by using the intuitive playback recorder that automatically records a series of Forms actions.
Before recording a Forms transaction, you must do the following:
Set the permissions of the .java.policy file on each Windows client. See Setting the Permissions of the .java.policy File.
Ensure that a trusted Enterprise Manager certificate is used. See Using a Trusted Enterprise Manager Certificate.
Add a certificate to the Enterprise Manager Agent to play back secure Forms transactions. See Adding a Forms Certificate to the Enterprise Manager Agent .
Configure the Forms server so that Forms transactions can be recorded. See Configuring the Forms Server .
After you have performed these steps, you can install the transaction recorder to record and play back the Forms transaction. See Installing the Transaction Recorder to Record and Play Back Forms Transactions.
You must the set the permissions of the .java.policy file on each Windows client on which the Forms transaction is being recorded. To set the permissions, follow these steps:
Ensure that the .java.policy file is present under the user home directory. If the .java.policy file does not exist, you must create one as follows:
Create a java.policy (without the ".") file
Click Start and Run from your Windows desktop.
Type cmd and click OK.
At the DOS prompt, rename the file as follows:
move java.policy .java.policy
After you have created the .java.policy file, set the permissions for each Forms server or Oracle Applications server as follows:
grant codeBase "URL" {
permission java.security.SecurityPermission "putProviderProperty.SunJSSE";
};
where URL needs to be replaced with the code source location of the Forms applet. By specifying the codeBase, you grant permissions to the code present in that location. For example, for an out-of-box Forms installation, you must specify the codeBase as follows:
http://formsServerHost:port/forms/java/*
where formsServerHost and port must be replaced with the host name and port number of the Forms server.
For Oracle Applications, you must specify the codeBase as follows:
http://appsHost:appsPort/OA_JAVA/oracle/apps/fnd/jar/*
where appsHost and appsPort must be replaced with the host name and port number of the Oracle Applications.
If you are using secure Enterprise Manager to record a Forms transaction running on Oracle Jinitiator or a Java plug-in, you must ensure that the Enterprise Manager certificate is trusted by Oracle Jinitiator and JPI. For Oracle Jinitiator, you must append the Enterprise Manager certificate to Jinitiator's certdb.txt file. For the Java Plug-in, you must set the certificate as trusted by JPI.
To ensure that the Enterprise Manager certificate is trusted by Jinitiator and JPI, follow these steps:
Export the Enterprise Manager certificate to a file.
When you launch secure Enterprise Manager, if Enterprise Manager is using a self generated certificate, you may see a "Certificate Error". Double click on the error and click View Certificates. The Certificate window is displayed.
Click the Details tab and then click Copy to file... to export the certificate to a file. The Certificate Export Wizard is displayed.
Click Next in the Welcome page.
In the Export File Format page, select Base-64 encoded X.509(.CER) and click Next.
Click Browse to select the name and the location of the file to which the certificate is to be saved.
Click Finish. The certificate has now been exported to a file.
After the certificate has been exported, you must set the certificate as trusted by Jinitiator or JPI.
For Forms applications running on Oracle Jinitiator:
Open certdb.txt under [Jinitiator InstallRoot]\lib\security\ directory. Usually Jinitiator is installed under C:\ProgramFiles\Oracle\Jinitiator [version]).
Use a text editor to open the file to which the certificate has been exported. Copy the contents and append it to certdb.txt.
For Forms applications running on Java plug-in:
In the Control Panel, double click the Java program that is used to run the Forms application.
Click the Security tab and then click Certificates.
From the Certificate Type drop down list, select Secure Site.
Click Import to import the file to the location in which the Enterprise Manager certificate has been saved.
Close the certificate windows and the Java Control Panel.
Close the browser window. When the Forms application is accessed again, Jinitiator or JPI is restarted. This ensures that the changes to the security settings have been saved.
To play back a secure Forms transaction, you must add a Forms certificate to the Enterprise Manager Agent by following these steps:
Stop the Management Agent by entering the emctl stop agent command.
Create an importable certificate file from the forms server certificate (Base64 encoded X.509 format) and name this file as forms.cer.
Copy the forms.cer to %AGENT_HOME%/jdk/jre/lib/security/ directory.
Run keytool with the following parameters (the keytool executable can be found under the jdk/jre/bin directory)
keytool -import -alias forms -file %AGENT_HOME%/jdk/jre/lib/security/forms.cer -keystore AGENT_HOME%/jdk/jre/lib/security/cacerts
You will be prompted for the cacerts password. Enter changeit as the password.
Start the Management Agent by entering the emctl start agent command.
For Forms6i, you need to follow these steps:
Stop the Management Agent by entering the emctl stop agent command.
Obtain forms server certificate in Base64 encoded X.509 format and append to $AGENT_HOME/sysman/config/b64InternetCertificate.txt file.
Start the agent by entering the emctl start agent command.
Before recording a Forms transaction, you must configure the Forms server by following these steps:
Create a system based Forms Application target that contains Forms, OracleAS Web Cache or Oracle HTTP Server / Apache HTTP Server targets. These targets must be a part of the system of the Forms Application. They must also be key components of your Forms Application or part of a key Redundancy Group. If you are using the Oracle HTTP Server, the Redundancy Group is referred to as the HTTP Server HA Group.
Set up the Forms server for recording transactions:
Navigate to the Forms Application Home page in the Grid Control console and click Monitoring Configuration.
Click Enable Forms Transaction Monitoring.
The Enable Forms Transaction Monitoring page is displayed.
Select a Forms server from the list and click Configure.
The Configure Forms Server: Login page is displayed.
Enter the login credentials of the host on which Forms server is installed and click Continue.
The jar files required for Forms Transaction Monitoring (formsRecorder.jar, jsse.jar, jnet.jar, and jcert.jar) are copied into the Forms applet's archive directory (ORACLE_HOME/forms/java) and a confirmation message is displayed.
For Oracle Applications, the archive directory is located at $JAVA_TOP/oracle/apps/fnd/jar.
Click Yes to configure the Forms server and return to the Enable Forms Transaction Monitoring page.
After you have configured the system-based Forms Application target, you can record and play back Forms transactions to monitor the availability of the Forms application. To do so, navigate to the Monitoring Configuration page and click Availability Definition. In this page, change the Availability Definition to Service Test.
After you have configured the Forms server, you can install the transaction recorder on your computer. The transaction recorder is downloaded from the Enterprise Manager Grid Control server the first time you access the Record Forms Transaction page. The transaction recorder requires some Microsoft libraries to be installed in your computer. Make sure that your computer has access to the Internet to download these files. If these libraries are not present during installation, they are automatically downloaded and installed from the Microsoft site. After you have recorded a Forms transaction, if you need to record another one in the same browser, you must use the same JVM version for the new transaction.
You can record multiple Forms transactions on the Forms Application target and monitor these transactions periodically. Before recording a Forms transaction, ensure that all other Forms applications are closed. When you a record a Forms transaction, make sure that the following parameters are specified correctly:
Login URL: If you selected the Login Type as Single Sign-On (SSO) or Oracle Applications Login, the Login URL must be explicitly specified.
Connection Type: This can be:
Socket: Ensure that the Forms server host name and port number are specified correctly.
HTTP / HTTPS: If the Connection Type is HTTPS and a non-standard certificate is being used, you must import the certificate into the Agent Home directory.
Forms Path: This is an optional parameter and points to the absolute path of the forms files (.fmx) on the Forms server. To find the absolute path, launch the Forms Application and view the source HTML file of the Forms launcher window. The path is stored in a variable called xmodule. Example: The path may be stored as /myvol/oracle01/apps/apps_st/appl/fnd/12.0.0/forms/US/.
Note:
This parameter is required only if the Forms transaction has been recorded on one Forms server and played back against a different Forms server with a different installation path.For more details on recording a Forms transaction and metrics collected, refer to the Enterprise Manager Online Help.
The End-User Performance Monitoring utility allows you to measure the response time of your applications by viewing information about how quickly the responses are delivered to the end users. When you access a Forms application, the End-User Performance Monitoring utility measures the response time of Forms actions such as Commit, Query, Runform, Callform, Newform, and Openform.You can monitor the Forms actions and view reports based on the response times experienced by the user. You can also define a Watch List of the most important Forms actions to monitor and view the response metrics of these critical operations at a glance.
Note:
End-User Performance Monitoring is supported with Forms server version 6i Patch 16, 10g R2. For version 6i Patch 16, only the Commit operation can be monitored.Before you can begin monitoring the End-User Performance of a Forms Application, you must configure the Forms and Web server to enable data collection for End-User Performance Monitoring. To configure the Forms Application for End-User Performance Monitoring, follow these steps:
Configure the Forms server to enable End-User Performance Monitoring.
Configure the Web server (OracleAS Web Cache or Oracle HTTP Server / Apache HTTP Server) so that it can be used for End-User Performance Monitoring.
Enable the collection of end-user performance data.
Before you can enable the collection of end-user performance data, you must first configure the Forms server. To configure the Forms server, follow these steps:
Navigate to the Forms Application Home page in Enterprise Manager Grid Control.
Click Monitoring Configuration.
Click Manage Web Server Data Collection.
On the Manage Web Server Data Collection page, select the Forms server and click Configure. The Configure Forms Server for End-User Performance Monitoring: Login page is displayed.
Enter the host login credentials and click Continue. The Configure Forms for End-User Performance Monitoring: Configuration Sections page is displayed.
Select a section and check the Enable Monitoring checkbox to enable End-User Performance Monitoring on that section. Click Enable All or Disable All to enable or disable all the sections. You can also click Add New Section to add a section without affecting existing sections. After adding the section, you can enable End-User Performance Monitoring by selecting the checkbox. You can also delete a section that you have added.
Tip:
A section is a parameter defined in theformsweb.cfg. It specifies which section of Forms configuration the user wants to run. The section usually includes the application name and other relevant parameters which are required for successful execution of the application.Set the value of the End-User Performance Monitoring URL column to http://<hostname:portnumber>/oracle_smp_chronos/oracle_smp_chronos_sdk.gif. The hostname and port number are for the Web Server that is serving the Forms application.
After you have configured the Forms server, click OK to save the changes and return to the Manage Web Server Data Collection page.
You can use the 10.1.2 or 9.0.4 versions of OracleAS Web Cache to collect end-user performance data.
OracleAS Web Cache 10.1.2: To configure OracleAS Web Cache 10.1.2, follow these instructions:
You can configure OracleAS Web Cache by using the Oracle Application Server Control. Navigate to the Forms Application home page in the Enterprise Manager Grid Control.
Click Monitoring Configuration.
Click Manage Web Server Data Collection.
On the Manage Web Server Data Collection page, select the Web Cache target and click Configure. The Application Server Control login dialog box is displayed.
Tip:
If the login dialog box does not appear or if you receive an error message in your browser window, navigate to the Web Cache Home page and click Administer under the Related Links. You will be prompted for the user name and password for Application Server Control. Click Administration, scroll down and click End-User Performance Monitoring.If Application Server Control is not available, you can also use the Oracle Application Server Web Cache Manager to configure the OracleAS Web Cache for End-User Performance Monitoring. For more information about starting and using Oracle Application Server Web Cache Manager, refer to the Oracle Application Server Web Cache Administrator's Guide.
Enter the username and password for the Web Cache administrator account or the ias_admin account. The password for the ias_admin account is defined during the installation of Oracle Application Server.
After you have logged into Oracle Application Server Control, you can configure OracleAS Web Cache from the Set Up End-User Performance Monitoring page.
Select the Access Log Format as access log:WCLF for each site from the drop down list. If this format is not in the list, click Use Required Log Format.
You will return to the Web Cache Administration page in Oracle Application Server Control. Click Restart to restart the Web Cache. For more detailed information about configuring these options, refer to the Enterprise Manager Online Help.
Close the Oracle Application Server Control browser window and return to the Manage Web Server Data Collection page in the Enterprise Manager Grid Control.
OracleAS Web Cache 9.0.4: To configure OracleAS Web Cache 9.0.4, follow these instructions:
You can configure OracleAS Web Cache by using the Oracle Application Server Web Cache Manager. Navigate to the Forms Application home page in the Enterprise Manager Grid Control.
Click Monitoring Configuration.
Click Manage Web Server Data Collection.
On the Manage Web Server Data Collection page, select the Web Cache target and click Configure. A login dialog box is displayed.
Tip:
If the login dialog box does not appear or if you receive an error message in your browser window, navigate to the Web Cache Home page and click Administer under the Related Links. You will be prompted for the user name and password for Application Server Control. Click Administration, scroll down and click End-User Performance Monitoring.Enter the username and password for the Web Cache administrator account. The first time you log in to the Oracle Application Server Web Cache administrator account, the password is administrator.
Configure Oracle Application Server Web Cache to use the Web Cache Log Format (WCLF):
Select Logging and Diagnostics and then select Access Logs in the OracleASWeb Cache Manager navigator frame.
In the Cache-Specific Access Log Configuration table, click Edit Selected and enable the access log for your selected cache.
In the Site-Specific Access Log Configuration table, make sure that the Format style of the selected Site Name is WCLF and that it is enabled.
For more details on changing the access_log format, refer to the Enterprise Manager Online Help.
Click Apply Changes at the top of the Oracle Application Server Web Cache Manager window and restart Oracle Application Server Web Cache by clicking Restart on the Oracle Application Server Web Cache Manager Cache Operations page.
Close the Oracle Application Server Web Cache Manager window and return to the Manage Web Server Data Collection page in the Grid Control console. You can now enable the collection of end-user performance data.
You can collect end-user performance data by using Oracle HTTP Server or Apache HTTP Server. Before you use these server, follow these steps:
On the Agent Home page, select the Oracle HTTP Server or Apache HTTP Server target type. If you are using a generic third party Apache server, select a Apache HTTP Server target.
Add the target of the corresponding type and make sure that the Log file directory and Log file name properties are set in the Monitoring Configuration page.
The Log file directory and Log file name you specify here will be used by the End-User Performance Mining Engine to upload end-user performance data.
Note:
If the Oracle HTTP Server is installed before the Management Agent has been installed, and is up and running during agent installation, then the target will be discovered automatically. Otherwise you need to manually create the Oracle HTTP Server target and specify the following properties:Machine name, Port number, Version of the Apache Server, Oracle home path, Log file directory (for EUM), Log file name (for EUM) where EUM refers to End-UserPerformance Monitoring. Create a system target and a Forms Application target. Add the Oracle HTTP Server or Apache HTTP Server target to the system target, and make it a key component of the Forms Application target or a part of a key Redundancy Group target. If you are using Oracle HTTP Server, the Redundancy Group is referred to as HTTP Server HA Group.
Navigate to the Monitoring Configuration page for the Forms Application target that contains the Oracle HTTP Server or Apache HTTP Server target. Click Manage Web Server Data Collection. You will see a table which lists the Web Servers including Oracle HTTP Server, Apache HTTP Server, or OracleAS Web Cache.
Select the Oracle HTTP Server or Apache HTTP Server from the table and click Configure. Enter the username and password for the host on which the Oracle HTTP Server or Apache HTTP server is installed.
After logging in, you will see a table containing the list of sites that are being hosted by the Apache server. These include a list of virtual hosts defined by the user in the Apache Configuration file. The up and the down arrows under the Monitoring Status column shows the corresponding site is currently being monitored. For each site, check or uncheck the Enable Monitoring checkbox to indicate whether this site is to be monitored. For the site that is to be monitored, enter the log file name in the text box to indicate the location in which the end-user performance data is to be stored. By default, the log file will be created under the logs/directory under Apache root directory. To save the log file in a different directory, enter a file name with the absolute path.
Make sure that the log file name you specify here matches the Log file directory and Log file name in Monitoring Configuration page of the Oracle HTTP Server or Apache HTTP Server target.
You can also use the one button accelerator to enable all sites or disable all sites all at once.
After you have made the configuration changes, click OK to go to the Apache Restart page. Restarting the Apache server will finalize all configuration changes, and end-user performance data will be logged by the Apache server.
After you have configured the Web server, you must configure the Forms server and enable collection of the End-User Performance data from the Manage Web Server Data Collection Page. For details on configuring the Forms server, refer to the Enterprise Manager Online Help.
After you have configured the Forms and Web server to enable collection, you can then start collecting end-user performance data.
Navigate to the Web Application home page in the Grid Control console and click Monitoring Configuration.
Click Manage Web Server Data Collection. Enterprise Manager displays the Manage Web Server Data Collection page.
In the Interval (minutes) column, enter the interval at which Enterprise Manager will collect performance data.
Check the Collection Enabled checkbox.
Click Apply, review the changes and confirm by clicking Apply again. End-User Performance Monitoring collection is enabled and data will soon be uploaded to the database and shown under the Page Performance page.
To stop collecting end-user performance data:
Navigate to the Manage Web Server Data Collection page.
Clear the check box in the Collection Enabled column of the table and click Apply.
Click Apply again to confirm the changes.
Enterprise Manager can gather critical request performance data about your Web application and display this performance data. This feature can be instrumental when you are diagnosing application server and back-end performance issues.
Before you can begin collecting request performance data, you must do the following:
Create a Web application target and associate it with a system that contains the OC4J instances to be monitored.
Make these OC4J instances as key system components for your Web application and enable the logging and tracing capabilities. If these OC4J instances are a part of an OC4J Cluster, make sure that this OC4J Cluster is a key system component of your Web application. To enable request performance monitoring, you must configure the specific OC4J instance within the OC4J cluster.
For more information, see the following:
Before you configure the OC4J target to collect request performance data, follow the steps given below to add the target to the Web application.
Configure the system where the OC4J targets are defined for the Web application target.
Navigate to the Web application Home page and click Monitoring Configuration.
Click System Configuration. From the list of system components displayed on this page, select one or more OC4J targets and select the checkbox in the Key Components column. The OC4J targets can now be configured and used to collect request performance data.
When you use transactions to monitor your Web application, some of the transactions you create often involve application components such as servlets, Java Server Pages (JSPs), Enterprise Java Beans (EJBs), and database connections. Often, the best way to solve a performance problem is to trace these more complex transactions and analyze the time spent processing each application component.
Enterprise Manager provides a mechanism for tracing these transactions. Use the Service Tests and Beacons link on the Monitoring Configuration page of the Web application target to create your transactions and to trace the transactions as they are processed by the servlets, JSPs, EJBs, or database connections of your application.
However, before you can take advantage of transaction tracing, you must first enable tracing for the OC4J instance used to deploy the application. Each OC4J instance of an OC4J cluster must be configured independently. The OC4J instances of the OC4J clusters selected as key components of the Web application target are displayed on the Manage Web Server Data Collection page.
To enable tracing for an OC4J instance:
Navigate to the Web Application Home page and click Monitoring Configuration.
Click Manage OC4J Data Collection.
Enterprise Manager displays the Manage OC4J Data Collection page.
Select the OC4J to configure and click Enable Logging.
Enterprise Manager opens another browser window and displays the Tracing Properties page for the OC4J instance in the Application Server Control.
If you are prompted to log in to the Application Server Control Console, enter the credentials for the ias_admin administrator's account.
Select the following options on the Tracing Properties page:
Enable JDBC/SQL Performance Details
Enable Interactive Trace
You can use the default values for most of the tracing properties.
Note:
Turning on the Enable JDBC/SQL Performance Details option allows to you drilldown to actual SQL statements but this may require more resources.Click Apply.
If this is the first time you are enabling OC4J tracing for this application server, Enterprise Manager displays a message stating that the transtrace application is being deployed. The Application Server Control then prompts you to restart the OC4J instance.
Click Yes to restart the instance and enable the tracing properties.
Return to the Grid Control console.
Tracing is now enabled for the selected OC4J instance.
You must configure OC4J instances to enable tracing so that request performance data can be collected. Each OC4J instance of an OC4J cluster must be configured independently. The OC4J instances of the OC4J clusters selected as key components of the Web application target are displayed on the Manage Web Server Data Collection page. To configure the OC4 instances, follow these steps:
Navigate to the Web Application home page and click Monitoring Configuration.
Click Manage OC4J Data Collection.
Enterprise Manager displays the Manage OC4J Data Collection page.
For the OC4J instance that you used to deploy your application, select the check box in the Collection Enabled column.
In the Interval (minutes) column, enter the interval at which to collect OC4J tracing data.
The recommended interval setting is 60 minutes.
Select the OC4Js to configure and click Enable Logging.
Enterprise Manager opens another browser window and displays the Tracing Properties page for the OC4J instances in the Application Server Control.
If you are prompted to log in to the Application Server Control Console, enter the credentials for the ias_admin administrator's account.
Select the following options on the Tracing Properties page:
Enable JDBC/SQL Performance Details
Enable Historical Trace
You can use the default values for most of the tracing properties. However, Oracle recommends that you set the Frequency to Generate Trace File (seconds) field to 3600 seconds (equivalent to 60 minutes).
Note:
Modifying the value in the Trace File Directory field is not supported.Click Apply.
If this is the first time you are enabling OC4J tracing for this application server, Enterprise Manager displays a message stating that the transtrace application is being deployed. The Application Server Control then prompts you to restart the OC4J instance.
Click Yes to restart the instance and enable the tracing properties.
Return to the Grid Control console.
Request Performance data should begin to appear on the Request Performance page as soon as data for the OC4J instance is collected and uploaded into the Management Repository.
If you used Oracle User Interface XML (UIX) to build your application, there is an additional configuration step you must perform before you can monitor the requests of your application.
Before you can monitor the requests of your UIX application, you must do the following:
Enable tracing for the OC4J instance you used to deploy your application, as described in "Configuring OC4J Tracing for Request Performance Data".
Locate the following configuration file in the Application Server home directory where you deployed your UIX application:
$ORACLE_HOME/j2ee/OC4J_instance_name/config/oc4j.properties
For example, if you deployed your application in the OC4J instance called "home," locate the following configuration file:
$ORACLE_HOME/j2ee/home/config/oc4j.properties
Open the oc4j.properties file using your favorite text editor and add the following line to the end of the file:
oracle.dms.transtrace.dollarstrippingenabled=true
Save your changes and close the oc4j.properties file.
Restart the OC4J instance.
A monitoring template for a service contains definitions of one or more service tests, as well as a list of monitoring beacons. A monitoring template can be used to create service tests on any number of service targets, and specify a list of monitoring beacons.
A monitoring template must be created from a service target. Once the template is created, the user can edit the template, create copies, or delete it. Finally, the user can apply the template to other targets, which creates the service tests on the other targets and adds the monitoring beacons.
To create a Monitoring Template, follow the steps given below:
Click Setup to navigate to the main Setup page in Enterprise Manager.
Click the Monitoring Templates link in the left panel.
Click Create to create a monitoring template.
In the target selection box, enter or select a service target and click Continue.
In the Monitoring Template General Page, enter the name of the template that you wish to create.
Click Tests to add / remove or configure service tests associated with the selected service target. Make the required changes to this page and click OK to save the template to the repository.
After you have created the Monitoring Template, use the Apply option to apply this template to a service test. You can click Edit to modify the template. For more details on these operations, refer to the Online Help.
You can configure the service tests and beacons associated with the template by using the options in the Tests page. A service test-based template contains the following elements:
Variables: A variable may occur at multiple locations in the service tests. The Variables table allows you to specify default values for all the variables. These default values will be stored in the template along with the variables. You can specify values other than the default while applying the template to a target. You can perform the following operations:
Add a variable. The variable can consist of letters, numbers and underscores only.
Rename a variable. When you rename a variable, all variable references in the service tests will be replaced with the new name.
Remove variables for properties within service tests. If you remove a non-password variable, all references to the variable in test properties will be replaced with the variable's default value
Replace Text in test properties with a variable definition.
Service Tests: You can edit the test definition and define variables for various properties. You can select the tests from the original target that are to be part of the template by clicking the Add / Remove button. You can specify whether the service test is a key test and if it should be enabled. You can also click Monitoring Settings to drill down to this page and define metrics and thresholds for the service tests.
Beacons: Use the Add / Remove button to specify which beacons are to be included in the template. You can also specify whether each beacon is a key beacon.
Refer to the Enterprise Manager Online Help for detailed instructions on these operations.
A service level rule is defined as an assessment criteria used to determine service quality. It allows you to specify availability and performance criteria that your service must meet during business hours as defined in your Service Level Agreement. For example, e-mail service must be 99.99% available between 8am and 8pm, Monday through Friday.
A service level rule specifies the percentage of time a service meets the performance and availability criteria as defined in the Service Level Rule. By default, a service is expected to meet the specified criteria 85% of the time during defined business hours. You may raise or lower this percentage level according to service expectations. A service level rule is based on the following:
Business Hours: Time range during which the service level should be calculated as specified in your Service Level Agreement.
Availability: Allows you to specify when the service should be considered available. This will only affect the service level calculations and not the actual availability state displayed in the console. You can choose a service to be considered up when it is one or more of the following states:
Up: By default the service is considered to be Up or available.
Under Blackout: This option allows you to specify service blackout time (planned activity that renders the service as technically unavailable) as available service time.
Unknown: This option allows you to specify time that a service is unmonitored because the Management Agent is unavailable be counted as available service time.
Performance Criteria: You can optionally designate poor performance of a service as a Service Level violation. For example, if your Website is up, but it takes 10 seconds to load a single page, your service may be considered unavailable.
Business Criteria: Business criteria are useful in determining in the health of the business processes for a particular service. You can optionally define business metrics that can affect the Service Level. A Service Level violation occurs when a critical alert is generated for a specified business metric.
Note:
The Business Criteria column is displayed only if one or more key business indicators are associated with the service. Refer to Oracle Enterprise Manager Integration Guide.Actual Service Level: This is calculated as percentage of time during business hours that your service meets the specified availability, performance, and business criteria.
Expected Service Level: Denotes a minimum acceptable service level that your service must meet over any relevant evaluation period.
You can define only one service level rule for each service. The service level rule will be used to evaluate the Actual Service Level over a time period and compare it against the Expected Service Level.
When you create a service, the default service rule is applied to the service. However, you must edit the service level rule for each service to accurately define the assessment criteria that is appropriate for your service. To define a service level rule:
Click the Targets tab and Services subtab. The Services main page is displayed.
Click the service name link to go to the Service Home page.
In the Related Links section, click Edit Service Level Rule.
On the Edit Service Level Rule page, specify the expected service level and the actual service level and click OK. The expected service level specifies the percentage of time a service meets the performance, usage, availability, and business criteria defined in the Service Level Rule. The actual service level defines the baseline criteria used to define service quality and includes business hours, availability, performance criteria, usage criteria, and business criteria.
Note:
Any Super Administrator, owner of the service, or Enterprise Manager administrator with OPERATOR_TARGET target privileges can define or update the Service Level Rule.You can view service level information directly from the either of the following:
Enterprise Manager Grid Control Console -From any Service Home page, you can click on the Actual Service Level to drill down to the Service Level Details page. This page displays what Actual Service Level is achieved by the service over the last 24 hours/ 7 days / 31 days, compared to the Expected Service Level. In addition, details on service violation and time of each violation are presented in both graphical and textual formats.
Information Publisher - Information Publisher provides an out-of-box report definition called the Services Dashboard that provides a comprehensive view of any service. From the Report Definition page, click on the Services Monitoring Dashboard report definition to generate a comprehensive view of an existing service. By default, the availability, performance, status, usage, business, and Service Level of the service are displayed. The Information Publisher also provides service-specific report elements that allow you to create your own custom report definitions. The following report elements are available:
Service Level Details: Displays Actual Service Level achieved over a time-period and violations that affected it.
Service Level Summary: Displays service level violations that occurred over selected time-period for a set of services.
Services Monitoring Dashboard: Displays status, performance, usage, business, and service level information for a set of services.
Services Status Summary: Information on one or more services' current status, performance, usage, business, and component statuses.
Refer to the Online Help for more details on the report elements.
Using the Command Line Interface, you can define service targets, templates and set up alerts. EM CLI is intended for use by enterprise or system administrators writing scripts (shell/batch file, perl, tcl, php, etc.) that provide workflow in the customer's business process. EM CLI can also be used by administrators interactively, and directly from an operating system console. Refer to Enterprise Manager Command Line Interface Guide for details.
This section lists some of the common errors you may encounter while using the Forms and the Web Transaction test type. The following topics are covered here:
The section covers the following:
This section lists some of the common errors you may encounter while playing back a Forms transaction and provides suggestions to resolve these errors.
Error Message: Connection to Forms Server is lost. Possible version mismatch between agentjars and formsjars.
Possible Cause: The transaction was recorded using an out-of-the-box Forms version.
Solution: Verify the version of the Forms Application that you are running by checking the version number in the About Oracle Forms Online Help. If this version is not supported, follow the steps listed under Error Message 2.
Error Message: Version Not Supported <forms_version>
Possible Cause: The machine on which the beacon has been installed does not contain the necessary forms jar files.
Solution: To resolve this error, follow these steps:
Login to the system on which the Forms server has been installed. Locate the frmall.jar (if you are using Forms 10.1 or later) or f90all.jar (if are using Forms 9.0.4 or later) under the $FORMS_HOME/forms/java directory.
Login to the system on which the beacon has been deployed and copy the jar file to the $ORACLE_HOME/jlib/forms/<version>/ directory. The version you specify here should be the same as the version string in the error message. Make sure that the directory is empty before you copy over the jar file.
If you are using Oracle Applications R12 and you encounter this error, follow these steps to resolve the error:
Login to the system in which the Oracle Application server has been deployed. Locate the following files:
$JAVA_TOP/oracle/apps/fnd/jar/fndforms.jar $JAVA_TOP/oracle/apps/fnd/jar/fndewt.jar
Login to the system on which the beacon has been deployed and copy these files to the $ORACLE_HOME/jlib/forms/apps/ directory. Make sure that the directory is empty before you copy over the jar files.
Note:
You cannot monitor two deployments of Oracle Applications from the same beacon if different versions of Oracle Applications have been used.Error Message: Forms URL is not pointing to the forms servlet.
Possible Cause: When the Forms transaction was recorded, the location of the forms servlet could not be determined.
Solution: Make sure that the Forms URL Parameter is pointing to the forms servlet. It should be http://<hostname>:<port>/forms/frmservlet for Forms10g or http://<hostname>:<port>/forms/f90servlet for Forms 9i. This parameter is automatically set by the Forms Transaction Recorder. But if it has not been set, you can locate the URL by following these steps:
Launch the Forms application.
View the source HTML file in the Forms launcher window.
Locate the xsurl variable. The URL is stored in this variable.
Error Message: Could not connect to <machine name>.
Possible Cause: The machine on which the beacon has been installed cannot access the Forms Application.
Solution: Make sure the machine on which the beacon has been installed can access the Forms Application and firewalls have been properly configured. Support for playing back Forms transactions through proxy server is not available in this release.
Error Message: Invalid module path in the initial message.
Possible Cause: The transaction may have been incorrectly recorded or may be corrupt.
Solution: Try to record the transaction again.
Error Message: Cannot connect to login server.
Possible Cause: This error may occur due the following reasons:
The Login URL that you have specified may be incorrect.
An invalid HTTPS certificate may have been provided for the login server.
Solution:
Verify that the Login URL is correct.
If you are using HTTPS to connect to login server, make sure the certificate on the server is written for the login server machine itself. Make sure the SSL Certificate is imported into Agent and the CN of the certificate matches the host name of the login Server URL.
This section lists some troubleshooting steps that you can use when the Forms transaction cannot be recorded successfully.
Make sure that all your Internet Explorer instances are closed and no java runtime programs are open.
Start recording again with the java console open. You can view any exceptions or error messages displayed on the console.
You should now see the text "Forms Transaction Recorder Version: <version number>" on the console. If this text is displayed, proceed to step 5. If you do not see the text, check if the formsRecorder.jar has been copied to the Forms archive directory. You can perform this check using either of the following methods:
Navigate to the Forms archive directory and check if the formsRecorder.jar file is present in the directory.
Navigate to the Enable Forms Transaction Monitoring page, select the corresponding Forms server target and click Configure. Enter the host credentials to see if the Forms Transaction Recorder has already been configured on this Forms server. If the formsRecorder.jar is not present in the Forms archive directory, follow the steps in the Configuring the Forms Server section to configure your Forms server for transaction monitoring. After ensuring that the formsRecorder.jar is present in the archive directory of the Forms server, go back to Step 1 and try recording again.
If you see an exception related to the java .policy file displayed on the java console, check the file to ensure that it has the required content and is in the right location. If any errors are found, you must fix these errors and try recording again. See Setting the Permissions of the .java.policy File.
If the recording still fails, check if the Enterprise Manager Certificate has been imported to the secure site as described in Using a Trusted Enterprise Manager Certificate. If the certificate has not been imported, you must import it and try recording again. See Using a Trusted Enterprise Manager Certificate.
This section lists troubleshooting steps that you can use when the Forms transaction End-user Performance Monitoring (EUM) data is not being displayed.
Ensure that the Forms server is configured with EUM.
From the Manage Web Server Data Collection page, select the Forms server and click Configure. Log in using the credentials of the host where the Forms server is installed. Ensure that the correct Forms configuration section has been configured with EUM enabled and that the correct EUM URL is specified. Go to the Forms application URL (with the correct configuration section) and perform "Save" or "Query" actions to generate EUM traffic.
Ensure that the Web server is configured to log End-User Performance Monitoring data.
From the Manage Web Server Data Collection page, select the Web server and click Configure.
If you are using a Web Cache to log EUM data, login to the Web Cache Administration page or Web Cache Manager and check if the access_log file is set to either End-User Performance Monitoring or WCLF format. End-User Performance Monitoring data is logged into Web Cache's access_log.
If you are using HTTP Server or Apache HTTP Server, log in using the credentials of the host where the HTTP Server is installed. Then check if EUM has been enabled and note the path of the log file in the configuration page.
Ensure that the EUM log file is being generated.
Go to the location of the End-User Performance Monitoring log file, open the log file and search for word "sdk".
"sdk" entries indicate that there is EUM traffic and that the monitoring configuration is correct. In this situation, more time is required to collect end-user performance data. If the log file exists and "sdk" entries are found, go to step 4.
Check the Monitoring Configuration page of the Web Cache or HTTP Server target to ensure the parameters "Log File Directory (for EUM)" and "Log File Name (for EUM)" match that of the log file path shown on the configuration page.
Another way to verify the existence of end-user performance data, is to note the value of the Number of Unprocessed Samples on the Page Performance page of the Forms application. Samples for an hour that has not ended are referred to as Unprocessed Samples. For example, data is processed for the time period between 10 am to 11 am, 11 am to 12 pm and so on. Therefore, data from 10 am to 11 am will be considered Unprocessed Samples if the 11 am boundary has not been crossed or if there is no incoming end-user traffic after 11 am. If this is a non-zero value, click Process Samples. End-user performance data is displayed in the Slowest Response Times table.
This section lists some of the common errors you may encounter while recording and playing back Web Transactions.
Scenario: Verify Service Test displays: Connection establishment timed out -- http://..../
Possible Cause: The beacon can only access that URL via a proxy server and it has not been configured.
Solution: From the All Targets page, select the beacon, click Configure and set the beacon proxy setting.
Scenario: Verify Service Test displays: Authorization Required -- https://...../
Possible Cause: The Basic Authentication information is not recorded automatically.
Solution: To resolve this error, follow these steps:
From the Service Tests and Beacons page, select the service test, click Edit.
Make sure you enter all the Basic Authentication information: Username, Password, and Realm.
Note:
Realm usually appears above the Username label in the Browser's authorization dialog box.Scenario: Verify Service Test displays sun.security.validator.ValidatorException: No trusted certificate found -- https://....../.
Possible Cause: The beacon does not know about this SSL Certificate.
Possible Solution: From the Service Tests and Beacons page, select the service test, and click Edit. Under Advanced Properties, and set Authenticate SSL Certificates to No.
Scenario: Verify Service Test displays: Timeout of 300000 exceeded for https://....../ Response time = 3000000
Possible Cause: The test may be too complex to complete within the allotted time. Or, this may be an actual performance issue with the server.
Possible Solution: From the Service Tests and Beacons page, select the service test, and click Edit. If this is not a server performance issue, under Advanced Properties, increase the Timeout Value.
Scenario: The Verify Service Test option reports that the service as down, but the Web application is up and you can successfully play back the Web transaction.
Possible Cause: The Web application is only compatible with Internet Explorer or Mozilla-based browsers.
Possible Solution: From the Service Tests and Beacons page, select the service test, and click Edit. Under Advanced Properties, set the User Agent Header as Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) OracleEMAgentURLTiming/3.0.
Note:
For Grid Control 10.2.0.4 and beyond, this User Agent Header is set automatically during Web transaction recording.Scenario: Test Performance Page does not show any step metrics.
Possible Cause: By default, only transaction-level metrics are collected.
Possible Solution: From the Service Tests and Beacons page, select the service test, click Edit, and set Data Granularity to Step.
|
 Copyright © 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|