MONITORING THE BUSINESS ASPECTS OF AN APPLICATION

Like with all complex problems, I will try to divide the problem in smaller and easier to handle pieces. My approach will be a top down approach, as this is the approach taken by the business.
  • Step 1: make your user or customer happy
  • Step 2: know your business throughput and results
  • Step 3: do not lose any business, but grow your business

Now, what does this have to do with application monitoring? Directly nothing, but as ICT professionals we need to deliver the context and monitoring for the applications that provide the capabilities required by the business. So, we need to translate the business requirements into technical requirements and act upon them.

  1. Make your user or customer happy. This translates into the term end-user experience and the technologies used for end-user experience monitoring. The user experience can be monitored at two places using different technologies. Both are complementary and should be one solution. The first is the web server or the access to the application. Webservers provide access and error logs that can be analyzed. For your packaged applications, we refer to the logging provided by the software vendor, if any. The access log gives you an insight in the requests coming from clients and the errors experienced by the users. They also deliver response times for each request that can be used to analyze the response times experienced on the client side. We use log monitoring tools to capture and provide the information and dashboards to present the information to the technical and business users. The technical users might be interested in the errors, the business users in the response times, the number of unique users … and corresponding SLAs if they have been defined. The second is synthetic transaction monitoring. This is a technical term that stands for monitoring for availability and response times. The difference with access monitoring is that with synthetic monitoring one or a few specific test scenarios can be monitored that indicate if the pages are available and what the average response time is. This can be monitored from one or more places on the Internet for web monitoring or from one or more PCs for thick client monitoring. The result is the availability of the application and the response time under normal circumstances.
  2. Know your business throughput and results. This translates into terms like transaction monitoring, application performance monitoring or application chain monitoring. In fact, what we want to do is to monitor the behavior of the application itself on a data and functional level. The only place we can do this is in the application itself. This means that the application needs to be instrumented to deliver the measurements required for monitoring. This can be done in two ways: non-intrusive, the application delivers the information to the monitoring in a structured format, like log files or streaming data to a time series database or even with the help of web services or APIs. The other way is by instrumenting the application from outside using tracing. Tracing is a technique whereby the application is instrumented to pass transaction trace data to the monitoring system. This instrumentation is added to key methods in the source code of the application or the framework in which the application runs. Tracing is only available for your inhouse developed applications. For packaged applications you need to rely on what the provider delivers, and most of the time these are logfiles with sometimes transactions, of course depending on the packaged application.
  3. Grow your business. This aspect becomes more and more important with the move to the cloud. Applications that run in the cloud should be able to grow or scale down in function of the business requirements or the number of users of the application. This is what I would call elastic resource management, which is similar to the use of water or electricity and is driven by a pay what you use model. This capacity management needs monitoring of either the number of active users or the resources taken up by the application and should automatically scale the application resources accordingly. This might seem new at this moment but it will certainly become mainstream in the near future.

MONITORING THE TECHNICAL ASPECTS OF AN APPLICATION

As the above defines the business aspects of monitoring, we still need to dive into the technical aspects of application monitoring. What do we need to monitor from a technical point of view?
  • The infrastructure
  • The framework or the footprint of the application on the system
  • The application itself

Infrastructure monitoring is well known, but we see a shift from traditional infrastructure to the cloud, where resource monitoring is required to validate the use of resources used by the application and the delivery of those by the cloud provider. So, infrastructure monitoring will not go away anytime soon. Now, what do we want to know from an application perspective? We want to know the health and performance of the underlying infrastructure, and this linked to the resources that the application is using.

This is easier said than done and requires a thorough mapping of the application to all the resources that it uses. In fact, what we need is cross domain monitoring and mapping. But most infrastructure monitoring tools do not have these cross-domain capabilities …

Framework monitoring or stack monitoring. This refers to the application framework in which the application is running and the resources used by the application within this framework. Together with application monitoring, most tool providers call this full stack monitoring. This is true if you consider the application framework stack, without the underlying infrastructure. The goal of this kind of monitoring is to provide an insight in the resources that the application is using and the health of the environment in which the application runs. This is certainly required in environments where multiple applications or application instances run on the same frameworks’ server or in the cloud. This kind of monitoring also provides the baseline for the elasticity of the resources.

Technical application monitoring is linked to the business monitoring, but not always completely. Some aspects of the application resort under technical monitoring such as the monitoring of the services or processes on the server … These aspects are mainly monitored for packaged applications and deliver the monitoring of the application as seen from the perspective of the Operating System.

CONCLUSION

Business aspects of the application are monitored from the application itself, whereas the technical aspects are monitored in the environment in which the application is running. This is completely true for full stack monitoring where you run your own developed applications in an application framework. This is a totally different matter for packaged applications, where you depend on what the provider is delivering. In both cases you need to monitor the underlying resources and there, ‘full stack’ might be confusing, as it means the framework stack and not the infrastructure stack!

Application tracing delivers you the most complete information required to follow the business, which might be ok for developers, but might be too much detail for operations. Operations is not interested in the transaction by transaction performance but is interested in the health and performance of the application. So, a tradeoff between development and operations is a fundamental requirement, which also points in the direction of DevOps.

So, all in all, application monitoring is a vast domain of monitoring techniques provided for all aspects of your applications. Consider up front what you would like to achieve with application monitoring. A good choice of the techniques and technologies to use is a must before you start.