| Oracle® Web Services Manager Administrator's Guide 10g (10.1.3.3.0) Part Number E10299-01 |
|
|
View PDF |
| Oracle® Web Services Manager Administrator's Guide 10g (10.1.3.3.0) Part Number E10299-01 |
|
|
View PDF |
From the Oracle Web Services Manager (Oracle WSM) Operational Management menu options, you can view and manage performance of your Web services.
This chapter includes the following sections:
The Oracle WSM Monitor collects metrics (statistical measurements, operational status, and other information about service execution) from several sources, for Web services managed by Oracle WSM. Oracle WSM Gateways send metrics to the Oracle WSM Monitor for each Web service managed through the gateway. Agents also send metrics to the Oracle WSM Monitor, whether they are embedded in the client or in the server. You can view the metrics collected by Oracle WSM Monitor through the Operational Management section of Web Services Manager Control.
The Oracle WSM Monitor does the following:
Correlates and stores operational metrics on Web service execution and Web Services Manager component performance.
Restricts data queries and views of system configuration information to authorized parties.
Allows administrators to define rules for actions and conditions that generate alarms and notification.
Allows administrators to create custom reports by recording performance of managed Web services and Web Services Manager components.
The following are the benefits of Oracle WSM Monitor:
Improves application integrity by alerting information technology (IT) administrators of service-level performance or availability issues for any Web service in the network, so issues can be quickly addressed.
Reduces time in troubleshooting and diagnosing problems by quickly identifying Web services and applications causing failures or performance problems.
Enhances security by continuously monitoring the entire services network for security violations.
Ensures conformance to service-level agreements (SLAs); administrators can be notified when service performance fall below set limits.
The Operational Management options in Web Services Manager Control let you display snapshots of Oracle WSM system and Web service performance, create custom views of Oracle WSM metrics and performance data, and create alarm rules and view service alarms.
In the left pane of Web Services Manager Control, there are three distinct sections in the Operational Management menu—for performance reporting, creating and displaying customized views, and creating and viewing alarms. You can select the Snapshot, My Views, and Alarms options simply by clicking the corresponding links. Menu options that display the icon, that is, Overall Statistics, Security Statistics, Service Statistics and Alarm Rules, include submenu options, so you can click the main menu choice to expand and display the available submenu options.
Table 6-1 provides a brief description of each Operational Management menu option that appears in Web Services Manager Control.
Table 6-1 Operational Management Navigation Pane Options
| Menu Option | Description |
|---|---|
|
Snapshot |
Provides an overall view of Oracle WSM managed services. Visual dashboard elements display overall, security, and service statistics for selected Oracle WSM components and services. |
|
Overall Statistics: |
Provides an expandable menu with choices that display overall Oracle WSM performance measurements. |
|
SLA Compliance |
Compares actual performance metrics against configurable SLA conformance limits. |
|
Execution Details |
Provides a graph of service execution attempts; also provides information on success or failure, latency, failover, and so on. |
|
Message Logs |
Lists message log entries for service requests and responses. For failures, you can drill down to view error messages. |
|
Flows |
Provides a searchable list of monitored flows. A flow is a collection of Web service invocations that are grouped together within some context, for example, a collection of application services required to fulfill a client request in processing an order. |
|
Security Statistics: |
Provides an expandable menu with choices that display Oracle WSM performance measurements pertaining to authentication and authorization. |
|
Access Control |
Shows distribution of access failures for all service execution attempts. Graph also shows the distribution of all granted requests and failures of authorization and authentication for all access attempts. |
|
Service Statistics: |
Provides an expandable menu with choices that display Oracle WSM performance measurements pertaining to service latency and message traffic. |
|
Latency Variance |
Provides a graph showing maximum and minimum latency metrics, by individual service or all services. |
|
Traffic Analysis |
Displays number of bytes and messages per service by individual service or all services. |
|
My Views |
Provides access to customized views of service and message log information based on atomic (field value) or aggregated measurements; also allows you to create custom views. |
|
Alarms |
Search and display alarms based on the Component ID, time range, alarm type, or alarm severity. |
|
Alarm Rules |
Provides menu choices to create alarm rules and process Oracle WSM alarm information. |
|
Alarm Creation |
Creates or edits Oracle WSM rules to generate alarms based on specific conditions such as service execution or policy step processing, latency, and SLA conformance triggers. |
|
Alarm Processing |
Specifies alarm processing such as actions to perform when rules trigger an alarm. |
The following sections describe operations performed by each Operational Management menu group.
Web Services Manager Control provides a centralized location from which system administrators can accomplish the following performance monitoring tasks:
View a summary snapshot view for system health of all services, or view the health of only selected services.
View statistics for service-level agreement (SLA) compliance, execution details, message logs, and transaction flows.
Edit and monitor conformance of performance SLAs.
View security statistics for authentication and authorization failures.
View service statistics for service latency variances.
Analyze message traffic.
The Oracle WSM Monitor captures service detail information, status, and performance metrics from each service request or response handled by Oracle WSM gateways or agents. That information is then stored in the Oracle WSM Database, where it can be retrieved by requests to display status, statistics, snapshots, views, and so on. You can also create rules that will process information stored in the database to generate alarms and other messages that alert you to potential problems.
The operational snapshot view gives system administrators an overview of performance and availability for all managed Web services. If problems arise that affect performance of one or more Web services, these problems will be reflected in the Snapshot view. The graphs in that view display information for three categories:
Overall Statistics
Overall failures: Shows the average rate of failure occurring in any of the steps of a Web service policy pipeline, or during the execution of a selected service.
Overall latency: Show the average latency for execution for the selected services and corresponding policy pipelines
Security Statistics
Authentication failures: Shows the average rate of failure in the authentication step of the policy pipelines for the selected services.
Authorization failures: Shows the average rate of failure in the authorization step of policy pipelines for the selected services.
Service Statistics
Service failures: Shows the average rate of failure occurring during execution of a selected service. Does not include failures occurring in policy steps.
Service latency: Shows the average latency for execution of the selected services. If a failure occurs in any policy step prior to service execution, no data will be included for those services.
This section describes how to see a snapshot view of the Oracle WSM system.
To view a system snapshot
From the navigation pane of Web Services Manager Control, select Operational Management, and then select Snapshot.
The Snapshot page is displayed.
Oracle WSM generates the summary values for all services by processing values from all Web services, or for all services connected through a single enforcement component (a gateway or an agent), as indicated by the Component list. The default view summarizes the data for all connected services.
Note:
If you have just installed Oracle WSM, some dials similar to those in Figure 6-1 may not have any data to display. In that case, the dials will indicate an absence of data by a lighter color.You can view all the services managed by one component, choose just one of the managed services, or designate a specific time range by choosing a combination of the Component, Service, and Time Range from the menus.
To view service performance
From the navigation pane of Web Services Manager Control, select Operational Management, and then select Snapshot.
Select a component from the Component list.
Web Services Manager Control now displays statistics and performance measurements specific to the component you selected.
From the Service list, select a specific Web service for which to display measurements. The list of services in the list are the services managed by the selected component.
From the Time Range list, select the time period for which to display results.
Click Display.
Web Services Manager Control now displays a snapshot based only on data for the selected component, service, and time range.
In the navigation pane of Web Services Manager Control, click Operational Management, and then select Overall Statistics to generate real-time reports on Oracle WSM performance. These reports are based on statistics that combine measurements for both the policy execution and Web service execution. For example, the latency statistics combine the time taken to execute all the steps in the policy pipeline for a service (for example, logging, authentication, authorization, and decrypting,) with the time for the execution of the Web service.
The options for Overall Statistics reporting in Web Services Manager Control include the following:
Viewing compliance with service-level agreements for all services or only for selected services
Editing service-level agreements
Viewing detail information on Web services execution
Viewing message logs
Viewing execution flows across multiple services
For all Web services managed by a gateway or agent, Oracle WSM creates default service-level agreement (SLA) settings that are in force until you edit them to define your own service performance requirements. You can edit an SLA configuration for any service registered to an Oracle WSM component.
Oracle WSM compares the values, derived from actual traffic metrics, with the SLA for each Web service. The distribution of values is displayed in red, yellow, and green zones on the bar graphs or pie graphs, according to the categories shown in Table 6-2:
Table 6-2 Graphical Display Color Key
| Color | Meaning |
|---|---|
|
Green |
Web services performing within SLA |
|
Yellow |
Web services performing close to limit of SLA |
|
Red |
Web services performing outside limit of SLA |
Monitoring SLA Compliance
This section describes how to use Oracle WSM to monitor compliance with service-level agreements for all services.
To monitor the service-level agreement (SLA) compliance for all services
From the navigation pane of Web Services Manager Control, select Operational Management, select Overall Statistics, and then select SLA Compliance.
Web Services Manager Control displays a summary of SLA compliance for all Oracle WSM managed services.
Viewing SLA Compliance
This section describes how to use Oracle WSM to monitor compliance with service-level agreements for a selected component, service, and time range.
To view SLA Compliance for a selected component, service, and time range
From the navigation pane of Web Services Manager Control, select Operational Management, select Overall Statistics, and then select SLA Compliance.
By default, Oracle WSM displays the SLA Compliance for all services in the last hour.
Figure 6-2 Service-Level Agreement (SLA) Compliance for All Services
From the display criteria lists, select the component, service, and time range for which you want to view SLA compliance.
Click Display.
Web Services Manager Control now shows SLA compliance for the selected component, service, and time range.
Figure 6-3 Service-Level Agreement (SLA) Compliance for a Selected Service
From this display, you can move your cursor over particular sections of the pie chart to display more detailed information on the overall service execution.
Editing Service-Level Agreements
This section describes how to specify specific conformance levels for latency, downtime, and failure rates.
To edit specific conformance levels for latency, downtime, and failure rates
From the navigation pane of Web Services Manager Control, select Operational Management, select Overall Statistics, and then select SLA Compliance.
From the Component list, select a component.
Click Display.
Web Services Manager Control displays overall statistics and SLA compliance for the selected component.
Click Edit SLA Values.
Web Services Manager Control now lets you view and update specific SLA parameters.
Select the component and the Web service for which you want to edit SLA conformance levels.
Click Next.
Web Services Manager Control displays current SLA limits defined for the specified component and Web service.
Specify the new SLA limits you want to enforce.
Click Save.
Note:
Oracle WSM uses default SLA values for any SLA limits for which you do not specify a value.Execution Detail views that Oracle WSM provides give administrators a way to monitor the details of service invocations. Execution Detail views display instances (represented by dots) of actual messages over time, plotted against their overall latencies. The color of a dot indicates the overall status of a service execution.
Viewing Execution Details for All Services
This section describes how to view the execution details for all services.
To view execution details for all services
From the navigation pane of Web Services Manager Control, select Operational Management, select Overall Statistics, and then select Execution Details.
By default, Web Services Manager Control displays execution details for all connected services.
To view more information on specific service execution instances, position your cursor over individual dots in the graph.
When you position your cursor over a dot, Web Services Manager Control displays a brief message listing the service name, service ID number, time, and latency measurement for the execution instance.
Viewing Execution Details of Specific Services
This section describes how to view the execution details for a specific Web service.
To view execution details of specific services
From the navigation pane of Web Services Manager Control, select Operational Management, select Overall Statistics, and then select Execution Details.
Select a component, service, and time range from the lists.
Click Display.
Web Services Manager Control displays execution details only for the selected Web service.
Figure 6-4 Execution Details for a Specific Service
You can position your cursor over individual dots in the graph to view more information on specific service execution instances. Web Services Manager Control displays a brief message listing the service name, service ID number, time, and latency measurement for the specific execution instance.
By default, Oracle WSM policies create logs for all request and response messages processed through gateways or agents. Message logging for a Web service is customized by modifying the properties for the logging step in the service's policy pipeline.
For more information on configuring the Log step properties for either gateways or agents, see "Adding Policy Steps to Oracle WSM Gateway Web Services" and "Creating Policies for Oracle WSM Agents".
To view message logs
From the navigation pane of Web Services Manager Control, select Operational Management, select Overall Statistics, and then select Message Logs.
Select the component and time range from the lists.
Click Search.
The Message Logs page displays a list of service requests and responses matching the specified component and time range. For each log entry, Web Services Manager Control displays the service ID, the time stamp of the log entry, and the type of log entry, request or response.
From this display, you can click the hyperlinked number entries in the Index column to view the details of specific responses or requests corresponding to log entries.
Note:
The next section describes how you can view flow execution details from Web Services Manager Control. You can display the same log request or response detail as that shown in Figure 6-6, by selecting individual service invocation points on the graphs that show flow execution details.When you display the message logs for a component, by default, Oracle WSM displays up to 500 of the most recent message logs. If there are more than 500 message logs, you will not be able to view messages 501 and beyond. You can configure the number of messages that are displayed by editing the following file:
ORACLE_HOME/owsm/config/ccore/ui-config-installer.properties
Edit the ui.messagelog.maxViewableMessageLogs property and specify the maximum number of messages you want displayed. By default, this property is set to 500.
ui.messagelog.maxViewableMessageLogs=500
If you do not want to set a limit, that is, you want to be able to see all messages, then specify zero (0), as in
ui.messagelog.maxViewableMessageLogs=0
A flow is a collection of Web services's invocation data that is grouped together within a particular context. For example, fulfilling an order may require access to several back-end Web services to complete the entire operation. All these service invocations for a single transaction are grouped together to define the context of an order fulfillment flow.
Note:
For more information on designing message structures so that Oracle WSM can effectively interpret how messages are related in the same flow or transaction, see "Designing Messages Structures for Oracle WSM Flow Tracking".With options available from Web Services Manager Control, you can view the service execution flow across multiple Web services.To view flow execution from Web Services Manager Control:
From the navigation pane of Web Services Manager Control, select Operational Management, then select Overall Statistics, and then select Flows option.
Select the flow type and time range from the lists.
Click Search.
Web Services Manager Control displays a list of all service flows selected by your search criteria.
To see the details of a particular flow, click Context ID.
Web Services Manager Control displays a summary of the different service invocations involved in the flow.
Click Chart View.
Web Services Manager Control now displays a graph showing details of the service invocations in the flow. In the graph, the horizontal axis represents time (relative to flow execution) and the vertical dimension shows the services invoked in each of the flow instances.
The blue horizontal line represents the flow time line.
Each service invocation (or subflow) is denoted by a blue vertical line.
Each Web service (subflow type) has its own time line, represented by the horizontal lines.
Each section of a horizontal line is color-coded; GREEN represents successful execution, RED indicates a service failure, and YELLOW represents that the service was successful after failover.
Flows are messages that are related to each other in some application-determined manner. Messages may be related because they are part of an overall transaction, or because they trigger each other. The Web service application determines which messages are related to each other, and indicates this by inserting the same correlation ID in all the messages that are part of the same flow. This correlation ID can be thought of as the flow ID.
How Does an Application Put the Flow ID into the Message?
The application developer who is writing the application that invokes a Web service must put flow IDs into the message headers. The same flow ID should be inserted into the headers of any related messages. Flow IDs are inserted into the SOAP header using the <RelatesTo> tag defined by the WS-Addressing specification, for example:
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing"
xmlns:cswm="http://schemas.confluentsw.com/ws/2003/08/Message">
<soap:Header>
<wsa:RelatesTo RelationshipType="cswm:ParentContext">
uuid:8EB9-C6A3-75AA-7EBA
</wsa:RelatesTo>
<soap:Header>
<soap:Body> ...... </soap:Body>
</soap:Envelop>
How Does the Oracle WSM Monitor Track Flows?
Oracle WSM agents and gateways automatically inspect each message that passes through them to see if the SOAP header contains a <RelatesTo> tag. If a <RelatesTo> tag is found, then the flow ID is extracted and sent along with other metrics about the message (latency, sender, destination, and so on) to the Oracle WSM Monitor.
The Oracle WSM Monitor stores the flow IDs for all the messages it receives and then correlates the messages containing the same IDs to deduce the flow.
How Does the Oracle WSM Monitor Know When a Flow Started and When It Ended?
Only the application being monitored can tell when the flow transaction is completed. The Oracle WSM Monitor provides SOAP APIs that allow applications to tell the Oracle WSM Monitor when the flow begins and when the flow ends. These SOAP APIs are, in effect, calls to the Oracle WSM Monitor that say:
monitor.beginFlow (flowId); .... monitor.endFlow (flowId);
You do not have to send the begin and end SOAP messages to the Oracle WSM Monitor to view flows in the Operational Management section of Web Services Manager Control. Flows for which the Oracle WSM Monitor has not received begin and end messages show up as pending in the Flows view. If you choose to send the begin and end messages, you must use Java APIs that construct the SOAP message and send it to the Oracle WSM Monitor.
Note:
If you have specific requirements for tracking message flows in Oracle WSM and need more technical details on how to implement the changes, contact your Oracle support representative or Oracle Support Services.The Security Statistics option provides a way for you to view and monitor authentication and authorization activity with Oracle WSM managed services. Authentication failure occurs when the proper credentials are not presented during enforcement of the Oracle WSM policy step for authentication, that is, when a user tries to invoke a Web service without first obtaining the proper permissions.
The Oracle WSM Security Statistics option provides two different graph type options to display access failures, as described in Table 6-3.
Table 6-3 Security Statistics Graph Types
| Graph Type | Description |
|---|---|
|
Bar Graph |
Shows the distribution of access failures per Web service, per selected component. |
|
Pie Graph |
Represents per component, for all Web services registered to that component, and shows the distribution of all access attempts; total successes over failure of authorization and failure of authentication. |
By default, Web Services Manager Control displays a summary of security statistics access control failures.
To view a summary of access control violations
From the navigation pane of Web Services Manager Control, select Operational Management, select Security Statistics, and then select Access Control.
From Web Services Manager Control, you can also view access control violations for selected components, services, and time ranges.
To view selected access control violations
From the navigation pane of Web Services Manager Control, click Operational Management, select Security Statistics, and then select Access Control.
Select the specific component, service, and time range for which to view access control information.
Click Display.
Web Services Manager Control now displays access control violations only for the component, service, and time range you specified.
Figure 6-7 Access Control for Selected Service
From this display, you can move your cursor over particular sections of the pie chart to display more detailed information on access control attempts and failures. Web Services Manager Control displays a window showing the actual percentages of access attempts, successes, and failures.
The Service Statistics options in Web Services Manager Control (Latency Variance and Traffic Analysis) show statistics based solely on service execution, not including the latency of any policy steps. If the service fails in the policy execution, prior to the service execution, no statistics will be displayed.
Viewing Service Latency Variance
Web Services Manager Control provides an option to view service latency variance, which allows administrators to monitor the variations in Web service performance over a selected time period.
To view service statistics for latency variance
From the navigation pane of Web Services Manager Control, select Operational Management, select Service Statistics, and then select Latency Variance.
The latency variance for all services is displayed.
Viewing Latency Variance for Selected Display Criteria
From the navigation pane of Web Services Manager Control, select Operational Management, select Service Statistics, and then select Latency Variance.
Select the desired component, service, and time range for which you want to view latency variance information.
Click Display.
Web Services Manager Control now displays the latency variance for the selected component, service, and time range.
Figure 6-8 Latency Variance for Selected Service
The Traffic Analysis option provides an analysis of the volume of message activity, including message size, for selected services.
To view traffic analysis statistics
From the navigation pane of Web Services Manager Control, select Operational Management, select Service Statistics, and then select Latency Variance.
Web Services Manager Control displays charts reflecting message traffic for all selected services.
From this display, you can move your cursor over particular sections of the pie chart to display more detailed information on individual services. A brief message will display information on the number of messages per operations.
To view traffic analysis for selected display criteria
From the navigation pane of Web Services Manager Control, select Operational Management, select Service Statistics, and then select Traffic Analysis.
Select a desired component, service, and time range from the lists.
Click Display.
Web Services Manager Control displays message traffic information for the selected component, service, and time range.
Figure 6-9 Traffic Analysis for Selected Service
As before, you can move your cursor over particular sections of the pie chart to display more detailed information on individual services. In this case, a brief message will display information on the number of messages per operation.
The Snapshot, Overall Statistics, Security Statistics, and Service Statistics options in the Operational Management menu provide standardized views of metrics that Oracle WSM monitors and captures for system and service operations. Using the Operational Management My Views option, you can create customized views of metrics and other Oracle WSM data. In creating a customized view, you define and save a template that defines a set of data and, optionally, a time interval, to capture and display metric information. You can then go back anytime later to run one of your views and display the metrics and other information that matches its parameters and conditions.
Oracle WSM lets you define any number of customized views. For example, you can create separate views that focus the data on metrics and other service detail information captured by the Oracle WSM Monitor for particular gateways, agents, and services. You can also specify different views that either aggregate data field values (the average over several metrics) or return all atomic (single-event metric) data sent to the Oracle WSM Monitor from selected gateways, agents, and services.
Note:
Views are created and maintained on a per group basis.To display and select from a list of customized views
From the navigation pane of Web Services Manager Control, select Operational Management, and then select My Views.
Web Services Manager Control displays the My Views page that shows a list of any existing customized views that you have created and saved.
From this page, you can choose to run an existing view, delete or edit a view, or create a new customized view.
Click the Run icon.
When you run a view, Web Services Manager Control displays the results for the selected view.
In the aggregated view, you see performance statistics such as the number of total requests, successes and failures, the average overall and service execution latency, plus some other related metrics. You can click the hyperlinked headings in the table to sort the rows, based on data values in a particular column. In addition, you can click the hyperlinked data values in columns showing either average or total (count) values to drill down and view the detailed service metrics that were included in the calculation.
In a nonaggregated view, you see the metrics for specific service requests (and responses), with specific atomic data values in each row. In addition, you can click the hyperlinked index column values to display the details of the request or response log entry for specific operations.
Oracle WSM displays up to 25 rows of service request data per page. You can click Previous, Next, or a specific hyperlinked Page Number to navigate pages contained in the view.
You can create as many customized views of Oracle WSM metrics as you want. Views are maintained and displayed on a per group basis.
To create a new view
From the navigation pane of Web Services Manager Control, select Operational Management, and then select My Views.
From the My Views page, click Create New View.
Web Services Manager Control displays a New View form in which you can specify a name for the view and select options that will determine the metrics to be included in the view.
Oracle WSM shows a different list of display fields depending on whether you selected Atomic (single-event metric) or Aggregated (counting or averaged over several metrics). Table 6-4 and Table 6-5 provide descriptions of the different columns available in the two views.
Fields that require an entry on the New View form are denoted with an asterisk (*). To begin, specify a name for the view and then also specify the components and associated services for which you want metrics to be included in the view. In both the Components and Services lists, you can select one or more components or services (using Shift or Control keys to select multiple items in the list).
In the Time fields, you can optionally specify a start time, and end time, or both a start and end time, to define an interval of time by which to qualify metrics included in the view. If you specify only a start or end time, you can optionally also specify a duration that will designate the metrics to be included in the view, for a period of time following the start time, or before the end time. In specifying start and end times, you can choose keyword options such as -2 hours or -2 days before the current time (relative to the time the query is run). Or, you can enter discrete start and end dates and times using the format: MM-dd-yyyy HH:mm. The time zone field lets you specify the time zone in which the start and end times will be calculated, so the view will include metrics generated only in the specified time period.
Table 6-4 Display Field Options for Atomic (Single Event) Views
| Field | Description |
|---|---|
|
Component |
Gateway or agent name where message was processed. |
|
Service |
Name as service being invoked (last part of URL). |
|
Operation |
Service operation that was invoked. |
|
Overall Status |
Overall status of the invocation, including policy and service execution. |
|
Authentication Status |
Success or failure indicator if authentication step in policy is attempted. |
|
Authorization Status |
Success or failure indicator if authorization step execution in policy is attempted. |
|
Service Status |
Success or failure, failover, or pending indicator if service execution is attempted. |
|
Size |
Total size of request and response messages, if information is available. (Size is currently available only for messages handled by gateways.) |
|
Overall Latency |
Overall time delay of a service invocation, including policy and service execution. |
|
Service Latency |
Overall time delay of service execution. |
|
User ID |
User ID of the user invoking the service, if available. |
|
Timestamp |
Time of invocation (when request message arrived at gateway or agent). |
Display fields listed in Table 6-4 are available when you choose the Atomic Display Fields option to create an Atomic (nonaggregated) view. Display fields listed in Table 6-5 are available when you choose the Aggregated Display Fields option to create an aggregated view.
Table 6-5 Display Field Options for Aggregate Views
| Field | Description |
|---|---|
|
Component |
Gateway or agent ID where messages were processed. |
|
Service |
Service being invoked (displays last portion of service request or response URL). |
|
Operation |
Service operation that was invoked. |
|
Number of Requests |
Total number of request and response messages processed. |
|
Number of Successes |
Total number of messages successfully executed. |
|
Number of Failures |
Total number of messages where execution failed. |
|
Number of Authentication Failures |
Total number of authentication failures (for messages where authentication step is included in policy). |
|
Number of Authorization Failures |
Total number of authorization failures (for messages where authorization step is included in policy). |
|
Number of Service Failures |
Total number of service execution failures. |
|
Average Overall Latency |
Average latency of all service invocations (including policy and service execution). |
|
Average Service Latency |
Average latency of all service executions. |
|
Number of Bytes |
Total (aggregate) size of all request and response messages. (Size is currently available only for messages handled by gateways.) |
For both types of views, you can select check boxes next to fields you want to appear and clear those check boxes you do not want to include in a view.
The Oracle WSM Monitor captures and stores service details, status, and performance metrics from each service request or response handled by Oracle WSM gateways or agents. By creating rules in Web Services Manager Control, you can select and process certain information to generate alarms and other messages that alert you to existing or potential problems with services managed by Oracle WSM. The Operational Management menu in Web Services Manager Control includes options to do all of the following:
Search and view generated alarms based on the Component ID, time range, alarm type or severity.
Create and edit rules to generate alarms based on specific conditions, such as service execution or policy step processing, latency, and SLA conformance triggers.
Specify alarm processing and notification actions to perform when rules trigger an alarm.
The following sections describe options available to view generated alarms and how you can define new alarms and alarm processing rules for the operation of your Oracle WSM system.
As an administrator, you will want to be notified as soon as possible if there is a problem with one of your Web services. Oracle WSM has a system for creating alarms to alert you when a Web service is not functioning as planned.
This section includes the following topics:
Viewing generated alarm data
Creating new alarm rules
Creating alarm processing rules
Oracle WSM ships with one default alarm for latency. To generate alarms, you must enable the default alarm or create a new alarm. Once enabled, generated alarms are logged and may be searched by component, time range, alarm type, and severity level.
The alarms menu lists all generated alarms. Oracle WSM ships with one default alarm rule. The rule is disabled until you change the setting. To generate visible alarm data, you must enable the default alarm or create a new alarm. Each alarm type has a rule that is triggered by a specific condition. The conditions that trigger the rules can be reviewed by looking at the details of the alarm type for each rule. For more information, see "Creating an Alarm Rule with Oracle WSM".
To view generated alarm data
From the navigation pane of Web Services Manager Control, select Operational Management, and then select Alarms.
The alarm browser displays a list of alarms, up to the first 25 most recent alarms. View the results beyond the first 25 by clicking Get Next until the results for the desired time period are displayed.
From this page, you can also search and display specific alarm types by selecting Component, Time Range, Alarm Type, and Severity options from the lists and clicking Search.
View individual alarm details by clicking the associated service ID number.
Web Services Manager Control displays details of the selected alarm message.
An alarm rule specifies how Oracle WSM processes metrics to trigger alarms. Once created, alarm rules are combined with a rule action, typically an alert sent to key personnel.
To create an alarm
From the navigation pane of Web Services Manager Control, select Operational Management, select Alarms, select Alarm Rules, and then select Alarm Creation.
Web Services Manager Control displays alarm creation rules you have defined.
Click Add New Rule.
Web Services Manager Control displays a page in which you can define a new alarm rule.
Enter the Alarm Type and enter a brief description.
Select a Measurement Type from the list.
Alarm rules can be based on the measurement types described.
Table 6-6 Invocation Measurement Types
| Measurement Type | Description |
|---|---|
|
agginvocation |
Statistics that summarize a set of invocation statistics received for a given service over a specified period of time (default =2 minutes). For example, using this type, you could create an alarm if average latency drops below a certain level. |
|
aggping |
Aggregated ping statistics. For example, using this type, you could create an alarm if a service is not accessible for 5 minutes. |
|
correlated-flow |
Flow events that happen within the same context. For example, using this type, you could create an alarm when a flow execution fails or takes more than a day to be completed. |
|
flow-event |
The start and end of a flow execution. For example, using this type, you could create an alarm when a transaction starts or ends. |
|
invocation |
Statistics for individual Web service executions. For example, using this type, you could create an alarm if service latency exceeds a specific threshold. |
|
ping |
Statistics based on synthetic requests. For example, using this type, you could create an alarm every time a service is not accessible. |
The alarm rule action is automatically enabled.
Click Next.
Web Services Manager Control now updates the page to let you specify an alarm severity level and conditions for the alarm rule to be triggered.
Choose an Alarm Severity Level from the list.
Specify a time zone and, optionally, specify days of the week and time intervals to qualify specific days and times when the alarm rule can be triggered.
For the Time Intervals field, you can specify a time interval using the time format shown (hh:mm:ss).
Specify one or more individual rule conditions in the Add new expression field to define when the new alarm rule will be triggered.
For example, you could define a condition, latency > 300, by selecting the latency option from the list in the left column, select the right angle bracket (>) as the condition operator from the middle column, and specify 300 as the value in the right column.
Note:
A rule condition consists of one or more logical expressions connected by the Boolean operator AND. You can define logical expressions based on any of the fields or variables defined in the measurements type. Commas can be used to specify multiple valid values that can satisfy a rule condition, for example, status=0,1.For more information on creating rules, "Operational Rule Basics".
Click Save.
Web Services Manager Control updates the alarm creation rules list, now including the alarm rule you just created.
The new Alarm rule is enabled and will be triggered by the conditions that match the specified rule condition. Generated alarms appear when you select Operational Management, and then select Alarms in Web Services Manager Control.
A rule consists of a condition and an action. The condition is a Boolean expression, and the action is an operation to execute when the rule is triggered. A rule can be seen as a conditional processing operation--if the condition is evaluated as true, then the action is performed.
Oracle WSM ships with a default set of metrics processing rules, and actions based on those rules. Rules may be assigned to a specific Web service, or they can operate over all Web services for a component. Rules can be defined and immediately assigned to a Web service, or they can be saved and activated at a later time. Rules become operational only after they are enabled and committed.
There are two basic types of Oracle WSM rules, outlined Table 6-7:
Table 6-7 Types of Operational Rules
| Rule Type | Description | Advantages | Limitations |
|---|---|---|---|
|
General |
Examines all metrics and takes action based on a single event. |
Preserves information about specific events. |
Could cause avalanche of actions in cases of Web service failure and have negative impact on system performance. |
|
Aggregated |
Examines only aggregated metrics and takes action based on a consolidated view of events. |
Lowers the risk that alarms can overwhelm system performance. |
Could lose information about specific events could during the aggregation process. |
If it is important that a system administrator be notified each and every time a Web service fails, you can define a general operational rule. Even if the Web service fails very rarely, this rule runs for every incoming Web service invocation metric. Defining operational rules as general rules could have a negative impact on system performance.
If efficient run-time performance is a priority, you can define a rule based on aggregated metrics, and base your rule on the number of failed invocations for a specified period of time. Oracle WSM then gathers data during the time interval and evaluates the aggregated data immediately after the specified time interval has passed.
Available Statistics for Building Rules
Aggregated rules, as described in Table 6-7, perform calculations involving integer statistics elements, which provide a way of keeping statistics about the values of an atomic variable over the specific aggregation provided by the rule.
Integer statistics are recorded for the following elements:
min: smallest value recorded during the aggregation.
max: largest value recorded during the aggregation.
last: last value recorded during the aggregation.
count: number of values taken into account during the aggregation.
total: sum of all values.
average: total or count of all values or events.
For instance, if the variable looked at is the speed of a car during a road trip and the aggregation has taken place over the whole trip, you might assemble the following statistics to describe the trip:
min : lowest speed recorded
max : max speed recorded
last : current speed
count : number of samples
total : total sum of all speed sample (not very relevant)
average : average speed over the trip
When defining rules, Oracle WSM references elements from aggregated statistics using the following conventions:
variable_name@stat.min variable_name@stat.max variable_name@stat.last variable_name@stat.count variable_name@stat.total variable_name@stat.average
Similarly, Oracle WSM references aggregated statistics that contain buckets which are conditional counters, using the following convention:
variable_name@bucket.bucketname
The following tables provides descriptions of statistics used in different types of rule aggregations.
Table 6-8 Agginvocation Rule Conditions
| Name | Type | Description |
|---|---|---|
|
latency-stats |
integer statistics |
Statistics about recorded overall latency, including both the policy execution and service invocation. |
|
service-latency-stats |
integer statistics |
Statistics about recorded endpoint service latency. |
|
message-stats |
integer statistics |
Statistics about the number of bytes exchanged in invocations. |
|
service-latency-buckets |
integer buckets |
Invocation information in three buckets (or categories):
|
|
access-control-buckets |
integer buckets |
Access control information in three buckets (or categories):
|
|
component-id |
string statistics |
Statistics about the ID of the component that issued this measurement. (Used for display and storage indexing purposes.) |
|
service-id |
string statistics |
Statistics about the ID of the invoked service. (Used for UI and storage indexing purposes.) |
|
service-name |
string statistics |
Statistics about the ID of the invoked service. (Used for display and storage indexing purposes.) |
|
operation |
string statistics |
Statistics about the name of operation (method) invoked on the service. (Used for display and storage indexing purposes.) |
Table 6-9 Aggregated Ping Rule Conditions
| Name | Type | Description |
|---|---|---|
|
latency-stats |
integer statistics |
Statistics about recorded latency. |
|
service-latency-stats |
integer statistics |
Statistics about recorded endpoint service latency. |
|
service-id |
string statistics |
Statistics about the service ID of the pinged service. (Used for display and storage indexing purposes.) |
|
service-name |
string statistics |
Statistics about the service ID of the pinged service. (Used for display and storage indexing purposes.) |
|
url |
string statistics |
Statistics about the pinged URL. (Used for display and storage indexing purposes.) |
|
component-id |
string statistics |
Statistics about the service ID of the component that issued this measurement. (Used for display and storage indexing purposes.) |
|
latency-buckets |
integer buckets |
Invocation information in three buckets (or categories). 1: Number of successful pings whose latencies are above expected value. 2: Number of successful pings whose latencies are below expected value. 3: Number of failed pings. |
Table 6-10 Flow-Event Rule Conditions
| Name | Type | Description |
|---|---|---|
|
type |
string |
The type of business process. |
|
event-id |
integer |
Event flows; can be of two types: 1: Flow level events 2: Task level events |
|
status |
integer |
The status of the current event: 0: Success 1: Failed 2: Pending |
Table 6-11 Ping Rule Conditions
| Name | Type | Description |
|---|---|---|
|
service-id |
string |
The ID of the invoked service. |
|
component-id |
string |
The ID of the component generating the measurement. |
|
pinged-url |
string |
The URL used to retrieve the WSDL document. |
|
status |
integer |
A successful invocation indicating that the WSDL document was returned. 0: Invocation successful 1: Invocation failed |
|
status-change |
integer |
The dynamics of multiple ping operations. This element indicates if the service went up, went down or did not change its status from the previous ping operations. Should be used to define alarm rules. 0: no-change 1: went-up 2: went-down |
|
latency |
integer |
Latency, in milliseconds, of WSDL document retrieval. |
|
http-status |
integer |
Status of the HTTP connection. (The current implementation uses the HTTP protocol to retrieve WSDL documents.) |
Table 6-12 Invocation Rule Conditions
| Name | Type | Description |
|---|---|---|
|
flow-id |
string |
The ID of the service flow. |
|
error message |
string |
Explanation describing why a service invocation failed. |
|
service-id |
integer |
Unique ID assigned to service by Oracle WSM upon service registration. |
|
authentication-status |
integer |
Status of the user authentication: 0: Authentication successful 1: Authentication failed |
|
service-latency |
integer |
Endpoint service latency, in milliseconds. |
|
service-status |
integer |
Endpoint service status: 0: Invocation successful 1: Invocation failed 2: Invocation failed over; the primary service end point failed, but a failover end point was successful. 3: Invocation pending. The service was contacted, data was sent to it; but no reply has yet come back. |
|
size |
integer |
Number of bytes exchanged for both query and response. |
|
user-id |
string |
The ID of the user that accessed the service. |
|
component-id |
string |
The ID of the component that issued this measurement. |
|
operation |
string |
Name of the operation (method) invoked for the service. |
|
latency |
integer |
Overall latency, in milliseconds, including both the policy execution and service invocation. |
|
authorization-status |
integer |
Status of the authorization: 0: Authentication successful 1: Authentication failed |
|
status |
integer |
0: Invocation successful 1: Invocation failed 2: Invocation failed over. The primary service end point failed, but a failover end point was successful. 3: Invocation pending. The service was contacted, data was sent to it, but no reply has yet come back. |
Alarm processing rules enable you as the administrator to receive an automatic alarm notification, or to trigger remedial actions. Once defined, processing rules for alarms are used to trigger actions (typically notifications of various types) that are sent to key personnel. The action desired is indicated by the alarm processing rule.
Oracle WSM ships with four default alarm processing rules that are disabled until you complete the information needed for the alarm action. You may also create your own alarm processing rule.
To create the action that the alarm takes when it is triggered
From the navigation pane of Web Services Manager Control, select Operational Management, select Alarms, and then select Alarm Processing.
Web Services Manager Control displays the default list of alarm processing rules that ships with Oracle WSM.
You can add alarm processing rules to this list. For example, you could create a processing rule to trigger another alarm or action.
Click Add New Rule.
Web Services Manager Control displays a new page in which you can define and specify actions for a new alarm processing rule.
Enter a name by which you can identify the new alarm processing rule and a brief description of the rule.
Select Alarm Type from the list.
Specify a Rule Action from the list, that is: e-mail notification, SNMP V1 Event, SNMP V2 Event, Service Invocation, or Custom.
Click Next.
Web Services Manager Control now updates the page to let you specify conditions for the processing rule action to be performed.
Select the Enabled check box to enable the alarm processing rule.
Specify a time zone and, optionally, specify days of week and time intervals to qualify specific days and times when alarm processing rules can be triggered.
For the Time Intervals field, you can specify a time interval using the time format shown (hh:mm:ss).
Specify a condition to trigger the action of the alarm processing rule.
You can generally enter a condition in the same way you specify conditions for an alarm creation rule. You could use this condition to process a generated alarm differently for different services or components. For example, different administrators could be notified when latency alarms are triggered for different services, depending on the service owner.
Note:
A rule condition consists of one or more logical expressions connected by the Boolean operator AND. You can define logical expressions based on any of the fields or variables defined in the measurements type. Commas can be used to specify multiple valid values that can satisfy a rule condition, for example, status=0,1.Click Next.
Web Services Manager Control displays a page for entering e-mail address and mail message information.
Enter the e-mail address for notification, and select or copy a desired message to include in the e-mail message body. The message body can be composed and can include alarm measurement variables, for example, latency value. If you pick the rule action SNMP V1, you will have to define how to compose ID and value fields from the available measurement variables.
Click Save.
The list of alarm processing rules is displayed with your new alarm processing rule action added to the list.
Note:
If you send an e-mail notification when an alarm is triggered, you must configure Oracle WSM with the E-mail Server and user account information. See Chapter 3, "Configuring the Oracle Web Services Manager Components," in Oracle Web Services Manager Deployment Guide for more information.You can view Oracle WSM metrics over a period of time. For example, you can get overall statistics for a gateway over the last 2 hours or for the last 30 days. You can select a time period from the Time Range list. By default, the Oracle WSM Database persists data only for the last 100 minutes. So, if you select the time range Last 10 minutes or Last hour from the Time Range list, you will see the metrics for the period you selected. If, however, you want to see metrics over a longer period of time, you must configure the Oracle WSM Database to store the data for the desired length of time.
To configure the time period for which metrics data is persisted
Edit the following file:
ORACLE_HOME/owsm/config/coreman/monitor-config-installer.properties
Change the value for the monitor.aggregator.measurementStore.WindowSize parameter.
The number specified is the length of time, in minutes, that the Oracle WSM Database retains metric data.
Redeploy the application by using the wsmadmin deploy monitor command.
