This is a topic every customer I’ve been in touch with asked me about. The answer has changed three times so far:
- before October 2010, it has been: you can use synthetic transactions or if you app is .Net based such a cool product from Avicode… cool, but expensive and with a parallel though integrable architecture to be implemented
- after Avicode acquisition from Microsoft on October 2010, it has been: well you can use synthetic transactions or if you app is .Net based Avicode but you need to implement a few more components and deploy new agents
- today, the picture is changing once again and the answer is: you can still use synthetic transactions but with OM2012 you have almost all the Avicode power integrated in one single product and architecture for your .Net based web app. This new integrated feature is called Application Performance Monitoring (APM), today at the beta stages is limited to IIS 7 hosted .net applications.
Synthetic transaction have always been good, the web transactions monitoring is flexible enough and it’s not limited to .net application, it has its own caveats and scope, but we’ve been able to use it for a wide range of web application monitoring on almost every platform. What web transactions monitoring does is replay http(s) verbs. This way it can tell:
- the time it takes to get a complete answer (http answer)
- the url in your transaction that’s taking most of the time
- if your transaction is able to complete successfully (you can for example implement a complete shopping cart like transaction)
- the time the DNS resolution takes
- how much data is transferred through the network
Useful and powerful indeed, but it doesn’t tell you:
- which is the end user experience (web app synthetic transactions have no concept such as rendering or client side scripting)
- where your application is broken in case it’s unavailable
- where you’re spending time **inside** the application code
- what’s slow? The server, the network or the client?
A brand new world, isn’t it?
Web App synthetic transactions are good at availability and response time baselining, while they’re not measuring the user experience, they can give an indication if the application response time pattern has changed or if it is above given thresholds. This is good and useful and general purpose, but if you have .net applications you definitely want to implement APM.
Beware synthetic transactions and APM are different things, the former replays http verbs so even with no users interactions it monitors how the web app is performing, the latter is triggered by users interactions if the web app has no contacts then it won’t collect any data nor do any monitoring.
I strongly encourage you to give it a try, there’s a good step by step guide from Michael http://blogs.technet.com/b/momteam/archive/2011/07/30/operations-manager-and-application-monitoring.aspx
If you want to know more about the new integrated architecture take a look at this post by Daniele (http://blogs.technet.com/b/momteam/archive/2011/08/12/application-performance-monitoring-in-opsmgr-2012-beta.aspx), btw Daniele I completely missed you moved to the OM team: congratulations! (ben fatto!)
And, if you want to get to the meat here’s an example of what you can have with APM.
Let’s take a look at what happens when one request is served slowly (i.e. when the processing time surpasses the threshold set). The following is a typical alert that says SignIn.aspx is performing slowly (it took about 10 seconds) and that the culprit is a stored procedure called dbo.aspnet_Membership_GetPassword, not only it shows all the stored procedure parameters. Here it is, the issue is with the sql backend.
The alert above tells you the server story, but what happened client side? If you enable client monitoring you get the actual (I mean yes the real one) user experience with server, network and client side timings. If we take into exam the same issue above here is what we get:
As you can expect and see the server is the culprit, this way is super easy to point the finger in the right direction and even get to the line of code that’s causing issues.
And remember, if you developed your app in house there’ll be soon a Visual Studio connector that will help the internal developers to track down bugs, exceptions and performance issues. It was there, it was expensive, not it’s in the product. Just use it.
This posting is provided "AS IS" with no warranties, and confers no rights.