Introduction to Application Monitoring

This document introduces Application Monitoring in EntireX and describes common scenarios that use this feature. It covers the following topics:


Scope

Application Monitoring is an EntireX feature that enables you to monitor the response times in your distributed applications, and it also enables you to monitor certain error situations. The heart of Application Monitoring is the EntireX Application Monitoring Data Collector, which collects the response time data of each involved software component of selected synchronous EntireX RPC services. The Application Monitoring Data Collector stores the KPI values in CSV (comma-separated values) files. The files can be processed by any third-party tool that supports CSV files, for example Microsoft Excel. Alternatively, you can hook in your own monitoring back end, using the callback user exit of the Data Collector.

When Application Monitoring is enabled, each call to the service by a client application is monitored. You can measure

  • overall service response times

  • network transport times

  • EntireX Broker processing

  • waiting times

  • RPC server processing times

You can also measure

  • time spent for database calls (if Natural and mainframe Adabas are installed on the back end)

  • time spent for DB2 calls (if applicable and depending on the platform)

Each Software AG enterprise product involved concatenates the monitored time(s) with the service call. When the call returns to the client, the client RPC runtime provides the event data to the Application Monitoring Data Collector.

Scenarios with webMethods Integration Server

For webMethods Integration Server scenarios, the Application Monitoring Data Collector is available inside the Integration Server. This section describes the following scenarios:

REST Client or IS Service Calls RPC Server

In this scenario, REST clients call into an RPC server via an IS service: inbound calls from the viewpoint of the webMethods Integration Server, or RPC server. The following diagram shows the KPI measuring points and flow when a REST client or IS service calls an RPC server.

graphics/appMon_is_rpc2rest.png

The KPI measuring points comprise the Integration Server and the RPC server.

REST Client or IS Service Calls CICS IPIC, CICS ECI, IMS Connect or AS/400

In this scenario, REST clients call into the back end (CICS, IMS or AS/400) via an IS service: inbound calls from the viewpoint of the webMethods Integration Server, or back end. The following diagram shows the KPI measuring points and flow when a REST client or IS service calls the back end using a CICS IPIC, CICS ECI, IMS Connect or AS/400 Connection.

You can monitor the sum of the transport time to CICS IPIC, CICS ECI, IMS Connect or AS/400 plus the time spent in the CICS transaction, IMS transaction or AS/400 program.

graphics/appMon_is_ipic-eci-imco-as42rest.png

The KPI measuring points comprise the Integration Server.

REST Client or IS Service Calls CICS Socket Listener

graphics/appMon_is_ciso2rest.png

The KPI measuring points comprise the Integration Server and Socket Listener.

RPC Client calls IS Service or REST API

This scenario illustrates the opposite direction: outbound calls of an RPC client calling a REST service via an IS service. The following diagram shows the KPI measuring points and flow when an RPC client calls a webMethods IS service or REST API.

graphics/appMon_is_rest2rpc.png

The KPI measuring points comprise the RPC client and Integration Server.

Scenarios with EntireX Broker

There are also scenarios that do not use webMethods Integration Server, for example calls to/from web services or another RPC client through RPC server communication. Where EntireX Broker is the communication hub, the Application Monitoring Data Collector runs as a separate standalone component, often called the External Application Monitoring Data Collector.

graphics/appMon_broker.png

RPC clients support Application Monitoring without additional configuration, including the EntireX Adapter with an EntireX RPC connection, which is technically an RPC client. So does an RPC server, including the EntireX Adapter with an EntireX RPC Listener connection, which is technically an RPC server.

Processing KPI Data with EntireX Adapter

You can process your KPI data using the Application Monitoring Data Collector or an Integration Server service:

Processing KPI Data with CSV Files

The Application Monitoring Data Collector collects the response time data of each involved software component of selected synchronous EntireX RPC services and stores the KPI (key performance indicator) values in CSV (comma-separated values) files. The files can be processed by any third-party tool that supports CSV files. For webMethods Integration Server scenarios, the Data Collector is available inside the EntireX Adapter.

See Application Monitoring in the EntireX Adapter documentation for configuration details.

Processing KPI Data with Integration Server Service

As an alternative to storing the KPIs in CSV files, you can invoke an IS service. The monitoring KPIs can be consumed by an Integration Server service, and the monitoring data can be further processed.

Processing KPI Data with External Application Monitoring Data Collector

The External Data Collector runs as a pre-started service controlled by a daemon, for example the cron daemon in a Linux system, or a Windows service under the Windows operating system.

For more information see Setting up the External Application Monitoring Data Collector under Setting up Application Monitoring.

With the External Application Monitoring Data Collector you can process your KPIs with any tool that supports CSV files or you can use the callback user exit of the External Data Collector:

Processing KPI Data with CSV Files

The External Application Monitoring Data Collector collects the response time data of each involved software component of selected synchronous EntireX RPC services and stores the KPI (key performance indicator) values in CSV (comma-separated values) files. The files can be processed by any third-party tool that supports CSV files.

Processing KPI Data with Callback User Exit

As an alternative to storing the KPIs in CSV files, you can use the callback user exit of the External Application Monitoring Data Collector. Use this approach if you want to feed arbitrary monitoring back ends in real time.

Start of instruction setTo use the callback user exit

  1. Write a Java class that implements the DataCollectorCallback interface.

  2. Make it known to the External Application Monitoring Data Collector.

For more information see Callback User Exit under Setting up Application Monitoring.