OpsMgr Lineage Explorer

As I’ve been researching management pack elements over the course of the past 18 months, one task that I find myself doing over and over again is researching the lineage of management pack elements.  With the inheritance and composite module features of the OpsMgr design, this can take you down quite a road.  I have long wanted to write a tool that makes this easier.  This is it.

What This Tool Does
This tool allows you to explore the lineage of OpsMgr MP elements.

Why This Tool Is Useful
OpsMgr is very object-oriented in its design.  As such, it includes inheritance for class types and relationship types.  Also, the workflow engine in OpsMgr is the driving force behind all discoveries, monitors, and rules.  All discoveries, monitors, and rules are based on modules that perform various functions.  All module types derive, eventually, from either managed code or native code.  One major difficulty in researching a new management pack you’ve loaded (or from which you intend to learn) is that module types can also be “composite” modules, which contain any number of other modules that are linked together to form a new module type.  Often, you will find a discovery that uses a data source module that is a composite of three or four modules.  Those three or four modules can themselves be composites of several modules.  Some management packs have modules that must be un-wrapped to four or five levels before you really understand the base modules that make up the actual work the workflow is doing.

This tool loads your OpsMgr environment from the database and then allows you to inspect the class types, relationship types, and module types installed.  It allows you to expand them to see their lineage (either their parentage for class types and relationship types or in the case of module types, their composition tree down to the underlying native or managed modules).

Future Directions
I am currently working to extend this viewer to include:

  • MonitorType Lineage
  • Discovery DataSource Lineage
  • Discovery Target Lineage (useful for disabling the “root” discoveries for a management pack)
  • Rule Lineage

I also plan to add more features around presenting the data:

  • DisplayStrings.  Everything is an ID right now, which is the most important item for using what you see in your own MP.
  • A view into the <Configuration/> block for modules.  This is easy to do at face value, but to make it intelligent, the schema really needs to be parsed so one can easily see how a composite module is using a member module.  This would also involve expanding the SchemaTypes involved.  Many times, this is a simple $Config$ reference, which just passes the problem up the chain; however, the implementation of many modules do not require the configuration of certain member modules to be specified.  Instead, they configure the member module directly.  This is often the case with the Expression Filter.  The bottom line is that a view into the <Configuration/> block will be introduced shortly, but it may or may not be introduced with some intelligence around parsing the schema.  At some point, however, that would be the desired end state for this part of the tool.
  • I have a function that I have not completely implemented that will allow a module to be right-clicked and selected as the filter for the entire display.  This would be very useful, for example, in determining which modules eventually use a script, publish performance data, or generate alerts.  Most management packs are intuitive, but I’ve seen a few write actions in rules that bury the GenerateAlert module a few levels deep, which makes it difficult to flag them as alert-generating.
  • Exception handling will improve as I get feedback and break the tool more myself.  I’m following the basic premise that I recently discussed with a friend and peer developer: I’m not catching exceptions unless I plan to do something useful with them.  This is a fairly innocuous tool at the moment, so I’m assuming that you’d like to see the stack trace as much as I do.  I’ll spare everyone from the Spartan “Could not connect to database.” message box for the time being.

Getting the Tool
The current build (227) is available for download here:




One Response to OpsMgr Lineage Explorer

  1. Vin
    Could you add the ability to export to XML or text? That would be nice.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: