The “Monitoring Azure applications” series:
I've been working a lot monitoring of Azure applications lately and while I've found a number of helpful blog posts on various topics surround the matter I've not yet found one comprehensive set of posts that walk you through the process from start to finish. What I want to do with this series is…
The series assumes that folks have a novice to intermediate understanding of OpsMgr and (like me) are relative newcomers to Windows Azure. These posts also assume that the following as already been done:
We’re not in the data center any more…
With traditional on-premise applications, I’m used to getting a list of servers and a list of instrumentation, pushing agents to those servers and then building an MP to collect or alert on the instrumentation. While there are similarities, there are some fundamental differences about Azure applications that make that process, not entirely portable.
The three most significant ones that come to my mind are the following:
I’ll cover the impact of the first bullet in another post, but for starters I want to focus on bullets 2 and 3 as they both relate to getting things configured in Azure.
Getting the Azure application ready to be monitored
So in order to turn the instrumentation “on” and to get all of that instrumentation into one place, where it can be consumed by OpsMgr, we need to start working with the Windows Azure Diagnostics (WAD). Here are the steps involved:
With all of that in place, your Azure application is now capable of sending it’s instrumentation to Windows Azure Storage. You can verify this with one of the many tools available (a few are listed here). I personally use the Server Explorer in Visual Studio.
In the next post we’ll cover getting management certificates setup in both Azure and OpsMgr.