InnovationQ will be updated on Sunday, April 29, from 10am - noon ET. You may experience brief service interruptions during that time.
Browse Prior Art Database

Method and System of Autonomous Data Acquisition for Monitoring Web Application Topologies

IP.com Disclosure Number: IPCOM000022352D
Original Publication Date: 2004-Mar-10
Included in the Prior Art Database: 2004-Mar-10
Document File: 6 page(s) / 146K

Publishing Venue



A method is disclosed that provides a means to create a distributed and autonomous monitoring and data acquisition system that can be deployed independently of any downstream monitoring functions, such as data warehousing, analysis and reporting. The distributed method overcomes the drawback of tightly coupling the monitoring and data acquisition function to a central management process to avoid a single-point of failure. The method consists of lightweight and efficient data acquisition elements that autonomously monitor system infrastructure and transaction performance, and can be deployed on any or all of the servers of a web application topology.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 27% of the total text.

Page 1 of 6

Method and System of Autonomous Data Acquisition for Monitoring Web Application Topologies

A method is disclosed to monitor system infrastructure resources and transactions of web application topologies in a distributed and autonomous fashion. The method avoids the complexity and single-point-of-failure drawback of being tightly coupled to a central management monitoring process or console. It allows the data acquisition function to operate completely autonomous of any subsequent downstream monitoring functions such as data warehousing, analysis and reporting. The method consists of lightweight monitoring and data acquisition components that can be deployed on any or all servers of a web application topology. Lightweight means components consume little server resources (i.e., memory, CPU and network resources) and can be deployed quickly.

Figure 1 shows a view of the web processing system with the monitoring and data acquisition components (MDAC) deployed on the servers. Since the monitoring for the different types of servers will collect different metrics, the MDACs are customized and classified by the type of servers being monitored. For example, the MDAC monitoring the IP-Sprayer 1 is classified as an IP-MDAC 2 while for the web server it is classified as a WS-MDAC 3. The metrics defined for the IP-MDAC 2 would be oriented toward collecting data on total requests and sprayer resources, whereas the WS-MDAC 3 would collect more specific metrics regarding the requests, responses (e.g., web page details) and resources associated with a web server. In the web processing system of Figure 1, the other classes of MDAC depicted are AS-MDAC 4, MG-MDAC 5 and DB-MDAC 6 for application servers, messaging servers and database servers respectively. The concept of the MDAC can be extended to other server types as well.

1 Web Processing System

  IP Sprayer


 Web ApplicationServer(s)







Database Server(s)



Messaging Server(s)





 Web Browsers

Enterprise Information System

Figure 1. Deployment of MDACs


[This page contains 1 picture or other non-text object]

Page 2 of 6

Since MDACs are responsible for monitoring and acquiring data that relates to the overall performance of the web processing system, there are 2 major areas that need to be monitored. These are performance as affected by "server processing health" and performance as affected by "user response time".

Monitoring for "server processing health" requires continuous measurement of server processing status and resources that could affect performance. Examples of such processing/resource metrics for application servers are servlet requests/second, average servlet response time, number of active threads, amount of free JVM memory, etc. For a web server, different processing/resource metrics would be recorded such as total number of requests, number of active worker threads, status of server plug-ins, status of pro...