Resources For IT Professionals
Post an article
Wikis - Page Details
  • First published by (3Microsof)
  • When: 15 Jul 2010 4:33 PM
  • Last revision by (3Microsof)
  • When: 10 Sep 2013 9:57 AM
  • Revisions: 5
  • Comments: 2
Options
RSSSubscribe to Article (RSS)
Can You Improve This Article?
Positively! Click Sign In to add the tip, solution, correction or comment that will help other users.

Report inappropriate content using these instructions.
Wiki  >  TechNet Articles  >  Worst Practice: Class properties that get updated frequently

Worst Practice: Class properties that get updated frequently

Worst Practice: Class properties that get updated frequently

Operations Manager 2007 lets the MP author use classes to model aspects of health information.  As with popular object based languages, Operations Manager classes represent a concept, and can include property values such as name, location, etc.    Unlike object based languages, the logic that populates a class is separated from the class - and is found in the Discovery section of the management pack.    Discoveries run when a condition (their target) exists under control of the current agent, and then discover class instances managed by that agent.    At runtime, Ops Manager discovery then populates the properties on these classes based on logic set by the author.  This enables the property values to appear on the operations console.  Classes are useful mostly as targets for monitors and rules - so once a class instance exists under a specific agent control, this will trigger the subsequent execution of any monitors, rules or other discoveries that use the class as a target condition.
 
If the MP author is not careful, or they are "too object oriented", they may add both static and volatile properties.  A static property is one that is set once by the initial run of the discovery operation.  Static properties are well behaved.  It is when authors unwittingly choose to set up volatile property values on classes and then set them each time the discovery runs that severe performance problems can result.   Common examples of volatile properties include last-time-discovery-ran and system values such as a performance counter value at the time the discovery ran.  Volatile properties are undesirable in large operations manager installations because the property maintenance operation is one of the most expensive (performance impacting) things you can do with operations manager.
 
When designing classes, avoid adding properties that change over time.  Let's examine what happens when a discovery sets a property on a class in operations manager.
 
The first time the discovery runs, the class instances are discovered so to the author testing their management pack, everything is good.  But each time the discovery runs, every class instance gets updated with new property values.  This causes the new discovery data to be pushed up to the Root management server (RMS) - a non-trivial operation.  When the class model of a system changes, other agents need to know about the change, so after updating the RMS, the agents are informed of the new state - including the agent that provided the discovery data.  This confirms that the system state is uniform - but this propagation upwards and then back downwards to the agents causes a lot of churn in the system - and this makes the RMS agents work overtime.  This may not seem like a lot of work, but the transfer of many instance level updates each time discovery runs adds load to the RMS server.  When discovery runs frequently, and the instance counts are high, this can destabilize ops manager overall because it is constantly working on updating the instances that are being monitored.
 
The only properties you should expose on a managed entity that is populated by discovery shoud be static data that is instance specific and that changes very infrequently (less than once a week).
, , , , [Edit tags]
Leave a Comment
  • Please add 2 and 1 and type the answer here:
  • Post
Wiki - Revision Comment List(Revision Comment)
Sort by: Published Date | Most Recent | Most Useful
Comments
  • 10 Sep 2013 9:57 AM

    Dan Rogers edited Revision 3. Comment: Grammar changes and clarity

  • 10 Sep 2013 9:22 AM

    Maheshkumar S Tiwari edited Revision 1. Comment: Added Tag

Page 1 of 1 (2 items)
Wikis - Comment List
Sort by: Published Date | Most Recent | Most Useful
Posting comments is temporarily disabled until 10:00am PST on Saturday, December 14th. Thank you for your patience.
Comments
  • Posted by
    on 10 Sep 2013 9:22 AM

    Maheshkumar S Tiwari edited Revision 1. Comment: Added Tag

  • Posted by
    on 10 Sep 2013 9:57 AM

    Dan Rogers edited Revision 3. Comment: Grammar changes and clarity

Page 1 of 1 (2 items)