Line of Business Application Monitoring

Best Practices for EnsuringApplication Availability and Reliability

Document Version 1.07©2007 AVIcode, Inc. All rights reserved. AVIcode, Intercept Studio, and AVIcode Application Health Modeling and Monitoringare trademarks or registered trademarks of AVIcode, Inc. All other trademarks are the property of their respective owners.This document shall not be duplicated or used for any purposes other than that for which it is being provided. For permission to re-use or reprint, contact AVIcode at 443-543-0030 orinfo@avicode.com.

Monitoring Line of Business Applications

Introduction

Typically, organizations select a monitoring solution for their line of businessapplications based on feedback from a few individuals charged with evaluating products.This process is not perfect since the few individual evaluators may not adequatelyrepresent the total population of users or those who will benefit from the monitoringsolution. For example, if the evaluators are from Operations, their requirements may be toselect a solution that will notify them of impending system problems. On the other hand,evaluators from Development will be more likely to select a solution that providesdetailed diagnostic information about unexpected problems in their code.The question remains: what is the best monitoring approach for ensuring your line of business application achieves optimal performance and uptime?

Application Problems Defined

Before answering this question, we should define application problems as any issue thatcauses an application to deviate from its intended design – whether the issue is related tosystem failures like network or operating system errors, or application failures in which arequired task cannot be executed.In addition, problems are categorized as

expected

unexpected

. Expected problemsare those which have been planned and coded for during the design phase, or for whichworkarounds have been identified during the QA phase. Expected issues generally avoidcatastrophic failures by providing enough information to enable an end user to respondappropriately in order to remedy the problem. A common expected problem is a “Printerout of paper” error. This failure does not cause the text editor to stop working; rather, adeveloper has specifically anticipated the potential for this error to occur and has writtencode to appropriately handle it. The error message provides enough information for theend user to resolve the problem.While expected problems are typically well structured and correspond to unsuccessfuluse-case scenarios, unexpected problems have no clear context and do not result from aset pattern of user behavior. For example, when an application leaks memory, iteventually fails with an “Out of memory” error. The only thing a developer can do underthis circumstance is to make the code fail gracefully with a “Server unavailable”message, and to try to collect as much information as possible for later analysis.Typically, unexpected or unhandled problems are the most time consuming andcomplicated to track down and resolve, and thus the most costly to a business.

Monitoring Line of Business Applications

Always-On Monitoring

Because approximately 80% of applications will fail at some point – due to expected orunexpected errors – it is critical to monitor line of business applications in an

always-on

state. That is, a monitoring solution must constantly look for application problems andprovide actionable alerts in real-time when errors are detected. This will ensure optimalapplication availability and reliability.Always-on application monitoring can be either

reactive

proactive

. Reactivemonitoring detects an error at the moment of failure and collects information at that timein order to effect resolution. Reactive monitoring alerts an organization that a user isexperiencing a problem, but does not provide advanced notice of an issue before itoccurs.Unexpected problems are always detected via reactive monitoring and requireinformation to be gathered for accurate analysis and diagnosis. For example, anapplication that is missing data in a particular database table will fail each time it tries toaccess or manipulate that information. For effective reactive monitoring, adequateinformation must be collected at the time of failure to diagnose the root cause of theproblem and influence action to resolve it.Reactive monitoring may also provide insight into expected errors. For example, while anapplication may cleanly handle and report problems writing to the hard drive, if the errorresults from a bad disk sector (as opposed to low disk space), the application may beunable to notify the user of reasonable corrective actions to take. In this case, theapplication needs to provide enough information about the error to diagnose it after thefact.While some expected errors are unpredictable, others can be anticipated before they everbecome a problem for end users. For example, proactively monitoring disk space couldavoid application write failures when inserting new data into a database. There aremultiple techniques to facilitate proactive monitoring. For instance, you can test/exercisecritical functionality with synthetic transactions and detect failures before the end userdoes. Another technique is monitoring performance counters to analyzeperformance/capacity requirements and predict insufficient resources before they impactyour business.

An effective monitoring solution for line of business applications is based on analways-on approach that combines reactive and proactive techniques to detect bothexpected and unexpected failures.