The new Windows Azure Diagnostic Monitor
The latest update of Windows Azure (the one from June 2012) brought us lots of new features. From virtual machines that can run Linux without any problem to distributed cache that can be stored in-memory or on a dedicated machine.
One new feature that can help us after we deploy a product for Windows Azure is the ability to monitor and track resources utilization in real time. Until now, when we wanted to monitor the resources that are consumed on Windows Azure, we had to redirect all the Diagnostics Monitor data to Windows Azure tables or blobs. After all this data was written in the data store we needed tools to interpret this information. There are a lot of free tools for this, but they don’t always work as expected. Each time the information was loaded, a lot of data passed between Windows Azure and us – this meant extra costs.
With the new version of Windows Azure, we have this mechanism built in. We can monitor and track the resources utilization from the portal in real time. We don’t need to search tools in order to view data and generate reports. All these things are done for us by the portal.
The moment we create a new cloud service, the minimal monitoring is provided to us. This means that we have the following metrics by default:
- CPU Percentage
- Data In
- Data Out
- Disk Read Throughput
- Disk Write Throughput
We can change this configuration to add or remove metrics at any moment of time. When we want to make these configurations before the role starta we need to use a diagnostic configuration file. Because all the metrics data is stored in our data store, we need to specify the data store account that will be used to store this information.
In the service definition of our role we will need to import the diagnostics module.
After this step, we can specify the data store connection string in the service configuration of our role:
After this step all we need to do is to create a diagnostic monitor configuration file. For more information please follow this link: http://msdn.microsoft.com/en-us/library/hh411551.aspx
By default, if we set the level of the diagnostic monitor to verbose, the data aggregation will be made at the following time interval: 5 minutes, 1 hour and 12 hours. All information older than 10 days is deleted automatically. The information is transferred from role instances every 3 minutes.
If we have all these configurations made on our instances, we can access the portal anytime and change the configuration. For each cloud service we can go to the “CONFIGURE” panel and change the monitoring settings. We can only change the level of monitoring, the retention time interval (how many days the data is stored before it is purged) and the connection string to the data store. A different configuration can be made for the production and staging environment. All these configurations can be done from the configuration file before deploying the solution to the cloud. Any configuration that is made on cloud services will not persist if we make a new deployment on a new service instance.
A nice feature of the monitoring dashboard from Windows Azure is the ability to add any kind of metric. This feature is very useful when we try to debug a cloud service and we realize that we need to monitor some metrics. At that moment we can access the monitor dashboard and add the metrics that we need.
Let’s see how this data is stored in Azure tables. For each role instance per aggregation time interval a different table is created. At first look, the naming format of each table can be pretty odd, but once we understand the format we can easily understand it.
- WAD – this is the default suffix that is added to the table name
- deploymentId – id of the deployment
- PT – characters used for delimitation
- aggregationInterval – aggregation interval (the values can be: 5M, 1H, 12H)
- R|RI – aggregation type (it can be at role level aggregation – R, or aggregation for role instances – RI)
From now on we shouldn’t be afraid when we see a monitoring table name in Windows Azure Tables.
The easiest thing to do is to see the monitoring metrics report that is displayed in the monitoring panel. I don’t think that someone will have problems using and understanding this information.
In this post we saw how easy it is to use the monitoring features from Windows Azure. With the new version of Windows Azure not only is the configuration of diagnostics monitoring simple, but also, after reading all this data it becomes very easy. On the top of this all, this diagnostics configuration can be changed at runtime without any problem.