JaxView includes different types of monitors. They are organized into five categories according to the type of measurement that they provide. The following table is a summary of the monitor categories, the names of the monitors in that category and a general description of the use and metrics provided.
|
Category |
Monitor Types |
Description |
|---|---|---|
|
Performance Management Monitors |
These monitor intermediaries measure the performance of a Web service. They generate metrics such as round trip time and message sizes |
|
|
Fault Management Monitors |
These monitors are for measuring the fault rate and total fault count for a Web service. They can also monitor fault types |
|
|
Client Metering Monitors |
These monitors are designed for measuring client usage of a web service. They also generate metrics around the number faults generated by the client usage and unauthorized attacks on the web service. |
|
|
Active Monitors |
Active monitors send a synthetic request to a Web service, on a schedule, and waits for a response. The user can then set a threshold on the round trip time and the value of the response from the Web service. |
|
|
J2EE Monitors |
These monitors will measure J2EE related metrics such as JTA Stats or J2EE server container logs. |
The following sections describe the JaxView monitor configuration settings that you use to create or edit monitors in JaxView.
Note: The object assignment model used in JaxView is designed to make management of multiple services and monitors easy. It can, however, lead to some confusion. A single JaxView monitor configuration definition can be assigned to multiple service operations in the environment. After this assignment all instances of that definition continue to be linked via the definition in the Monitors tab. Any changes made to a single instance of that monitor will be made to all instances that use the same definition. See the section Object Assignment in JaxView for more information.
This monitor allows the user to monitor the contents of a message body and header for both request and response. This monitor is important for monitoring business activity of a Web service. The following are the metrics available from these monitors:
|
Metric |
Description |
|---|---|
|
Pattern Match Value |
This metric will allow the user to measure any part of the content of the message including the header using regular expression. See the section JaxView Tools for examples of regular expression syntax. |
The following are the configuration properties common to the Message Content monitor type:
Use this section to configure optional measurement baseline calculations. This feature allows you to use statistical trending to dynamically set the event thresholds for the monitor based on other measurements taken during a previous interval. See the section Monitor Baselining in JaxView for more information.
Use this section to set the event thresholds for the monitor. The monitor status is set according to the threshold settings. See the Setting Monitor Thresholds section for more information about threshold settings.
The following is an example of hoe the Element Pattern setting can be used.
If the Element Pattern content match expression was
/Copyright (\d*)/
and the content returned to the monitor by the request included the string:
... Copyright 2005 by Managed Methods
then the match is made and the retained content match value would be:
2005.
This retained value can then be referenced in the Error Condition threshold using the form: Element Name: copyright date < 2004
In this case, if the content returned contains a value less than 2004, this monitor will report an error.
NOTE: XPath can also be used in the pattern field to find and match on values inside a SOAP XML message.. The expression will be of the form: XPATH:path/to/message/element
NOTE: Element pattern field can be left blank for this monitor. If the field is left blank then JaxView will search for the text result of the message and will set Pattern Match Value to it. For example if the response of a message contains the following
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns0="urn:Foo" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance>"> <env:Body> <ns0:test3Response> <result xsi:type="xsd:string"> 25 </result> </ns0:test3Response> </env:Body> </env:Envelope>
And the Element Pattern field is set to blank, then the Pattern Match Value will be set to 25. So if the Error Condition threshold for this monitor was Error if Pattern Match Value > 24 then the monitor will be in error.
This monitor generates metrics about the size of the request and response message. The following are the metrics available from these monitors:
|
Metric |
Description |
|---|---|
|
Message Request Size (bytes) |
This metric measures the size of the request message in bytes. |
|
Message Response Size (bytes) |
This metric measures the size of the response message in bytes. |
The following are the configuration properties common to the Message Size monitor type:
Use this section to configure optional measurement baseline calculations. This feature allows you to use statistical trending to dynamically set the event thresholds for the monitor based on other measurements taken during a previous interval. See the section Monitor Baselining in JaxView for more information.
Use this section to set the event thresholds for the monitor. The monitor status is set according to the threshold settings. See the Setting Monitor Thresholds section for more information about threshold settings.
Performance monitor measures the time for a request to be processed by a Web service operation. The following are the metrics available from these monitors:
|
Metric |
Description |
|---|---|
|
Response Time (msec) |
The difference in time from when request is seen to when the response is seen: (RequestTime – ResponseTime) |
The following are the configuration properties common to the Performance monitor types:
Use this section to configure optional measurement baseline calculations. This feature allows you to use statistical trending to dynamically set the event thresholds for the monitor based on other measurements taken during a previous interval. See the section Monitor Baselining in JaxView for more information.
Use this section to set the event thresholds for the monitor. The monitor status is set according to the threshold settings. See the Setting Monitor Thresholds section for more information about threshold settings.
This monitor will measure the total usage rate or throughput of a Web service operation. The total usage rate is measured by JaxView checking to see at what rate messages have been entering the system for this particular operation. The monitor checks on a set interval that is configured in the Monitor Settings. The following are the metrics available from these monitors:
|
Metric |
Description |
|---|---|
|
Usage Rate/Hour |
This metric measures the throughput and the usage rate of the Web service operation from All clients. |
|
Total Usage |
To get total usage of a certain Web service operation, you need to create a report for this monitor type by right clicking on the operation node in the Service Tree under messages tab. |
The following are the configuration properties common to the Total Usage Rate monitor type:
Use this section to configure optional measurement baseline calculations. This feature allows you to use statistical trending to dynamically set the event thresholds for the monitor based on other measurements taken during a previous interval. See the section Monitor Baselining in JaxView for more information.
Threshold Settings
Use this section to set the event thresholds for the monitor. The monitor status is set according to the threshold settings. See the Setting Monitor Thresholds section for more information about threshold settings.
This monitor will allow the user to monitor the contents of a message that contains faults. The user will select which part of the fault segment in the message to monitor. This includes Fault String, Fault Code, Fault Actor. Then the user will create a regular expression to match on the value of these elements.
Use this section to set the event thresholds for the monitor. The monitor status is set according to the threshold settings. See the Setting Monitor Thresholds section for more information about threshold settings.
The following is an exmaple of how to use the the Fault Content monitor for matching message content.
If the fault string is:
JAXRPCTIE01: caught exception while handling request: deserialization error: XML reader error: unexpected character content: "buzz"
you can use .* unexpected character content.* in the pattern field to match on this string.
The default thresholds for this monitor are that if the pattern 'matched' the monitor will report an error condition. The Pattern Match has to always be set to 'matched'. If you want to reverse the condition you can set it as follows
error if Pattern Match != 'matched'
good if Pattern Match == 'matched'
NOTE: XPath can also be used in the pattern field. The format will be XPATH:xpath string.
This monitor will monitor the percentage of faults generated from requests. The monitor will look at the number of messages received for the last 3 hours and measure the percentage of the messages that generated the fault. Then a threshold is set on that percentage. There needs to be a steady state reached before the numbers are meaningful. For example if the monitor is just added and the first message is a fault then the percentage is %100, which could be meaningless. It is recommended that you let the monitor run for a minimum of 3 hours or record at least 100 messages before assigning a event notification rule and alert to it. The following are the metrics available from these monitors:
|
Metric |
Description |
|---|---|
|
Fault Usage Rate/Hour |
This metric measures fault percentage of the total request into the operation. |
The following are the configuration properties common to the Fault Percentage monitor type:
Use this section to set the event thresholds for the monitor. The monitor status is set according to the threshold settings. See the Setting Monitor Thresholds section for more information about threshold settings.
This monitor will monitor the rate that faults get generated by a Web service operation. JaxView runs this monitor type on a frequency interval set in the Monitor Settings and checks the fault rate for the assigned operation. When performing reporting on the this monitor it will also show the total number of faults over a time period in the summary table. The following are the metrics available from these monitors:
|
Metric |
Description |
|---|---|
|
Fault Usage Rate/Hour |
This metric measures the number of faults generated by a Web service operation from all clients. |
|
Total Faults |
To get total faults generated by a Web service operation, you need to create a report for this monitor type by right clicking on the operation node in the Service Tree under messages tab. |
The following are the configuration properties common to the Fault Rate monitor type:
Use this section to configure optional measurement baseline calculations. This feature allows you to use statistical trending to dynamically set the event thresholds for the monitor based on other measurements taken during a previous interval. See the section Monitor Baselining in JaxView for more information.
Use this section to set the event thresholds for the monitor. The monitor status is set according to the threshold settings. See the Setting Monitor Thresholds section for more information about threshold settings.
This monitor is used to scan through any error log created by JaxView for a service and look for types of log entries. If JaxView is used as a service gateway or proxy, it will create a service error log to record any errors in communicating with proxied Web services. The contents of the service error log can be viewed using the Errors sub panel in the Services tab. You can use the Service Error Monitor to automatically scan the service error log for specific entries and then assign rules and alerts to the monitor to be notified if errors occur.
Use this section to set the event thresholds for the monitor. The monitor status is set according to the threshold settings. See the Setting Monitor Thresholds section for more information about threshold settings.
This monitor will measure the usage of a Web service operation from a certain client. The metrics gathered are client usage rate per hour. The following are the metrics available from these monitors:
|
Metric |
Description |
|---|---|
|
Client Usage Rate/Hour |
This metric measures the throughput and the usage rate of the Web service operation from One Specific clients. |
|
Total Client Usage |
To get total usage of a certain Web service operation by a client, you need to create a report for this monitor type by right clicking on the operation node in the Service Tree under messages tab. |
The following are the configuration properties common to the Client Usage Rate monitor type:
Use this section to set the event thresholds for the monitor. The monitor status is set according to the threshold settings. See the Setting Monitor Thresholds section for more information about threshold settings.
This will monitor a Web service operation for unauthorized access. This requires that requests to the service include client information.
Use this section to set the event thresholds for the monitor. The monitor status is set according to the threshold settings. See the Setting Monitor Thresholds section for more information about threshold settings.
This module allows for active monitoring of a Web service. It does that by creating a synthetic message, sends it to the Web service, and waits for a response. It performs this on a schedule, for example, every 5 minutes. The user can then set a threshold on both the result of the response and the round trip time. This essentially actively monitors the performance of a SOAP Web service. The following are the metrics available from these monitors:
|
Metric |
Description |
|---|---|
|
Response Time (msec) |
This metric is the response time of a metric when measured from a specific client. |
|
Response Value |
When the request is made the response value of the Web service operation can be monitored. For example, if the operation measure reponds with the stock price, a threshold can be set on that price to trigger and alert. |
The following are the configuration properties common to the Heartbeat monitor type:
Use this section to configure optional measurement baseline calculations. This feature allows you to use statistical trending to dynamically set the event thresholds for the monitor based on other measurements taken during a previous interval. See the section Monitor Baselining in JaxView for more information.
Use this section to set the event thresholds for the monitor. The monitor status is set according to the threshold settings. See the Setting Monitor Thresholds section for more information about threshold settings.
This is a basically a URL monitor. It sends a request to a specific URL and waits for a response on a schedule. This type of URL monitoring is suitable for REST type services.
Use this section to configure optional measurement baseline calculations. This feature allows you to use statistical trending to dynamically set the event thresholds for the monitor based on other measurements taken during a previous interval. See the section Monitor Baselining in JaxView for more information.
Use this section to set the event thresholds for the monitor. The monitor status is set according to the threshold settings. See the Setting Monitor Thresholds section for more information about threshold settings.
This is a composite monitor whose status is dependant on the status of all of the monitors included. When this monitor runs it checks for all of the runs of the monitors included since the last time it ran and it generates its metrics. For example if this monitor includes 2 other monitors and it runs every 10 minutes. It will check all of the runs of the 2 monitors in the last 10 minutes and generate the metrics needed. The metrics generated include
percent in error: The percent of all of the generated monitor results that were in error
items in error: The number of all of the generasted monitor results that were in error
percent in warning: The percent of all of the generated monitor results that were in warning
items in warning: The number of all of the generasted monitor results that were in warning
percent in good: The percent of all of the generated monitor results that were in good
items in good: The number of all of the generasted monitor results that were in good
Use this section to select the monitors to be included in this monitor
Use this section to configure optional measurement baseline calculations. This feature allows you to use statistical trending to dynamically set the event thresholds for the monitor based on other measurements taken during a previous interval. See the section Monitor Baselining in JaxView for more information. The base line property for this monitor is percent in error
Use this section to set the event thresholds for the monitor. The monitor status is set according to the threshold settings. See the Setting Monitor Thresholds section for more information about threshold settings.
This Monitor will actively gather JTA Stats metrics from a J2EE container. It performs this task by creating a RMI connection to the J2EE container. It performs this on a schedule, for example, every 5 minutes. The following are the metrics available from these monitors:
|
Metric |
Description |
|---|---|
|
Total Commits |
This metric is the total number of transaction commits. |
|
Total Rollbacks |
This metric is the total number of transaction rollbacks. |
|
Total Transactions |
This metric is the total number of active transactions within the container |
The following are the configuration properties common to the JTA monitor type:
Use this section to set the event thresholds for the monitor. The monitor status is set according to the threshold settings. See the Setting Monitor Thresholds section for more information about threshold settings.
This Monitor will monitor the server log for the selected J2EE container. It actively on a schedule reads a chunk of the log and looks for regular expression pattern matches in that chunk.
Use this section to set the event thresholds for the monitor. The monitor status is set according to the threshold settings. See the Setting Monitor Thresholds section for more information about threshold settings.
For example, if the fault string is JAXRPCTIE01: caught exception while handling request: deserialization error: XML reader error: unexpected character content: "buzz"
you can use .* unexpected character content.* in the pattern field to match on this string.
The default Error Condition thresholds for this monitor are that if the pattern 'matched' that would be an error condition. The Pattern Match has to always be set to 'matched'. So if one wanted to reverse the condition they would set as follows
error if Pattern Match != 'matched'
good if Pattern Match == 'matched'
Setting event thresholds for monitors in JaxView is fundamental to efficient monitoring and SOA management. The monitor threshold is used to determine what are acceptable performance and content values and what values should be considered an event that requires notification and action.
You select the threshold metric you're interested in in the first drop down, then set a qualifier (for example > or >=) and then a value. The value could be a number or a string.
Note: If using a string then it needs to be wrapped in single quotation 'value'. Also the units for most performance related metrics are in milliseconds.
Some monitors have default thresholds for certain metrics. These are labeled with the text '(default)' in the threshold drop down list. If you do not explicitly set your own threshold settings the monitor will automatically use the default threshold for that specific monitor. It is recommended that you set your own thresholds for most metrics.