I promised that I would write about the complexity of modern applications and how that applies to your monitoring decisions. Consider this to be an initial dive into that subject. For many of you, this will be enough to get you going in the right direction and avoid making costly mistakes.
So, we understand how modern applications are split into display vs. data fetching and control calls. What does this mean in terms of one’s monitoring strategy? The first important step is to realize that there are two questions, not one:
- How well is my back-end supporting my UI?
- How efficiently is my UI supporting my end user’s experience?
The first question can be answered using standard monitoring methodologies – passive tapping, agents, etc. This deals with the most vexing issue of the Operations team – whether the current infrastructure investment is having a positive or negative effect on the end user. If each server interaction is free from availability and performance issues, then any problems with the end user experience will be the result of issues with the client-side display – i.e., it is not a data center issue. That is a critically important distinction to make for an Operations team.
In short, for public-facing applications, you are likely going to need to instrument the application. Keep in mind that modern applications work in terms of “application events” and not page views. An application event is a single interaction between the user and the application. It always starts with a user-initiated click on the UI and ends when the UI is ready for another interaction. The intervening gap can be filled with all kinds of activity, both on the client side as well as the server side, and it is all part of that application event. You can see how the instrumentation points for an event can vary enormously from one application to another, or even within the same application. Consequently, it is extremely hard to automate this kind of monitoring. Applications simply do not follow enough standards yet to allow for consistent automation. However, automated instrumentation is often suggested by tool vendors without discussing the risks or deficiencies.
To avoid suffering negative consequences from automated instrumentation, such as performance slowdowns or even breakage, you should strongly consider having the developers inject the instrumentation themselves as part of a larger culture of “Design for Monitoring” – a discipline that is sorely lacking in software development (and the subject of another blog entry in the future). Although there is a growing tide of libraries to help with instrumentation-based monitoring of web applications (e.g., Boomerang, Jiffy, etc), they are mostly focused on automating the instrumentation of page views. I have not seen any that are very effective at finding and defining application events. Hopefully, that will change in the near future. Browser vendors are once again in the best position to address this, since they can easily determine the two end points of any application event. I hope to see them step up. In the meantime, make sure that your tool set provides you with the ability to address this need in some fashion.