Monitoring Azure applications - Part 3

The “Monitoring Azure applications” series:

• Part 1: Enabling instrumentation and monitoring in your Azure app(s)
• Part 2: Setting up the handshake
• Part 3: Discovering your application
• Part 4: When things don’t work

Ok, so at this point you’ve got an application deployed to Windows Azure, you’ve setup that application with some instrumentation and you setup the necessary components to allow authentication between the OpsMgr environment and Azure.  Now it’s time to put the Azure management pack to work.

Import the MP for Windows Azure Applications

The first thing to do is get the Windows Azure management pack.  You can either search the pinpoint catalog for “Azure” to get the download link (this ensures that even if I don’t update my blog, you’ll get the latest and greatest), or you can go directly to the download page here.  Once you complete the management pack MSI, import the management pack into your management group. Note: The Management Pack for Windows Azure Applications works in both OpsMgr 2007 R2 (CU3 and beyond) as well as Operations Manager 2012.

What does the MP provide?

Once the management pack is imported, you’ll see two new things that you can see in the operations console and a number of other components that will come in use down the road (aka in a future blog post).

The first is a new set of views in the monitoring section of the console.  These views provide one place for reviewing state and performance of your Azure applications that you monitoring with operations manager.  While each application that you discover will also have a distinct view folder, these are the views that you will use to view state across all of your Windows Azure applications.

The second new thing that you will see in the console is under the Authoring section.  With the Management Pack Templates section of the UI, a new template will be added for Windows Azure Applications.  This is really nice because it means that we don’t have to do any real MP authoring to get monitoring of our Azure applications setup and running.  Granted, there are some complex monitoring scenarios that need further development, but the out of the box model is a great starting point, especially while your application is in test or still under development.

There are two more things that are provided within the management pack, which you do not see as features in the UI, but are important to briefly note here.

The first is the class model.  The Azure MP defines a lightweight and, in my opinion, clever class model which defines the generic structure of Windows Azure applications.  What makes the model clever is that it is succinct and that all other Azure application instances  inherit from this one class model.  This allows for both the “one view for all” view and allows for very easy addition of new workflows, which apply to all Azure applications.

The second is a set of module type definitions, which will come in handy later when we go to create custom monitoring for our Azure applications.

Discovering the Windows Azure Application…almost

Before we jump into the Azure MP template wizard, there are a few details we need to collect:

• What is your application’s subscription ID?  You can get this by opening the Windows Azure management portal (https://windows.azure.com), clicking on Hosted Services, Storage Accounts & CDN in the bottom left-hand of the portal , selecting Hosted Services toward the middle of the left-hand of the portal, and then click on the subscription that contains the application you want to discover.  On the properties pane on the right-hand side of the portal, you’ll see a property labeled Subscription ID and the string is a big GUID looking thing.  Copy that off to notepad.
• What is the DNS prefix of the hosted service?  Once you have the subscription ID, click on the hosted service under that subscription in the middle tree view of the portal.  You will then see a property named DNS Prefix on the right-hand side of the portal.  Copy that off to notepad as well.
• Which deployment(s)/environment(s) do you want to monitor?  Windows Azure provide the ability for users to run two builds of their application in parallel and swap between which is the “live” version.  This is covered in Overview of Managing Deployments in Windows Azure.  You’ll want to note whether the application you want to monitor is in the production deployment, the staging deployment or if you want to monitor both.  When in doubt, chose both and tweak it later if you need to.
• What is your proxy agent (aka watcher node) going to be?  One, and unfortunately only one, healthservice in your management group will act as the go-between for the Azure Service Management API and the management group.  If this box or the agent on it goes down, then the monitoring of the Azure application stops as well.  So, choose wisely and manage the proxy agent as if it were a part of your infrastructure!  Note:  You will also need to be sure that your run as accounts are approved for distribution to the system you pick.  I wrote about this a bit in Setting Up the Handshake under the heading “Create the Run As Accounts required for certificate based authentication” (points 4.c and 5.c).
• Does your proxy agent need a proxy server to communicate to the internet?  Since the Azure Service Management API is itself hosted in the cloud, the proxy agent (different kind of proxy) needs to have internet access.  As such, if you need to use a proxy server, capture that in notepad as well.

Discovering the Windows Azure Application…for real this time!

Ok.  All of your details are in order and now you can use the new template to discover your Azure application with Operations Manager.  This is what you do:

1. Open the Operations Manager console and connect to your management group (note: I have connected to the wrong group before, so it’s worth double-checking)
2. Switch to the Authoring section of the console
3. Navigate to Authoring -> Management Pack Templates
4. Right-click on Management Pack Templates and select Add Monitoring Wizard…
5. On the Monitoring Type page select  Windows Azure Application and click Next>
6. Give your application a name and select which unsealed MP you’re going to save your new monitoring into.  Note:  As always, it is never a good idea to save things into the default management pack
7. On the Application Details page, enter the DNS prefix and Subscription ID that you recorded earlier and choose which environment(s)/deployment(s) to monitor
8. On the Application Details page as well, select the run as accounts that you created previously and then click Next>
9. On the Proxy Agent page, pick the proxy agent and if the proxy agent needs to talk to the internet via a proxy server then enter those details as well.  In our case, we use existing management servers as our watchers since 1) we are already have good monitoring to ensure those healthservices are online and 2) the workload added is not much.
10. Then finish out of the template wizard and you are done.

So now what?

First things first, discovery has to happen.  The MP that you just created via the template has a discovery built into it which will run on the root management server (RMS).  That discovery in turn puts an object under the ownership of the proxy agent that you selected.  When the proxy agent realizes it was just handed a new object it will update its configuration and then run another discovery to get at the balance of the details for the Azure application.  It sounds involved, but in most cases it should take 2-5 minutes to complete.  So go grab a coffee, stretch, walk around the building, browse <insert your favorite social site>, check email, whatever. Now switch over to the Monitoring section of the console and scroll down to the Windows Azure set of views, and more specifically the Hosted Service State view.  Once the RMS discovery completes a new instance will show up here, but it will not have state yet.  Once the full discovery on the proxy agent runs, state will be populated here and you can then start browsing into the other state views to see the rest of the application.  You can also right-click on the row in the Hosted Service State view and select Open -> Diagram View.  With this view, you can watch the whole application get discovered and see how the objects relate to each other.

 

Now that the objects are discovered, the monitoring and collection workflows can start.  As I mentioned before, there is a set of rudimentary monitoring and performance collection that comes with the Azure template.  The following images show this better than I can explain it.

• The monitors targeted at the Role Instance class
  
• The rules targeted at Hosted Service and Role Instance
  

Lastly, if you ever need to revisit how your Azure application monitoring template is setup of you want to change something (i.e. deployment(s) or proxy agent), you can return to the Authoring section of the console, navigate to Authoring -> Management Pack Templates -> Windows Azure Application and then open the properties of the template from there.

So that’s it!  Now you have discovered you Azure application with Operations manager and you’ve been given a rudimentary set of monitoring and performance collections to boot.  But what if something went wrong in the discovery process?  That will be the subject of my next post on this topic.