After you have created a service, you can define the service availability, associate a system with the service, define performance and usage metrics, and so on. This section describes the following:
Availability Definition
Root Cause Analysis Configuration
System Association
Service Tests and Beacons
Test Summary
Monitoring Settings for Tests
Usage Metrics
Performance Metrics
Edit Service Level Rule
The availability of a service indicates whether the service is available to the users at any given point in time. The rules for what constitutes availability may differ from one application to another. For example, for a Customer Relationship Management (CRM) application, availability may mean that a user can successfully log onto the application and access a sales report. For an e-mail application, it may be mean that the user can access the application, send and receive e-mails.
Click on the service for which you want to define the availability and navigate to the Service Home page. From the Generic Service menu, select Administration, then select Availability. The availability of a service can be based on:
Service Tests: Choose this option if the availability of your service is determined by the availability of a critical functionality to your end users. Examples of critical functions include accessing e-mail, generating a sales report, performing online banking transactions, and so on. While defining a service test, choose the protocol that most closely matches the critical functionality of your business process, and beacon locations that match the locations of your user communities.
You can define one or more service tests using standard protocols and designate one or more service tests as Key Tests. These key tests can be executed by one or more Key Beacons in different user communities. 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. Depending on the definition, a service is considered available if all key service tests are successful or at least one key service test is successful. See Deploying and Using Beacons for details on beacons and how to create them.
You can specify whether the service should be available when:
All key service tests are successful (Default). This option is recommended.
At least one key service test is successful
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.
System: The availability of a service can alternatively be based on the underlying system that hosts the service or selected components of the system. If availability is based on selected system components, you must select the components that are critical to running your service and designate one or more components as Key Components, which are used to determine the availability of the service. The service is considered available as long as at least one or all key components are up and running, depending on your availability definition.
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".
Sub Service: For an aggregate service, availability can also be based on the availability of the sub services. You can specify if availability should be determined based on the availability of all sub services or a single sub service.
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 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 gives you a graphical representation of the service, along with the system and component dependencies. Targets that have caused the service failure are highlighted in the Topology page.
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:
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. RCA considers the status of a sub-service (a service that you depend on) as well the system components or service on which the sub-service depends.
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. RCA can be configured to run in two modes. It can run automatically based on the failure of a service or can be configured to run manually. You can decide the mode based on the Expected Service Level Agreement % of the service being monitored. If the Expected Service Level Agreement % is high, you must select the automatic mode to ensure that that possible errors and the root cause of the failure is easily detected.
A system is the set of infrastructure components (hosts, databases, application servers, etc.) that work together to host your applications. For example, an e-mail application can be hosted by a database, listener, application server, and the hosts on which these components reside.
After you create a service, you can specify the associations between the components in the system to logically represent the connections or interactions between them. For example, you can define an association between the database and the listener to indicate the relationship between them. These associations are displayed in the topology viewer for the system. Some data centers have systems dedicated to one application or service. Alternatively, others have systems that host multiple services. You can associate single or multiple services to a System, based on how the data center is set up.
Use this page to select the Enterprise Manager system that will be used to host this service. You can do the following:
Add or select a system
Change or remove a selected system
After you have selected the system, mark one or more system components as key components that are critical for running the service. These key components are used to determine service availability or identify causes of service failure.
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, from the Generic Service menu, select Administration, then select Monitoring Settings for Tests. 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.
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 in the Monitoring Configuration page. The Service Tests and Beacons page appears. You can select a test type from the drop down list and create a service test.
You can create different types of service tests based on the protocol and the location of the beacons. From the Service Tests and Beacons page, 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.
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. The Status icon indicates the status of the service test i.e. whether it can be successfully executed by the key beacons. If there are no key beacons defined for the service, the status will be unknown even if there are other beacons executing the service test. Click Status to go to the Status History page.
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-myproxy.myco.com as proxy, specify the values as follows:
proxyHost=www-myproxy.myco.com
proxyPort=80
dontProxyFor=myco.com,mycorp.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 all the OMSes for the changes to be effective.
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. See Creating an ATS Service Test Using OATS Load Script for details.
The creation of different types of service tests is covered in detail in the Enterprise Manager Online Help. In this chapter, we have covered the creation of the ATS test type as an example.
A beacon is a target that allows the Management Agent to remotely monitor services. A beacon can monitor one or more services at any point in time.
Note:
Before you create a beacon, you must ensure that the Oracle Beacon 12.1.0.2 or higher plug-in has been deployed.
To create a beacon to run one or more service tests, follow these steps:
This section lists additional beacon related configuration tasks.
Configuring SSL Certificates for the Beacon: When a beacon is used to monitor a URL over Secure Sockets Layer (SSL) HTTPS URL, the beacon must be configured to recognize the Certificate Authority that has been used by the Website where that URL resides.
To use the SSL option with the Port Checker test, you may need to add additional certificates to the Management Agent's monitoring wallet. To add an additional certificate, follow these steps:
Obtain the certificate, which is in Base64encoded X.509 (.CER) format, in the b64SiteCertificate.txt file. (The file name may be different in your configuration.) An example of the contents of the file is given below:
------BEGIN CERTIFICATE-------------- MIIDBzCCAnCgAw... ...... base 64 certificate content ..... ------END CERTIFICATE-----------------
This file is stored in the Home directory of the Management Agent as <AGENT_BASE>/agent_inst/sysman/config/b64InternetCertificate.txt file.
Create the b64InternetCertificate.txt file in the agent core and instance directory if it does not exist.
<AGENT_BASE>/agent_inst/sysman/config/b64InternetCertificate.txt <AGENT_BASE>/core/12.1.0.2.0/sysman/config/b64InternetCertificate.txt
Append the Base64encoded X.509 certificate to the end of both b64InternetCertificate.txt files. Include both the BEGIN and END CERTIFICATE lines.
Restart the Management Agent.
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:
applicationmetadataquota: the disk quota in bytes for each application area
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.
The applicationMetadataQuota_BEACON property determines the total size that can be used to store ATS zip files. If you are using a ATS zip file or need to configure a large number of small ATS zip files on the beacon, you must specify a higher value for the applicationMetadataQuota_BEACON property.
@ This property determines the total size that the beacon can consume to store
@ ATS zip files. If the user intends to use large ATS zip files or wishes to
@ configure large number of small ATS zip files on a beacon then this property
@ should be appropriately increased.
Append -Xms512m -Xmx1024m to the agentJavaDefines property. This increases the Java VM heap size to 1024 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.example.com as the beacon's Web proxy, specify the values as the following:
Proxy Host: www-proxy.example.com Proxy Port: 80 Don't use Proxy for: .example.com,.example1.com
Note:
You cannot play Siebel service tests and Web Transaction (Browser) service tests on the same machine.
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, and so on.
By using ATS load scripts, you can:
Reuse ATS testing scripts for production application transaction monitoring as part of application lifecycle management.
Expand the beacon capabilities by:
Supporting complex application flows with mixed application types and protocols such as HTTP and Oracle Forms application in one flow.
Supporting protocol based Siebel application monitoring.
Providing Databank support.
Incorporating enhanced scripting and debugging features from Openscript.
Adding the latest script modules and features without updating Enterprise Manager.
Creating an ATS service test involves the following:
Visit http://www.oracle.com/technetwork/oem/app-test/index-084446.html to download Openscript.
Launch the installer and follow the steps to install Openscript.
Record a new ATS transaction script by following these steps:
Launch Openscript and from the File menu, select New.
Select the type of script to be created and click Next. Some of the script types you can create are Adobe Flex, Oracle Fusion / ADF, Siebel, Database, Java Code Script, Web/HTTP and so on.
Select the location where the script is to be stored, enter a script name, and click Finish.
From the View menu, select Openscript Preferences to set the recording preferences.
Select Record Category and then select HTTP Preferences. Change the Record Mode from Web to HTTP. This ensures that scripts are played back correctly.
Select Record from the Script menu. The browser automatically opens when you start recording.
Load the web page where you want to start recording into the browser. Navigate the web site to record page objects, actions, and navigations. When you have finished navigating pages, close the browser and click Stop.
Select Playback from the Script menu to verify that the script has been properly recorded. Watch the application flow being played back in the play pane. Make sure the message log pane does not have any errors or failures. Save the script.
After the script has been recorded, from the File menu, select Export Script.
Specify the location in which the script is to be saved. You can save the script in a repository or workspace.
Enter a name for the script and click Finish. A script bundle (.zip) is created. Make sure that the script bundle is self contained. See Creating a Self Contained Zip File.
Note:
If the script file is very large, uncheck the Recorded Data option.
Log into Enterprise Manager, upload the script bundle, and create an ATS service test. See Creating an ATS Service Test for details.
For more details on OATS, please refer to Oracle® Functional Testing OpenScript User's Guide.
You must ensure that the zip file is self contained and contains the following:
<txn name>.jwg: The archive file that contains the compiled script executable to be run by Execution Engine.
script.java: The actual script Java source file.
<script name>-descriptor.xml – Describes the step hierarchy
script.xml: Describes the variables in the databank.
modules.properties: Describes which internal modules are required for the engine.
Assets.xml: Describes the dependent resources used by the root scripts including databank files, sub scripts, object libraries, and so on.
Databank Files: The databank files used by the script while substituting different variable values.
Object Libraries: The libraries that contain user-defined object identification rules and names. This is only applicable for functional testing scripts
Dependent Scripts: A script can call out to other script.
To create an ATS service test, follow these steps:
Note:
To use the command line utility (EM CLI) to create and customize an ATS Test instance using the service test available in the repository, see Oracle Enterprise Manager Lifecycle Management Administrator's Guide.
If the space quota for the beacon has been exhausted, the beacon cannot playback the recorded values in the ATS script and you may see the following error:
Beacon synchronization did not transfer the needed files to the agent. Please check the agent log. File at: <directory>
To address this issue, the applicationMetadataQuota agent property must be set to a higher value in the emd.properties file. The default value is 500 MB but if there are several large files to be uploaded, this must be increased. After the property value has bee changed, you must restart the Management Agent.
Notes:
The ATS files are present in the /EMSTATE/sysman/ApplicationState/beacon directory.
File names have following naming convention <Txn guid>_<beacon guid>.zip.
ATS related logs (gcagent.log, gcagent_error.log, emagent.nohup) are available in the EMSTATE/sysman/log folder
You can parameterize recorded script inputs to perform data driven testing. Examples of inputs that can be parameterized include user name, password on the login page, data entered in the search field, recorded navigations or user actions, and so on.
You can use databanks as the data source for parameterizing script inputs. Databanks are one or more external comma-separated value (CSV) or text (TXT) files that provide inputs to script parameters. Multiple Databank files can be attached to a single script and users can specify how OpenScript assigns data during script playback.
You can select data input values from an external.csv file and substitute the variable values with the values from the Databank. The field names are on the first line of the file separated by commas (no spaces). The field data is on subsequent lines separated by commas (different line for each record, no spaces around commas). An example is shown below:
FirstName,LastName,Mail,Phone John,Smith,JohnS@company.com,x993 Mary,Ellen,MaryE@company.com,x742
To use the databank records, follow these steps:
Open or create a script project.
Configure the Databank to use with a script in the Assets Script Properties.
Select the script node where you want to use the Databank record.
Select the Script menu and then select Other from the Add sub menu.
Expand the General node and select Get Next Databank Record. Click OK.
Select Databank avitek alias to specify the Databank file from which the records are to be retrieved.
Click OK. A GetNextDatabankRecord: databank alias node will be added to the script. In the Java Code view, the getDatabank("databank alias").getNextDataBankRecord() method will be added to the script code as follows:
getDatabank("avitek").getNextDatabankRecord();
After you have configured the databank for use with a script, you can map the databank files to specific script parameters. To map databank fields to script parameters, follow these steps:
{{db.avitek.Username,fred#@golf.com}}{{db.avitek.Password,weblogic}}For more details on setting up the Databank, see the Oracle® Functional Testing OpenScript User's Guide.
Adding a Beacon Specific Databank File
You can use the upload_ats_test_databank_file emcli command to add a beacon specific databank file. The format of this command is given below:
emcli upload_ats_test_databank_file -name=<service_name> -type=<service_type> -testname=<test_name> -testtype=<test_type> -databankAlias=<databank alias> -input_file=databank:<input_file> -beaconName=<beacon_name>
You can create variables to use for URLs in a script. If you need to change the base URL of a script, parametrizing the URLs provides a quick way to re-baseline a script to use a new URL.
To parameterize URLs, follow these steps:
You can perform text matching from TreeView and CodeView. For example, if you enter a string "hello" in a Google search window, the text matching is as follows:
web.document("/web:window[@index='0' or @title='Google']/web:document[@index='0']").assertText("MatchText", "hello", Source.DisplayContent, TextPresence.PassIfPresent, MatchOption.Exact);
Source - enum - (Html,Display Content)
Html - Raw Html including Tags
Display Content - Html without tags
MatchOption - Not Case Sensitive
Exact - sensitive: Matches any part of source string. For example, if the text entered is abcdef, if you enter abc, the string will match.
ExactEntireString: Matches the exact source string.
RegEx - Not Case Sensitive: Matches source string and sub-string. For example, if the text entered is abcdef, you can enter a.*d.
RegExEntireString: Matches the entire source string only. For example, if the text entered is abcdef, you can enter a.*f.
Wildcard - wildcard pattern: Matches source string and substring. For example, if the text entered is abcdefghijklm, you can enter a?c*f.
WildcardEntireString: Matches the entire source string. For example, if the text entered is abcdefghijklm, you can enter a*m.
You can use the beacon override feature to specify different variable values for a test running on a different beacon. To do so, follow these steps:
Databank_Alias>."<COLUMN_NAME>"="VALUE",<Databank_Alias>."<COLUMN_NAME>"="VALUE",...
For example:
FusionCredentials."host"="fs-aufsn4x0cxf",FusionCredentials."hostlogin"="login-aufsn4x0cxf",FusionCredentials."username"="faadmin",FusionCredentials."password"="fusionfa1"
To update the ATS test script, follow these steps:
.csv file using a spreadsheet editor and save the changes.If the ATS service test data is to be monitored by RUEI, you must specify the x-oracle-slm-message-id request header in the Additional Playback Options field. The format is in the form: name1:value1;name2:value2;name3:value3.
For example, x-oracle-slm-message-id: bcn=<beacon_name>; svc=<service_name>;test=<test_name>;step={{@getTopLevelStepName())}}
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.
Performance metrics to help you identify how well the service test is performing for each of the remote beacons. In general, the local beacon should have a very efficient and consistent response time because it is local to the Web application host. Remote beacons provide data to reflect the response time experienced by your application end users.
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 29-1 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. If you select this option, you can choose the Rule Based Target List.
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 29-2 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.
Note:
If you are defining performance metrics for an aggregate service, you can:
Add performance metrics from a single sub service.
Specify statistical aggregations of more than one metric.
After selecting the metrics, you can set the thresholds to be used to trigger incidents, or remove metrics that are no longer required.
The Rule Based Target List is applicable for system based performance metrics and direct members of system. You can define a rule that matches a system component you have selected. System components that match the user-provided rule will participate in the metric evaluation process. Later if any system component is added that matches this rule, this component will also participate in the metric evaluation process. If any system component that matches the rule is removed, that component will not participate in the metric evaluation process. The rule you define can be based on:
All (All system components)
Contains (Any system component that contains given criteria'
Starts With (Any system component that starts with given criteria)
Ends With (Any system component that ends with given criteria)
Equals (Any system component that matches with given criteria)
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 monitor the usage of a specific component or statistically calculate the average, minimum and maximum value from a set of components. For example, if you are defining an email service, which depends on an IMAP server, then you can use the 'Total Client Connections' metric of the IMAP server to represent usage of this email service. You can define usage metrics only for services that are associated with a system. 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 29-3 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.
Note that only metrics from system targets can be added as usage metrics. Metrics from tests are not indicative of usage, and therefore cannot be added as usage metrics.
Note:
If you are defining usage metrics for an aggregate service, you can
Add usage metric from a single sub service.
Specify statistical aggregations of more than one metric.
After selecting the usage metrics, you can set the threshold to be used to trigger incidents or remove metrics that are no longer required.
Rule Based Target List
The Rule Based Target List is applicable for system based performance metrics and direct members of system. You can define a rule that matches a system component you have selected. This enables you to promote performance metrics for evaluation. System components that match the user-provided rule will participate in the metric evaluation process. Later if any system component is added that matches this rule, this component will also participate in the metric evaluation process. If any system component that matches the rule is removed, that component will not participate in the metric evaluation process. The rule you define can be based on:
All (All system components)
Contains (Any system component that contains given criteria'
Starts With (Any system component that starts with given criteria)
Ends With (Any system component that ends with given criteria)
Equals (Any system component that matches with given criteria)