In the first part of my blog series about Service Monitoring I’ve described how Service Monitoring could be implemented en what parts of Service Monitoring are important. One of the most important lesson was to create a process around Service Monitoring. You can find the first blogpost in this series here. In this second part I want to talk about the implementation of Service Monitoring in System Center Operations Manager 2012: Distributed Applications.

Distributed Applications are used for showing the overall health of monitoring objects. Each monitoring object which is available in SCOM can be added to a distributed application. Distributed Applications can be created through the Distributed Application Designer in the Operations Console or through authoring tools. When you create your distributed applications through the Distributed Application Designer you can choose a base template. This template consists of some pre-configured distributed application component groups. There are 3 original SCOM 2007 templates: Line of Business Web Application, Messaging and Blank. These templates have a bug in the configuration of the health rollup mechanism. Only for the Availability part the Health Rollup monitors are created. Health Rollup for the Performance, Configuration and Security is not created out-of-the-box. If you want to use those templates and you want to have health rollup based on those parts you have to add your own rollup monitors by editing the Management Pack where the Distributed Application is saved.

If we want to understand how the distributed applications are created and discovered we have to look a level deeper. A distributed application consists of the following objects:

The Distributed Application and the components groups are class instances. The members of the component groups are also class instances. The membership of those objects are based on relationships. Why is this that important?

• Classes need to be defined in Management Packs. It’s difficult to discover those objects dynamically. If you want to do that you have to discover the objects and script a management pack around those objects. To my opinion this is not a easy process.
• The Relationships which define the membership of the objects can be discovered dynamically. The definition of the relationship need to be defined in the Management Pack but the instances can be discovered dynamically.

Why is the above still important?

If you are working with Distributed Applications you want to avoid editing a Distributed Application itself. If you have sealed your Management Packs with you distributed applications you will see that editing those MPs will result in a ‘not-monitored’ state of your distributed applications for some time. This is an undesirable situation. So how can we avoid the above scenario? We have serveral solutions for that but in this blog series I want to talk about the following solutions:

1. Make your distributed application dynamic by using dynamic groups
2. Make your distributed applications independent based on an external source file.

In this post I want to talk about the first solution and in part 3 we will look into the second solution.

Make your DA dynamic by using dynamic groups
When you implement this solution you add an additional component to you DA design. In each component group you add a dynamic group. The group will have a membership rule and based on the matches of this rule objects are added to the dynamic group. If you configure health rollup also on the Dynamic Group the health of the members of that group will be rolled up to to the component group and distributed application. A graphical view of this solution:

This solution has the following pros and cons:

Pros:
• If you configure the above solution the distributed application is dynamic. The membership of the monitoring objects is now dynamic because of the use of dynamic groups.
• Because of the use of dynamic groups you can edit the Management Pack in your test environments and when the MP is tested you can ‘upgrade’ your MP in production. This will reduce downtime when editing your distributed applications
• You can create dynamic groups based on a naming convention of objects, active directory groups and custom attributes.

Cons:
• It’s not always easy to create membership rules for the dynamic groups. It can cost some effort to create those and if created you have to take this in account when doing changes to the monitoring objects.
• You DA is now dynamic, if you want to have control on which objects will be added to the DA your only solution is to change the membership rule. If this cannot be done, you cannot control the membership of the monitoring objects

Based on the above pros and cons you will see that using Dynamic Groups in combination with Distributed Applications will give you some dynamic power. In Part 3 of the series I want to loop into the second solution. This solution is based on getting more control of the objects which are added to the distributed application.

Part 3 can be found here.