How to discover and monitor a multi-role application

Most of the time I subscribe to the KISS principle when it comes to authoring and SCOM.  I rarely recommend customers developing related class hierarchies in their own MP’s.  While making visualizations and routing of alerts far more functional, these complex relationships between classes can create much more complex MP’s to have to support.  Some of the WORST Management Packs that Microsoft ever provided, are partially due to being overly complex in their class structure.

That said – there are some benefits to using a multi-role class structure, when it is applicable to an application that you are trying to monitor:

1.  You can have more concise state/dashboard views that summarize application health when you have a top level class, instead of having to view lots of state views for multiple independent classes in an application.

2.  You can use diagram views effectively.

3.  You can create grouping based on the parent class which makes routing of Alerts via scoping or subscriptions much simpler.

I run into this from time to time with customers…. where to monitor their application, we’d end up with 10 or 12 independent unrelated classes.  That’s a real pain to manage, and you end up having to create state and alert views for EACH class (role) within the application.  This makes it much more challenging for effective operations down the road.  So, a little more complexity on the authoring side, can reduce complexity on the end-user side for years to come.

I have added two new fragments to my Fragment Library:

Class.And.Discovery.MultiRole.mpx

Class.And.Discovery.MultiRoleHostedByParentClass.mpx

These fragments are not complete, “import and go” like most fragments, they are more of a simple example class/relationship structure to get you started if this kind of MP is applicable.  The reason this is complex, is because of the different ways you might have to discover your app.  Registry, WMI, or Script might all come into play.

In Class.And.Discovery.MultiRole.mpx, this fragment uses 3 classes.  An abstract parent class, and two child classes.  Each child class represents a distinct application role.  Using this fragment, you ONLY discover the child roles.  The parent role is an abstract class, and the children use it as their base class.  Think of Remote Desktop Services as an application.  I could have the Gateway Role, and the Licensing Role.  In this case, I can discover each sub role independently, and apply different monitoring to each of those classes.  However, I could see an “all up view” by looking at the Parent Class role:

Each AppRole class can have whatever discovery type needed.  In this example, I provided a Registry discovery for one, and a PowerShell script example for the other.

In the Class.And.Discovery.MultiRoleHostedByParentClass.mpx fragment, this structure is slightly different.  There are actually 4 classes.  The first class is more like a “seed” class.  This must be discovered first with a simple discovery, then all application role discoveries target these class instances.  In this example, the AppRole classes again have an Abstract “parent” class to use as their base class.  However, we add a relationship from the Parent Seed class to HOST the Parent Abstract base class.  This gets a LOT more complex to understand, but it allows you to control Health Rollup from child to parent class. 

In this example, each class discovery type is provided for examples, like Registry, WMI, and Script.

If you import these into Silect MP Author or Visual Studio VSAE, you will see there is almost no user input required to use them.  Only ##CompanyID##, and ##AppName##.  However, the expectation is these are more to serve as examples/samples…. to give you a basic application structure that you can use to simplify operations.

You can download the fragment library here:  https://github.com/thekevinholman/FragmentLibrary

You can see fragments in action here:  https://kevinholman.com/2019/07/15/advanced-mp-authoring-mpu-may-2019/