Version 9.6	SEARCH   CONTENTS   |   PDF BOOKS   |   HOME   UP   PREV   NEXT

CentraSite can receive run-time events and Key Performance Indicator (KPI) metrics. A run-time event is an event that occurs while services are actively deployed on the target. Examples of run-time events include:

• Successful or unsuccessful SOAP requests/responses.

• Policy violation events, which are generated upon violation of service’s run-time policy.

• Service monitoring events, which are generated by the service-monitoring actions in the run-time policy.

KPI metrics are used to monitor the run-time execution of virtual services. Metrics include the maximum response time, average response time, fault count, availability of virtual services, and more. If you include run-time monitoring actions in your run-time policies, the actions will monitor the KPI metrics for virtual services, and can send alerts to various destinations when user-specified performance conditions for a service are violated.

CentraSite provides predefined event types for use with any supported policy-enforcement point (PEP), such as webMethods Mediator. In addition, you can create custom event types.

The run-time event data are collected by the PEP and published to CentraSite via SNMP. The PEP publishes data for all run-time events for all instances of the PEP target.

You can view the run-time events and metrics on the CentraSite Control user interface. You can view them for all targets, for a particular target, or for a particular virtual service.

The following topics are discussed:

• The Run-Time Event Types

• The Key Performance Indicator (KPI) Metrics

• The Event Notification Destinations

• Destinations for the Monitoring and Transaction Events

• The Metrics Tracking Interval

• Configuring CentraSite to Receive Run-Time Events and Metrics

• Viewing Run-Time Events and Metrics

• Creating Custom Run-Time Events

• Modifying Run-Time Events

The Run-Time Event Types

The types of run-time events that Mediator can publish are as follows:

The Key Performance Indicator (KPI) Metrics

For the Monitoring event type, Mediator can publish the following types of KPI metrics:

Note:
By default, Average Response Time, Minimum Response Time and Maximum Response Time do not include metrics for failed invocations. You can include metrics for failed invocations by setting the pg.PgMetricsFormatter.includeFaults parameter to true. For more information, see the section Advanced Settings in the document Administering webMethods Mediator.

The Event Notification Destinations

Mediator can publish data about the run-time events and metrics to the following destinations:

• An SNMP server. You can use one or both of the following kinds of servers:

  • CentraSite's SNMP server, which uses SNMPv3 user-security model.

    For the procedure to configure Mediator to send SNMP traps to the CentraSite SNMP server, see the section SNMP Destinations for Run-Time Events in the document Administering webMethods Mediator.

  • A third-party SNMP server, which uses either the SNMPv1 community-based security model or the SNMPv3 user-based security model.

    For the procedure to configure Mediator to send SNMP traps to a third-party SNMP server, see the section SNMP Destinations for Run-Time Events in the document Administering webMethods Mediator.

• An EDA destination. Mediator can use EDA to publish run-time events and metrics to a database. Mediator uses a JDBC connection pool that you need to define in the Integration Server.

  For the procedure to configure Mediator to send this data to an EDA destination, see the section EDA Configuration for Publishing Run-Time Events and Metrics in the document Administering webMethods Mediator.

Destinations for the Monitoring and Transaction Events

For the Monitoring and Transaction event types, there are additional event notification destinations to choose from (in addition to the EDA and SNMP destinations).

Monitoring events are generated by the following run-time actions that you can configure for your virtual services in CentraSite:

• Monitor Service Performance.

• Monitor Service Level Agreement.

• Throttling Traffic Optimization.

Transaction events are generated by the run-time action Log Invocations.

The available destinations for Monitoring and Transaction events are:

• An EDA destination (a database).

• The CentraSite SNMP server or a third-party SNMP server.

• The virtual service's Events profile in CentraSite.

• An SMPT email server.

• Your Integration Server's local log.

• Your Integration Server's audit log (for Transaction events only).

You will select these destinations when you configure your virtual services in CentraSite.

These additional destinations for the monitoring and transaction events are described below.

• SMTP Email Servers

• The Integration Server's Local Log

• The Integration Server's Audit Log

SMTP Email Servers

To specify an SMTP email destination, you must:

• Select the "Email" option as a destination when you configure the run-time actions listed above.

• Set the "Email Configuration" parameters in Integration Server Administrator (go to Solutions > Mediator > Administration > Email) as described in the section SMTP Destinations for Alerts and Transaction Logging in the document Administering webMethods Mediator.

The Integration Server's Local Log

To specify the Integration Server's local log as a destination, you must:

• Select the "Local Log" option as a destination when you configure the run-time actions listed above. When configuring the actions, you must also specify the severity of the messages to be logged (the logging level).

• Set the Integration Server Administrator's logging level for Mediator to match the logging levels specified for the run-time actions (go to Settings > Logging > Server Logger). For example, if a "Log Invocation" action is set to the logging level of Error, you must also set Integration Server Administrator's logging level for Mediator to Error. If the action's logging level is set to a low level (Warning-level or Informationlevel), but Integration Server Administrator's logging level for Mediator is set to a higher level (Error-level), then only the higher-level messages are written to the log file.

  Entries posted to the local log are identified by a product code of MED.

The Integration Server's Audit Log

You can select the Integration Server Audit Log as a destination for the "Log Invocation" action only. If you expect a high volume of invocations in your system, it is recommended that you select the Audit Log destination. For more information, see the webMethods Audit Logging Guide.

The Metrics Tracking Interval

Mediator tracks performance metrics by intervals. The interval is a period of time you set in Mediator, during which metrics are collected for reporting to CentraSite. You set the interval in the Publish Interval field on the Mediator > Administration > CentraSite Communication page in the Integration Server Administrator. For details, see the section Configuring Communication with CentraSite in the document Administering webMethods Mediator.

Mediator only tracks metrics for the current interval. At the end of the interval, Mediator aggregates the metrics and reports them to CentraSite. Once the metrics are reported, Mediator resets its counters for the new interval. Mediator does not calculate and aggregate metrics across intervals. If Mediator is shut down or the virtual service is undeployed before the current interval expires, the performance data is discarded.

Note:
To avoid the need for Mediator to store metrics during periods of inactivity, Mediator stores only first and last zero value metrics that occurs during an interval, and discards the remaining consecutive zero value metrics. Doing this drastically reduces the storage space consumed by the metrics, and speeds the queries you perform in the dashboard. Skipping the in-between zero metrics will not affect in the performance graphs shown in the dashboard.

For more information about the metrics tracking interval, see the section Key Performance Indicator Metrics and Run-Time Event Notifications in the document Administering webMethods Mediator.

Configuring CentraSite to Receive Run-Time Events and Metrics

Prerequisites:

• Ensure that Mediator is configured for publishing events to an SNMP server, as described in the section SNMP Destinations for Run-Time Events in the document Administering webMethods Mediator.

• If you use a target type other than Mediator or webMethods Insight, be sure to configure CentraSite to publish events by providing your own MIB file in your target type's definition file, as described in the section Run-Time Targets. (CentraSite provides a MIB file for Mediator and Insight.)

• Optionally change CentraSite's default settings for logging run-time events, as described in the section Logging. By default, CentraSite logs all predefined event types, but you may disable any type.

CentraSite provides an Event Receiver, which is a data collector that collects the run-time event data. The Event Receiver listens for run-time events from the target instances via the SNMP (Application-Layer) protocol, and contains the logic to parse and store event data in the Event Receiver's data store. You must configure the Event Receiver's properties file as described below.

This section includes the following topics:

• Components of the Event Receiver

• Configuring the Event Receiver

• Event Type Modeling

• Event Modeling

Components of the Event Receiver

The Event Receiver contains the following components.

• The SNMP Listener

  CentraSite's SNMPv3 Trap Listener, which supports SNMP4J. This Listener starts automatically when CentraSite starts.

• The Intermediate Queue

  The queue from the SNMP Listener to the Event Processor. This queue decouples the SNMP Listener threads from the Event Processor to improve throughput. The following modes are supported.

  • FileSystem: Incoming Traps will be stored temporarily in the file system

  • InMemory: Incoming Traps will be stored temporarily in memory

  • NoQueue: Incoming Traps will not be stored in any intermediate queue; the SNMP Listener threads will be processed.

  To select the mode, set the eventsQueueImpl property as described in Setting the Events Queue Implementation Property.

• The Event Processor

  The Event Processor (SOALinkSNMPEventsListener) transforms incoming SNMPv3 Traps into an XML file (Events.xml) that complies with the schema in the RuntimeEvents Collection component. The Event Processor transforms an SNMPv3 Trap to the Events.xml file as follows:

  1. Determines the Event Type (and Target Type) to which the Trap belongs, and gets the corresponding UUIDs. This involves searching all Event Type-to-Trap mappings in all the defined target types, using the Trap’s OID. Since this is an expensive search, the Event Type-to-Trap mapping is cached to improve performance.

  2. Parses the Trap attributes and obtains: the Service (UUID); the Target (Name); the TimeStamp and the SessionId. The Processor then searches the registry/repository and obtains the corresponding UUID for the Target Name. This mapping is also cached to improve performance.

  3. Collects the remaining attributes from the Trap.

  4. Constructs the Events.xml file using the Event Type UUID, Target Type UUID, Service UUID, Target UUID, TimeStamp, SessionId and other collected attributes.

• The Batch Condition

  The Batch Condition is a set of OR conditions used by the Event Processor. The Event Processor supports two modes of event storage into CentraSite: BatchMode and NoBatchMode. BatchMode is available only for FileSystem and InMemory queues. When BatchMode is enabled, the Event Processor continues to accumulate Events.xml documents until one of the conditions is evaluated as true. Then it inserts all the documents as a single batch into CentraSite.

  To specify BatchMode or NoBatchMode, set the batch-related properties as described in Setting the Properties for FileSystem or InMemory.

• The RuntimeEvents Collection

  The run-time events are stored in the RuntimeEvents Collection as non-registry objects. For information about how events are stored, see Event Type Modeling.

Configuring the Event Receiver

The Event Receiver is bundled in the installation as a Web-Application named SOALinkSNMPEventsListener supporting the JavaEE standard. The configuration file for the Event Receiver is located here:

<CentraSite_directory>/cast/cswebapps/SOALinkSNMPEventsListener/WEB-INF/web.xml

The web.xml configuration file contains all the Event Receiver configuration properties. You must set these properties as described below, and then restart CentraSite.

• Setting the Database Configuration Properties
• Setting the SNMPv3 Transport Configuration Properties
• Setting the SNMPv3 USM Configuration Properties
• Setting the Events Queue Implementation Property
• Setting the Properties for FileSystem or InMemory

Setting the Database Configuration Properties

In the Event Receiver's configuration file, set the following properties related to the RuntimeEvents Collection database .

Setting the SNMPv3 Transport Configuration Properties

In the Event Receiver's configuration file, set the following properties related to a SNMPv3 Transport.

Setting the SNMPv3 USM Configuration Properties

In the Event Receiver's configuration file, set the following properties related to SNMPv3 USM.

Setting the Events Queue Implementation Property

In the Event Receiver's configuration file, set the following property related to the implementation of the events queue.

Setting the Properties for FileSystem or InMemory

When the eventsQueueImpl property is set to either FileSystem or InMemory, you should also set the following properties.

Event Type Modeling

Event types are modeled as registry objects. The String, Date, Integer and Boolean event attributes are stored in the registry/repository as slots. The File-Type attributes (representing payloads/binary-data) are stored as HasExternalLink associations.

For example, consider the predefined event type Transaction. If you go to the Target Type details page, you will see the Transaction event type attributes (which are obtained from the webMethodsESB.mib file) as follows:

All of these attributes (except the File-Type attributes RequestPayload and ResponsePayload) are stored as registry object slots, as follows:

The File-Type attributes ResponsePayload and RequestPayload are stored as HasExternalLink associations, as follows:

The "Target Type to Event Type Association" Object

A target type (represented as a concept) is associated with an event type (represented as a registry object) by a "Target Type to Event Type Association" object, which defines the "UUID to MIB OID" mapping.

The following table shows the contents of a sample object that associates the target type webMethods Mediator with the event type Transaction. The table's columns are described below.

• Attribute: The Attribute column is not part of the object; it is included here simply for your reference.

• Slot Key: Contains the UUID, which is obtained from the event type registry object.

• Slot Type: Contains the slot type, which is obtained from the event type registry object.

• Slot Value: Contains the event type attribute's Object Identifier (OID), which is obtained from the MIB file.

Event Modeling

An event is an instance of an event type. Events are modeled in a separate schema from the event type schema. CentraSite models events as non-registry objects (to avoid storing large amounts of unwanted event data in the registry/repository), and instead stores event data in a database collection within the Event Receiver. CentraSite maps events to their corresponding event types, using the event types' UUIDs. Similarly, events are mapped to target types, targets and services using UUIDs and the event type attributes.

The stored event data will contain:

• The event Trap ID (MIB OID).

• The event Trap value, which consists of:

  • The attribute key (MIB OID).

  • The attribute value.

The event data is stored in the Event Receiver as an "events" doctype.

If an event contains payloads (e.g., File-Type attributes such as ResponsePayload and RequestPayload), the payloads are stored in the Event Receiver as a "payloads" doctype, and will be referenced by the event stored under the "event" doctype, using ino:id. This is used to reduce de-serialization of the usually large payloads, and to improve performance of queries on the stored events.

Viewing Run-Time Events and Metrics

You can view the run-time events and metrics that occurred for:

• A particular target or all targets (see Viewing Run-Time Events and Metrics for Targets).

• Each virtual service (see Viewing Run-Time Events and Metrics for Virtual Services).

• Each API (see Viewing Run-Time Events and Metrics for APIs).

Viewing Run-Time Events and Metrics for Targets

Use the following procedure to view lists of run-time events for a particular target or for all targets.

If you are using the Mediator target, ensure that Mediator is configured to send event notifications to the destination(s) that are applicable for each event type. For details, see SNMP Destinations for Run-Time Events in the document Administering webMethods Mediator.

Note:
You must have the permissions to manage targets, as described in the section Run-Time Targets.

To view a list of run-time events for targets

1. In CentraSite Control, go to Operations > Events > Event List.

2. Use the following fields to filter the event list you want to view:

   In this field...	Specify...
   Target Type	The type of the target whose events you want to view.
   Target	The target whose events you want to view (or select All to view events of all targets).
   Event Type	A particular event type, or select All to view all event types. For descriptions of the predefined event types, see the The Run-Time Event Types.
   Service Type	Select All or Virtual Service. Note: CentraSite does not provide out-of-the-box policy-enforcement for web services.
   Date Range	A range of dates from which to view the events.
   Start Date	Alternatively, select the check box next to this field and click the calendar and select a starting date and time.
   End Date	Click the calendar and select an ending date and time.

3. Click the Search button.

4. The generated event list displays the following information:

   Field	Description
   Date/Time	The date/time that the event occurred. Click this hyperlinked value to view the Event Detail page, which will contain the event's SOAP request or response name in the Attribute column. Click the hyperlinked request or response name to display the full SOAP request or response.
   Session ID	(Read-only.) The session ID that generated the event.
   Event Type	(Read-only.) The type of event (e.g., Monitoring, Policy Violation, Error, etc.).
   Service Name	(Read-only.) The name of the service that caused the event.
   Service Type	(Read-only.) The service’s type.
   Target	(Read only.) The target on which the event occurred.
   Target Type	(Read only.) The type of the target on which the event occurred.

   Note:
   To view the list of attributes that are mapped for each event type, go to the target type's detail page (see the section Run-Time Targets).

Viewing Run-Time Events and Metrics for Virtual Services

You can view the events and metrics for a virtual service in its Events profile and its Performance profile. For details, see the section Virtual Services in CentraSite Control.

Viewing Run-Time Events and Metrics for APIs

You can view the events and metrics for an API in its Runtime Events profile and its Runtime Metrics profile. For details, see the section Virtual Services in CentraSite Control.

Creating Custom Run-Time Events

CentraSite provides the predefined event types described in The Run-Time Event Types. In addition, you can create custom run-time events that CentraSite will monitor.

Note:
Prerequisite: You must have the Manage Runtime Event Types permission. By default, the predefined roles CentraSite Administrator and Operations Administrator include this permission. For more information about roles and permissions, see the section Users, Groups, Roles, and Permissions.

Important:
To enable CentraSite to recognize custom event types, ensure that your MIB file (which is contained in your target type definition file) contains the SNMP Traps metadata and Object Identifiers for the custom events. For more information, see the section Run-Time Targets.

To create custom event types

1. In CentraSite Control, go to Operations > Events > Event Types to display the Event Types page.

   The page displays all the predefined event types (Monitoring, Policy Violation, Transaction, Error and Lifecycle) and any custom event types that have been defined.

2. To view the details of any event type, click its hyperlinked name.

   The list of attributes for the event type is displayed. You can edit the attributes of custom event types, but not the predefined event types (see Modifying Custom Run-Time Events).

3. To create a custom event type, click the Add Event Type button. In the Add/Edit Event Type page specify a name and description for the event type. Event type names can contain any character (including spaces), and are not case-sensitive.

4. In the Event Type Attribute panel, the following default attributes are displayed. These attributes are required and cannot be deleted.

   Attribute	Data Type
   TimeStamp	Date
   Target	String
   Service	String
   SessionID	String

   To create additional attributes, perform the following steps:

   1. Click the plus button at the bottom of the attribute list.

   2. Specify a name in the Name column and a value in the Data Type column (Boolean, File, Date, Integer or String). Attribute names can contain any character (including spaces).

   3. To add another attribute, click the plus button at the bottom of the list.

   4. To delete an attribute, click the minus button for the attribute you want to delete.

   5. Click Save.

Modifying Run-Time Events

To edit and delete custom event types, perform the following steps.

To modify a custom run-time event

1. In CentraSite Control, go to Operations > Events > Event Types to display the Event Types page.

   The page displays all event types that have been defined.

2. To delete a custom event type, select the check box next to the event type and click the Delete button.

3. To edit the attributes of a custom event type, perform the following steps:

   1. Click its hyperlinked name to display the Add/Edit Event Type page.

   2. You can change the value of an attribute’s data type, but not its name. Data types can be Boolean, File, Date, Integer or String.

   3. To add another attribute, use the plus button at the bottom of the list.

   4. To delete an attribute, click the minus button next to the attribute.

   5. Click Save.

www.softwareag.com

Copyright © 2005-2014 Software AG, Darmstadt, Germany.

SEARCH   CONTENTS   |   PDF BOOKS   |   HOME   UP   PREV   NEXT