More than 10 products have been added to Optimize for Infrastructure v8.2, from tracking the number of transactions and commits for Adabas Transaction Manager to the number of RPC services checked in Natural SAF Security.
More than 200 new key performance indicators (KPIs) have also been added, including monitoring memory usage, conversations and worker queues in EntireX Broker as well as slots used in the Natural Roll Server.
One of the most important additions to Optimize for Infrastructure v8.2 is the ability to monitor an application's performance across multiple products and view the results on an interactive dashboard called MashZone Dashboarding. MashZone Dashboarding lets you bridge the gap between static tables, evaluations, rigid reports and the need for graphical, interactive, custom, easy-to-understand presentations.
Vertical vs. Horizontal Monitoring
Optimize for Infrastructure has long provided a single view of KPIs for multiple products, such as EntireX, Natural and Adabas. However, just like viewing these products’ individual diagnostic tools such as SMH and AOS, this only provides a vertical view into a specific product server’s performance. A vertical view of performance (i.e. response time of an Adabas DB, response time of a Natural Server, response time of an EntireX Broker) does not give a complete picture of an application’s performance.
Optimize for Infrastructure now offers a unique new feature called Application Monitoring. Application Monitoring combines all the performance information of an application as it operates across all supporting products from start to end. Take a web application, for example, Application Monitoring measures the resource usage of any single transaction as it traverses from the webserver through EntireX, Natural and Adabas. This end-to-end monitoring of an applications performance across all supporting products, as shown in Figure 1, is known as a horizontal approach to application monitoring
FIGURE 1: Monitoring Approaches
The challenge of monitoring response times of distributed applications is capturing the time spent by the components involved. For example, a company runs an application on the PC that makes an RPC request to trigger a program on a mainframe. In the client application, the overall response time spent for the call can be measured. However, time is not only spent for program execution, the transport (mainly from one machine to another) also consumes time. Additional time is used when the broker waits for a free server. Unfortunately, with such a distributed application various components are involved and the overall response time does not tell us how much time was used for each component.
Optimize for Infrastructure overcomes this challenge by introducing measurement points at the start and end of each component as shown in Figure 2. The time stamps before and after a database call are taken by the Natural nucleus and are therefore only available with a Natural RPC server. Additional time stamps are taken in the EntireX Broker before and after the wait for a free server.
FIGURE 2: Measuring response times by component
The ARIS MashZone transaction table, shown in Figure 3, lists the total response time, the time spent in each component involved and the time required for the transport. In addition, the KPIs are visualized in the bar chart. Any summarizing by time, application, service, user, etc. is also implemented. Real-time monitoring of response times of distributed applications is integrated in Optimize for Infrastructure with no additional charge!
FIGURE 3: Response Time KPIs
The new Application Monitoring from Optimize for Infrastructure tracks and displays the resource usage of any single transaction as it passes through EntireX, Natural and Adabas. EntireX RPC is the first application type implemented for end-to-end monitoring, with Natural for AJAX to soon follow.