John Quirk's Blog

Having taken a quick look at AVIcode yesterday, let’s take the gloves off and get a bit more hands on…

In this example we’ll be implementing AVIcode monitoring of a project management application ProLog. Sadly ProLog is something Orinoko developed themselves and the code quality leaves something to be desired. We have forced all staff to use this application for everything they do, so the Service Manager queue is building up!

In the Authoring Pane of the OpsMgr console I use the Add Monitoring Wizard to create a new Enterprise ASP.NET Application:

The wizard locates all the ASP apps on all of the servers I’m monitoring (this is an option in the AVIcode setup, if you wish you can limit discovery to certain machines).

The rest of this process is covered very well by Simon over on System Center Central here so I’ll skip on to what we get once it’s all up and running…

Each of our web pages gets its own dashboard under the Management Pack created for the .NET Application:

We also get a visual view of the application in a Distributed App:

I’m using the ProLog application to run a report of all the projects we’re working on currently.

I log in and select Reports – Overview

Nothing much happens, then eventually I receive a spurious error in Internet Explorer.

Over in OpsMgr I see data corresponding to this:

Behind the warning is significant data (still in the OpsMgr console):

You may notice that this is a Slowest Nodes alert showing that the page took 76672ms to render. 62626ms of this on the ReportExecution2005.asmx function. This is information I can then use to troubleshoot why this function of the application isn’t performing as it should.

Along with this data I get an excellent dashboard overview of application performance:

And if this isn’t enough, I can get deep into the code in the AVIcode Intercept Studio web console:

The top-level dashboard for each app collates relevant information for monitored processes. I can then drill into extraordinary detail around each transaction carried out against the application:

And drill deeper still into each individual event:

AVIcode is a massive product, with plenty of complexity and capability. Integrated with Operations Manager it provides the OpsMgr guys deep performance and alert knowledge on the performance of .NET applications and delivers even deeper intelligence for the .NET guys to optimise and troubleshoot poor performance and application failures all monitored in real-time. Great fun!

Here in the Orinoko ivory tower we’re too busy mixing our metaphors to let the grass grow under our feet. And so to AVIcode.

According to the product homepage “AVIcode delivers market-leading .NET application performance monitoring capabilities to help ensure the availability of business-critical applications and services, regardless of where they are deployed. End-user experience and application performance monitoring are critical in virtual datacenters and cloud environments…”

I couldn’t agree more. In case the marketing is a bit of a blur for you AVIcode does a number of very cool things:

1. It provides extraordinarily detailed and intelligent monitoring of web applications.
2. Jump-to-code debugging of .Net applications
3. Lots of graphs. Lots and lots of graphs.

All of this stuff is fully, and very elegantly, integrated into the Operations Manager console. To illustrate the concept, join me for a cocktail…

I am monitoring the OpsMgr Web Console to make sure that it’s always available for my busy admins. I have a good view of the health of the application from a datacentre and IIS perspective.

I do not, however, have any view of the end-user experience.

In the recent past, we would have provided an end-user perspective by deploying an OpsMgr agent to a machine outside of the datacentre and had it carry out a synthetic web session against the application. This works great, and can give us some really useful telemetry, but it’s still a little limited.

AVIcode provides a much more elegant solution to client-side monitoring by injecting some client-side code into page requests which then deliver telemetry data back to the monitoring infrastructure. This gives us real-time views of the performance of the application from the end-user’s perspective and can alert us to performance problems and failures and provide detailed information around the cause of those failures. It creates a Distributed App to illustrate this:

So if a user is getting an error. We can be alerted to this…

…and given code-level information around the cause of the problem

Next time we’ll have fun with graphs…