Building a consecutive event monitor for a Windows Azure Application can be very useful. Azure applications should throw exceptions when something goes wrong, sometimes they are minor issues, other times they are major. Building monitoring for this can be difficult.
Should we mark an application as critical if an exception is thrown? The answer is "not always." What if the application is throwing exceptions continually? The answer is "always!" We need to measure the number of exceptions thrown per timeframe and change the state of the application accordingly.
Firstly if you are not familiar with monitoring Windows Azure Applications with Operations Manager, included at the bottom are some links to help:
Operations Manager must raise an Alert if more than 5 events are received within a certain time period.
Create a monitor that will dictate the health of a Windows Azure Role Instance based on the occurrence above. An alert will be generated when the monitor enters a critical state.
A rule can satisfy the criteria set out above, however we can learn more concepts by building monitors and we can drive the state of the application.
We should be using the Visual Studio Authoring Extensions, but this was written a while ago.
Composite modules are composed of one or more other modules. Composite modules are included in library management packs, and custom composite modules may be defined by management pack authors for performing custom logic. Composite modules require no installation on the agent computer and are completely defined in a particular management pack. They may include native code modules, managed code modules, other composite modules, or any combination of such modules.
The Azure MP provides 3 data sources we can leverage:
We must create a composite module containing:
This consolidated module should be named agnostic of application or any variables such as EventIDs. Composite Modules can and should be reused where possible.
Both values should read:
Click OK when finished.
Click Edit… - if this is the first time you have entered the XML editing mode, you will need to specify a text editor.
In the example XML, we are promoting the Latency, Interval and Count elements to be configurable outside the Composite Module e.g. in the Monitor.
We are also using the OnNewItemTestOutputRestart_OnTimerSlideByOne, this counting method uses a sliding windows rather than the default fix window.
In step 5, we have just targetted EVERY role instance in our Azure application. This monitor would apply to; webroles & workerroles for ALL discovered Azure Applications.
If we want to be more granular over which applications or roles we target, we must reference our Application specific Management Pack the MP references. Then the Management Pack Class Chooser will be populated from classes defined in that Management Pack. Remember though, sealed vs unsealed becomes an issue here.
An Event with an EventID of $Data/Context/Context/DataItem/EventNumber$ has been raised on
$Target/Property[Type="MicrosoftSystemCenterAzure!Microsoft.SystemCenter.Azure.RoleInstance"]/RoleInstanceName$ $Data/Context/Count$ times with the description $Data/Context/Context/DataItem/EventDescription$
Click Tools and Export MP to Management Group… and select your TEST Management Group
You will get a 1201 event on the target RMS (first) and proxy agent (after) to indicate a new Management Pack has been received.
Then open the Health Explorer for a role instance and check your new monitor has been set up.
And when the application goes bad, this will be reflected all the way up the role instance on up the azure application.
The steps required to discover a Windows Azure Application are documented in the Monitoring Pack guide for the System Center Monitoring Pack for Windows Azure Applications (Azure MP): http://www.microsoft.com/en-us/download/details.aspx?id=11324
Management Pack Technical Writer Brian Wren: http://blogs.technet.com/b/mpauthor/archive/2011/06/20/custom-monitoring-for-windows-azure-management-pack.aspx
Attached to Brian's post is another sample MP which deals with nearly every connotation of Azure monitor known at the moment. So there's performance, events, .NET trace all that good stuff.
For more Event Logs examples, the following has some good posts on this: http://blogs.msdn.com/b/walterm/archive/2011/08/19/scom-2007-r2-event-log-alerting-and-monitoring-for-azure-applications.aspx