...building hybrid clouds that can support any device from anywhere
In part 1 of this 3 part series we discussed the reasons why we monitor and we talked about the different types of monitoring we can use. In this blog post we'll dig deeper into the Synthetic monitoring styles and more importantly when and where to use them. The purpose of this series and especially this blog post is not to show or map the best practices of any one type of monitoring but to show some different ways of thinking about monitoring applications, especially custom line of business applications. This blog post should simply show there are options and features available that can bring benefit in many ways, some you may have never imagined.
In the past and even still today this synthetic monitoring has been referred to as End User monitoring. I would even suggest for the most part, incorrectly. It gets this reference since its design is to simulate how end users use the application and in some cases simulate a transaction through the application. I say this is not end user monitoring since you are not monitoring the end user. We'll discuss real end user health monitoring in part 3, but as I will hopefully show a synthetic view of the applications response to a request still has value. I also do not limit them to only web application requests since we have other types of synthetic transactions, for example a SQL Select statement on a regular cycle from a node or nodes in the environment can confirm SQL responds as you would expect.
Figure 1 ( Synthetic requests in red )
In figure 1 above we are showing that there can be many use cases of synthetic monitoring. For example a GET request to http://<my web server >/ will show the site is available which includes the network devices in between the management server node and the web site server. If the response is slow or not at all have we then understood availability from that node? But let's say I create 2 availability monitors, the "web" request as before and another one into the Middle Tiers web server like this: GET http://<my middle tiers url>/myservice.svc, if it is a .NET WCF service. An example result would be, if the UI doesn't respond but the service does then you narrow the problem and severity to the Front End server and or network between. In addition, with infrastructure monitoring and code level monitoring I can now rule in or out the server or server OS as part of the problem, so now we are triaging and to some degree diagnosing by way of monitoring.
Hopefully I've made you have some different thoughts around when to use synthetic transactions, which essentially is when do you want to understand the health of something. Maybe it's not as easy as that since not everything can be interacted with via an agent or request. Let's take a look at what I would call my top list of synthetic transactions, again keep in mind health includes performance and availability.
Web Application Availability Monitoring - GSM(Global Service Monitoring)
Web sites and web services - single
From local and remote
Visual Studio Web Test Monitoring - GSM(Global Service Monitoring)
Web sites and web services - multiple
Web Application Transaction Monitoring
Web sites and web services – recorded
OLE DB Data Source
TCP Port Monitor
TCP Port availability
Yes I included TCP Port Monitoring as a synthetic transactions type. Let's just call it a pseudo synthetic transaction monitor simply because its goal is the same, to give you a perspective of connectivity from dispersed nodes. In the next section we'll discuss more how to use each of these, but in general they are simply pieces of the 'ALERT -> TRIAGE -> RESOLVE' puzzle. Even though the first three are for Web Sites and web services they are fundamentally different in several ways. The first and most significant difference is from what perspective they are from. The first 2 will offer a perspective from your own internal nodes, just like the rest, but they also offer views from the MSFT GSM (Global Service Monitoring) nodes around the world. Let's briefly describe each.
We primarily focused on some of the synthetic tools to use so let's now focus on some use cases and how to use. As figure 1 is trying to show, there are many uses or ways of reading the alerts and reports that come from Synthetic monitoring. For this purpose I'll use a three tier web application I use often called DinnerNow. This application uses asynchronous calls to a middle tier wen service to populate drop downs with data and to respond to special requests like searching. Seems pretty straight for to create a web availability monitor for the user interface, right? Strangely enough for this application, if the web service is down the application will still respond to user interactions just fine. Here is what the home page looks like when the middle tier is broken. Look at the drop down menus for food item and meal type, see no data to select.
Image if you will that you also create a web availability monitor for the middle tier web service, which in this case responds to HTTP request similar to any web application. This is a better alerting mechanism but even better then alerting, it is the start of diagnosing the problem by telling us the service is not reponding in the middle as expected.
Now, in this example the user interface would respond even though data is not available. But also in this example the middle tier actually would respond correctly to the synthetic transactions because I simply took the database offline. The service is still available, it's just not working fully. The best method to understand the reason why would be to use .NET application monitoring of the .NET web service to understand why (we will detail more in Part 3), but what if it's not .NET. Well in that case the alert would be from our OLE DB monitor which would return the database is offline. Another way to expand the monitoring would be to include in the availability monitor all the different URLS and query strings that are important.
Hopes are this blog post simply spurs some additional thinking about monitoring applications but to some degree I hope it highlights that there are many ways to understand the health of an application if one doesn't fit use another. Now go forth and monitor…