| Oracle® Enterprise Manager Advanced Configuration 10g Release 2 (10.2) Part Number B16242-01 |
|
|
View PDF |
| Oracle® Enterprise Manager Advanced Configuration 10g Release 2 (10.2) Part Number B16242-01 |
|
|
View PDF |
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 6-1 Summary of Service Management Tasks
| Feature | Description | Requirements | Refer to |
|---|---|---|---|
|
This feature allows you to proactively monitor services using service tests or synthetic transactions and determine their performance and availability from different user locations using beacons. For Web transactions, you can monitor the transactions at the transaction, step group and step level. |
|
|
|
|
Enterprise Manager allows you to gather end-user performance data and monitor the performance of the pages within your Web application. The End-User Performance Monitoring feature allows you to:
|
Configuring End-User Performance Monitoring |
||
|
Enterprise Manager provides a mechanism for interactively tracing Web transactions. This feature allows you to: |
Note: Recording a transaction is an optional feature. You can manually create a transaction by entering the required values. |
Configuring Interactive Transaction Tracing |
|
|
Enterprise Manager can gather critical request performance data about your Web application. The Request Performance feature allows you to:
|
Configuring OC4J for Request Performance Diagnostics |
||
|
The Root Cause Analysis (RCA) feature provides you with the ability to analyze and determine possible causes of service failure. The Topology Viewer provides a graphical representation of the service and its relationship to other services, systems and infrastructure components, with the causes identified by RCA highlighted in the display. |
For the Topology Viewer
|
Root Cause Analysis Configuration |
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, and Aggregate Service. 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. 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.
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:
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 6-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 6-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 6-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 Web application. |
|
|
The minimum value of the metric across all components will be used as the value of this usage metric for the Web application. |
|
|
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.
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 proxyHost=www-proxy.us.oracle.com proxyPort=80 dontProxyFor=us.oracle.com,oraclecorp.com The |
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:
For Web transactions, refer to instructions in the "Configuring Beacons to Monitor Web Applications Over HTTPS".
To use the SSL option with the Port Checker test, you may need to add additional certificates to the agent's monitoring wallet. For details on adding certificates, refer to "Adding Trust Points to the Management Agent Configuration".
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
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, and usage for the aggregate service depend on the availability, performance, 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 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 usage metrics to use, you can set the thresholds used 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 and usage 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:
Configuring End-User Performance Monitoring Using Oracle Application Server Web Cache
Setting Up the Forms Application 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.
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 user name 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 thechronos_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:
|
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.
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 name |
Oracle 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 Cache |
Specifically, 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 |
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".
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, go to Step g.
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 Step h.
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.
Enterprise Manager allows you to monitor response time data of end-users accessing an Oracle Forms application. The Forms operations that can be monitored include commit, query, runform, callform, newform, and openform. For each of these operations, the total response time, server time and database time for a particular URL are measured.
You can use either of the following Forms application versions:
Forms 10.1.2 (All Forms operations can be monitored)
Forms 6 Patch 16 (Only the commit operation can be monitored)
End-user performance monitoring for an Oracle Forms application requires an OracleAS Web Cache. OracleAS Web Cache is a component of the Oracle Application Server that runs the Forms application. To enable end-user performance monitoring, the Forms server needs to be configured and the logging format of the Oracle Web Cache needs to be changed to End-User Performance Monitoring format.
To set up the Forms application for End-User Performance Monitoring
Navigate to the Home page in Application Server Control.
Select the Forms system component and click Configuration.
Ensure the Forms Web Configuration (formsweb.cfg) View is selected.
Select the appropriate section to enable End-User Performance Monitoring, or click Create New Section to enable End-User Performance Monitoring for a new section and enter the name of the new section.
Click Edit to add or modify the following parameters in the formsweb.cfg file. If these parameters have not been defined, click Add New Parameters and enter the parameter names and their corresponding values.
Set the endUserMonitoringEnabled parameter to true.
Set the path of the endUserMonitoringURL to http://<hostname:portnumber>/oracle_smp_chronos/oracle_smp_chronos_sdk.gif. The hostname and port number are for the Web Cache that is serving the Forms application.
To change the Logging format in the 10g version:
Navigate to the Web Cache Home page in Application Server Control.
Click Administration.
Click Logging and change the log file format to End-User Performance Monitoring format.
Click OK and restart the Web Cache.
For earlier versions of Web Cache, use the Web Cache Manager page to change the logging format of the Web Cache to the End-User Performance Monitoring format.
|
Note: After you have configured the Forms server and the Web Cache, follow the steps listed in "Configuring End-User Performance Monitoring" to create the Forms Web application. You must then navigate to the Monitoring Configuration page of the Web application and specify FORMS in the Application Type field. |
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.
Actual Service Level: This is calculated as percentage of time during business hours that your service meets both availability and performance criteria specified.
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, business hours, availability and performance criteria and click OK.
|
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, 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 and service level information for a set of services.
Services Status Summary: Information on one or more services' current status, performance, usage 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.
