Everything about Web and Network Monitoring

The Application Performance Monitoring Primer (Part 1 of 3)

tortoise

 Application Management (AM) includes project management, development, testing, quality assurance, release management, application monitoring, and responding to the information supplied by monitors.  Application Performance Monitoring (APM) is application monitoring that is focused on performance rather than security, availability, planning, or some other matter.

This article is part one of a primer for those who have never heard about APM.  Since APM is quickly establishing itself as a monitoring framework, forward-thinking clients and system owners will no doubt be asking questions about it in the near future.  This article will prepare you to answer the more basic questions.

System Monitoring vs. Application Monitoring

System monitoring focuses on the systemic infrastructure that supports applications.  It keeps an eye on resources that are shared by all applications, such as hardware, system software, and networks.  Application monitoring focuses on the applications.  It keeps an eye on individual user transactions from an application viewpoint.

System owners, clients, and senior management are showing interest in APM because they recognize that computing resources exist for the purpose of running applications and applications exist for the purpose of providing services to people.  While monitoring the first link in the chain (the infrastructure) is a good thing, they also see the need to monitor the final link in the chain (the users’ experiences with the application).

APM also offers technical benefits.  Sysadmins already know that monitoring anything and everything gives them the best chance of finding emerging problems before they become in-your-face problems that generate support calls.  Since a problem can have its genesis anywhere, monitoring anything and everything gives us the earliest possible notification, which gives us more time to respond.  However, due to the scarcity of resources and the fact that monitoring adds its own load, “anything and everything” is not feasible.  Sysadmins must decide what is most likely to provide the earliest warning.

Adding application performance monitoring to the “anything and everything” list gives the sysadmin more options.  In some cases, the earliest warning will come from within the application, and in some cases, the earliest warning will come from within the infrastucture.

The Application Transaction

At the core of application performance monitoring is the concept of the application transaction (also called the business transaction).  An application transaction is a sequence of user and system activities that are perceived by the user to be a logical unit of work.  When the user is interacting with a computer system, this is often perceived as a user request followed by a system response.  Performance is then judged by the user to be the length of time between issuing the request (e.g., clicking on the print button) and the ultimate completion of the processes that fulfill the request (e.g., the document is sent to the print server and the active window is once again available to the user).

The definition of an application transaction need not be as finely-grained as that.  For example, a user issuing a print request may see the beginning of the transaction as his supervisor’s request for the printout and the end of the transaction as the delivery of the printout to this supervisor.  This coarsely-grained transaction may include ceasing his current activity, getting to his computer, turning the computer on, starting the program, loading the document, issuing the print request, putting paper in the printer, waiting for the printout, calling a messenger service, waiting for the messenger to arrive, waiting for the messenger to deliver the printout, and waiting for the phone call from his supervisor to confirm receipt of the printout.

While this scenario helps us see that user perceptions, and therefore transactions, can be coarsely-grained as well as finely-grained, it is obvious that automated measurement of the above-described transaction cannot be easily implemented at this time.  This is why an application transaction is typically defined to include only the computer-involved aspects of the user’s transaction.  However, in general, monitoring both finely-grained and coarsely-grained transactions offers more benefits than monitoring only one.

The important point, of course, is that the transaction is defined by the user’s experience, not by the path the request takes through the system, and not by the technical resources required to fulfill the request.

References

Magic Quadrant for Application Performance Monitoring.  Gartner, Inc.  2010.02.18.

Paid Monitor Open API Overview.  Paid Monitor.

Paid Monitor Open API Documentation.  Paid Monitor.

Paid Monitor Transaction Monitoring Overview.  Paid Monitor.

Try Paid Monitor For Free.  A 15-day free trial.  Your opportunity to see how easy the Paid Monitor cloud-based monitoring system really is.  Credit card not required.

The Paid Monitor Exchange at GitHub.  This is the official repository for scripts, plugins, and SDKs that make it a breeze to use the Paid Monitor system to its full potential.

Post Tagged with

About Warren Gaebel

Warren wrote his first computer program in 1970 (yes, it was Fortran).  He earned his Bachelor of Arts degree from the University of Waterloo and his Bachelor of Computer Science degree at the University of Windsor.  After a few years at IBM, he worked on a Master of Mathematics (Computer Science) degree at the University of Waterloo.  He decided to stay home to take care of his newborn son rather than complete that degree.  That decision cost him his career, but he would gladly make the same decision again. Warren is now retired, but he finds it hard to do nothing, so he writes web performance articles for the Monitor.Us blog.  Life is good!