Making Applications Manageable – Turning Your Death Model into a Health Model

Sounds and looks (DTO Show screencast) cool guys.  I see where your going.  I am just wondering about instrumentation model for an app and threading/locking and what the guidance will be.  If you have a shared server app and you need to expose counters that get read and written to pretty fast, how/where/what do you use?  Would you just setup some element in your model and use those exclusively.  We would still probably need to take a lock in our server for other state changes and hold it while updating your state.  Is this going to be fast enouph?  Just trying to wrap mind around using this from the 200 foot level.

Some clarification/background:

Windows has great low-level instrumentation services, notably performance counters, event logging, and WMI.  These constitute the 'standard' Windows instrumentation interface.

The .NET Framework already has good low-level support for Windows instrumentation, notably in System.Diagnostics.  You can, today, publish events and ticks and expose WMI interfaces.

Microsoft Operations Manager (MOM) is the premier software for managing Microsoft software-based business systems.   It is like an "expert system" in that it contains vast knowledge about specific server products such as SQL Server, Exchange, IIS, Windows Server, etc.  That knowledge is embodied in so-called Management Packs.  Microsoft provides and periodically updates the packs for its entire line of server products. 

The MOM user experience is based around the notion of a "health model" with which MOM assesses the health of your solution.  The individual management packs assess a given application's health in any way they see fit, but primarily they use - surprise - the above-mentioned Windows instrumentation services.

For a given business system, you are encouraged to write MOM packs for your custom applications.  Your pack must formulate a health model for your application.   Building an abstract description of the model then generating instrumentation code and a management pack would be great functionality.   Indeed, it is what this video describes.

Hope this helps!  Use MOM!

eronwright wrote:



Some clarification/background:

Windows has great low-level instrumentation services, notably performance counters, event logging, and WMI.  These constitute the 'standard' Windows instrumentation interface.

The .NET Framework already has good low-level support for Windows instrumentation, notably in System.Diagnostics.  You can, today, publish events and ticks and expose WMI interfaces.

Microsoft Operations Manager (MOM) is the premier software for managing Microsoft software-based business systems.   It is like an "expert system" in that it contains vast knowledge about specific server products such as SQL Server, Exchange, IIS, Windows Server, etc.  That knowledge is embodied in so-called Management Packs.  Microsoft provides and periodically updates the packs for its entire line of server products. 

The MOM user experience is based around the notion of a "health model" with which MOM assesses the health of your solution.  The individual management packs assess a given application's health in any way they see fit, but primarily they use - surprise - the above-mentioned Windows instrumentation services.

For a given business system, you are encouraged to write MOM packs for your custom applications.  Your pack must formulate a health model for your application.   Building an abstract description of the model then generating instrumentation code and a management pack would be great functionality.   Indeed, it is what this video describes.

Hope this helps!  Use MOM!

Thanks.  I think that helps.  So your app will just do what it do, but it will (as needed) publish state changes to the mom framework?

Correct.  You instrument your application with appropriate events and performance counters, such that its health can be assessed by management software such as MOM.  

If you are using MOM, developers should build a management pack as they go along.  A typical pack will contain rules for monitoring performance thresholds (based on your counters, of course), watching for events, performing discovery of running instances of your application, probing your application periodically, etc.  In addition, so-called knowledge articles detail the likely causes of error, possible resolutions, etc.

MOM provides a lot of .NET-based extensibility points for managing your application.  Indeed, a management pack is similar to a unit test project in how much code can conceivably be written.  I see it as an equally important part of an overall application.

Pursuant to this discussion, check out this great batch of videos regarding Operations Manager 2007.  My favorites:

• Distributed Applications (SDM-based!)
• What's new for Operations Manager 2005 Authors
• Building Management Packs (Management Pack Concepts)
• Management Pack Templates