| Oracle® Enterprise Manager Cloud Control Administrator's Guide 12c Release 1 (12.1.0.1) Part Number E24473-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Enterprise Manager Cloud Control Administrator's Guide 12c Release 1 (12.1.0.1) Part Number E24473-01 |
|
|
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 21-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 You must also perform the following tasks:
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:
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 21-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 21-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 21-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 21-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 Cloud 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 ATS, 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. 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.
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:
The Forms Transaction test type has been deprecated in Enterprise Manager 12c. Forms transactions created in earlier releases can still be used but you cannot create new Forms Transaction test types. You must create a Generic Service target and create an ATS Transaction using OATS EBS/Forms Load test scripts. This ATS test type is used to monitor Oracle Forms applications.
The Web Transaction test type is in maintenance mode only. To monitor Web applications, we recommend that you create an ATS load script and use the ATS Transaction test type to monitor Web applications.
For more details on creating different types of service tests, refer to the Enterprise Manager Online Help.
You can use the Oracle Application Test Suite (OATS) to define an Openscript Transaction Service Test. This test is used to enable beacon application transaction monitoring using Openscript load testing scripts. Openscript is a component of OATS and provides advanced capabilities to record and play back various types of Web transactions, such as web/HTTP, Oracle EBS/Forms, Oracle Fusion/ADF, Siebel, Adobe Flex etc. For details on how to create ATS load testing scripts, please refer to Oracle® Functional Testing OpenScript User's Guide. For details on creating an ATS test type, 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 Cloud 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. Incidents 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. Incidents 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 incidents, 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 incidents, 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 incidents, 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.
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 Cloud 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 incidents. 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 Web Transaction test type. Some of the common errors you may encounter while recording and playing back Web transactions are listed below:
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 © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|