For a clearer picture

Tag: SCOM

Part 3 – PowerShell Monitors – Monitor Type

The monitor type is where we define the workflows. I’ll run through creating a 2 state monitor where we have a workflow for “over threshold” and a workflow for “under threshold” as well as look at on-demand monitors \ workflows.

When you target a single instance class, be aware that when you have a 2 state monitor then both workflows will execute. Likewise, with a 3 state monitor you will have 3 workflows executing. If you have a multi-instance target then you will get 2 (or 3) workflows per instance. So you can quickly see that you can start to have a major impact on performance of the system being monitored which is why cookdown is important.

Right click on the folder FolderMonitoringCountFoldersInFolder and select Add, New Item, Empty Management Pack Fragment

This is the complete code that needs to copied and pasted between the tags.

Let’s look at it in some more detail.

First off, this is a 2 state monitor and we define the monitor type states. I’m going to have 2 – one for the value for number of folders less than or equal to the threshold and one for when the number of folders is greater than the threshold.

We then need to define the configuration parameters.

  • Interval Seconds and Sync Time are for our scheduler
  • From, To and Days allow us to set business hours using a schedule filter
  • Match Count allows us to only trigger a health state change (and trigger an alert) after a consecutive number of failures
  • Folder Path is the path to our “top level” folder
  • And threshold is the maximum number of folders are considered healthy. Any more than this and we want to trigger a health state change –> alert

The next section we want to set which parameters are available as overrides.

Within our modules, you will see a data source entry which triggers the data source we created in part 2 – hence it is passing over the parameters for interval seconds, sync time, folder path and threshold

But what I also have included is a separate probe – this will be used to trigger on demand detection which will allow the “Recalculate Health” button in Health Explorer to actually work. It doesn’t need an interval seconds or sync time configuration as it will be triggered on demand to execute on demand.

We then come on to our first condition detection which is to detect when the number of folders in our top level folder is less than or equal to the threshold

And then our next condition detection to detect when the number of folders in our top level folder is greater than our threshold. You’ll see here that I have included to suppress on MatchCount – so we can configure the workflow to only trigger a health state change after x consecutive occurrences. I didn’t set any suppression on the healthy workflow. That is because I would like the monitor to reset to healthy as soon as possible.

What I have done next is to configure a condition detection which will set a filter which will only pass data “on schedule”

We then have a section for regular detections; these are the “normal monitors”. You’ll see that we have 2 workflows defined. One to detect “less than or equal to threshold” and the other to detect “over threshold”. What I have also done is to add the filter to the over threshold workflow. This means that outside of my configured hours the workflow will filter data and not allow it to pass (and so won’t trigger an unhealthy state). My healthy (less than or equal to threshold) workflow doesn’t have this filter. I want the health state to go healthy 24x7x365. This is a matter of personal taste. Some authors will put the filter onto the data source that we looked at in part 2 so that the monitor doesn’t even execute which means that the monitor will stay unhealthy out of hours even if the monitored value drops below threshold, It all depends on what you are looking to achieve.

The final piece is the On Demand detections which enable the Recalculate Health button in Health Explorer to actually do something useful rather than just being eye candy.

Part 6 – Application Server and Groups

Microsoft doesn’t have a management pack for your in-house applications or even most 3rd party applications. So there are no classes, no discoveries, no relationships and no monitoring. That is where we, as SCOM specialists \ Subject Matter Experts, earn our keep. So let’s get going.

First; when I have a problem with my application I want my application team to deal with it. I don’t want the health rolling up to the windows computer object. So when I create the class for my application server I will:

  • Base it on Microsoft.Windows.ApplicationComponent
  • Create a hosting relationship to Windows Computer (as I want the agent on the computer to “host the monitoring”).
  • NOT create a dependency roll up monitor to windows computer – this way I keep my health state at the application layer and not the computer (infrastructure) layer. Note that if I had based my class on Microsoft.Windows.Computer or Microsoft.Windows.LocalApplication that I would not be able to manage the health rollups. A relationship and dependency rollup monitor would exist automatically.
  • Create a Filtered Registry Discovery Provider – I have created a windows service in C# and will use the registry key for that but you can always create your own registry keys which we will do for other components
  • Create a Group of Application Servers
  • Create a Group of Windows Computer Objects that host the Application Servers
  • Create a Group of Operating System Objects that host the Application Servers
  • Create a Group of Logical Disk Objects that host the Application Servers
  • Create a Group of Health Service Watcher Objects for the Application Servers

I will do this as a set of individual Management Pack fragments but you will be able to see that once we have done this; we can actually create a single Management Pack fragment that we can use in the future.

I’ll create a folder structure in Visual Studio. This is very much personal preference and I tend to follow the layout from the SCOM 2007 authoring console of Service Model, Health Model and Presentation folders but for the purpose of this walk through I’ll do the following:

1. Create a class for my application server based on Microsoft.Windows.ApplicationComponent

Right Click ClassesDiscoveriesRelationship and choose Add New Item, Empty Management Pack Fragment and call the fragment 1_Batura_ApplicationServer_Class

Copy and paste the following code:

If you try and build the solution at this stage you will get an error as we have stated in the class definition that the class is hosted but we haven’t defined the hosting relationship yet.

2. Create the Hosting Relationship to Windows Computer

Right Click ClassesDiscoveriesRelationship and choose Add New Item, Empty Management Pack Fragment and call the fragment 2_WindowsComputer_Hosts_BaturaApplicationServer

Copy and paste the following code

Now you can build the solution and it should (it will!) build successfully.

3. Create a Filtered Registry Discovery Provider Discovery

Right Click ClassesDiscoveriesRelationship and choose Add New Item, Empty Management Pack Fragment and call the fragment 3_RegistryDiscovery_BaturaApplicationServer

Copy and paste the following code

You’ll need to change the registry key if you are following this through.

And then deploy the management pack and go to the SCOM console, Monitoring blade and Discovered Inventory. Scope for the Batura Application Server Class

At the moment the class is listed as Not Monitored as we don’t have any monitors targeted at it. I’ll look at creating service monitors in a later article but I’ll do a quick digression here so that we can have a health state and check that our code is working when we come to the groups and health state rollups.

Digression Alert – creating a windows service and service monitor

See here on how to create a windows service and then a windows service monitor.

This shows our Batura Application Server with a health state so that when we create our groups and dependency roll up monitors, we can validate that they work.

4. Create an instance group of Batura Application Servers with a health rollup state.

For this, we will need to reference the Microsoft Instance Library. Right click References in Solution Explorer and choose Add Reference, and browse to c:\program files (x86)\system center visual studio authoring extensions\references\OM2012R2 and choose Microsoft.SystemCenter.InstanceGroup.Library.mp

Then right click the ClassDiscoveriesRelationship folder in Solution Explorer and choose Add, New Item, Empty Management Pack fragment and name it 4_Group_BaturaAppServer

Copy and paste this code into the empty fragment and build \ import.

Then scope discovered inventory to the Batura Application Server Group and you should see the following:

5. Create a Computer group of Batura Computers.

This is very different to the group of application servers (or operating system objects). This is a group of computer objects which will have a health state that rolls up from monitors that are targeted at Windows Computer.

Then right click the ClassDiscoveriesRelationship folder in Solution Explorer and choose Add, New Item, Empty Management Pack fragment and name it 5_Group_BaturaComputers

Copy and paste this code into the empty fragment and build \ import.

Note in here that we are using “Contains” to get a group of computer objects that contain the Batura Application Server. Because we know that the Batura Application server is directly hosted on the windows computer, we can use the MaxDepth property to tell SCOM to just look at direct child classes.

Then scope discovered inventory to the Batura Computer Group and you should see the following:

Notice that the group has a health state – I’ve included a dependency rollup monitor in the code so that the group will have a health state equal to the worst health state of any members.

6. Create a group of Operating System objects

The performance metrics for logical disk, memory and processor are targeted at Operating System classes so a group of these objects will assist us when we come to do some performance views.

Then right click the ClassDiscoveriesRelationship folder in Solution Explorer and choose Add, New Item, Empty Management Pack fragment and name it 6_Group_BaturaOperatingSystem

Copy and paste this code into the empty fragment and build \ import.

One of the challenges you will see here is that the Health Explorer shows the target – which in this case is the Operating System version. We can’t see in Health Explorer the actual server name. We can “fix” that in Squared Up.

7. Create a group of health service watcher objects

Why? Well; lets stop the agent on a healthy server. And you’ll see the computer groups stays green. The server greys out in the console but greyed out isn’t a health state. The health state remains that of the object when it was shut down.

And the way we have designed the monitoring, this means the application also stays green.

But by including the health service watcher object; we can see that something is wrong.

To create the group, right click the ClassDiscoveriesRelationship folder in Solution Explorer and choose Add, New Item, Empty Management Pack fragment and name it 7_Group_HSW

Copy and paste this code into the empty fragment and build \ import.

8. Create a group of IIS websites

This is more straight forward once we know that the property we are looking for is Description. To find this out we can either look in the state view of the SCOM console or, a much better way, is to use the Management Pack Browser in Visual Studio. If it isn’t visible then go to the menu bar and choose View, Management Pack Browser. This was we can also find the Management Pack the base class is created in as well as the actual base class itself.

Then right click the ClassDiscoveriesRelationship folder in Solution Explorer and choose Add, New Item, Empty Management Pack fragment and name it 8_Group_IISWebsites

Copy and paste this code into the empty fragment and build \ import.

Interestingly, if you look at the health explorer from the above screenshot you will see that you don’t just have your website rolling up health but also your application pool. This is because there is an out of the box dependency rollup monitor provided by Microsoft that rolls up the health of the application to the website.

And you’ll find that if you do stop the application pool, the website will go critical.

For this reason you will find that you might want to take a different approach to modelling your applications. Using groups means that all of the monitors that are targeted at the website will affect the health state of the class and hence the group. If we really want to target specific monitors then we need an alternative approach which will be discussed in another set of blogs.

9. Create a group of IIS Application Pools

To create the group, right click the ClassDiscoveriesRelationship folder in Solution Explorer and choose Add, New Item, Empty Management Pack fragment and name it 9_Group_IISApplicationPool

Copy and paste this code into the empty fragment and build \ import.

And you should see this:

10. Create a group of Microsoft SQL Databases

To create the group, right click the ClassDiscoveriesRelationship folder in Solution Explorer and choose Add, New Item, Empty Management Pack fragment and name it 10_Group_SQLDatabases

Copy and paste this code into the empty fragment and build \ import.

And you should see this:

11. Create a group of all the groups

And finally; lets create a top level group for our application and have all the other groups as nested members.

To create the group, right click the ClassDiscoveriesRelationship folder in Solution Explorer and choose Add, New Item, Empty Management Pack fragment and name it 11_Group_Application

Copy and paste this code into the empty fragment and build \ import.

And you should see this:

Next step …

… is to put this onto a dashboard.

Previous steps

Part 1 – Series Background

Part 2 – Visualisations with Squared Up

Part 3 – Application Monitoring Overview

Part 4 – Monitoring Overview

Part 5 – Create the Management Pack Solution and Project

Future articles

Part 7 – Create the Squared Up Dashboard

Part 2 – Squared Up – get a better picture of your SCOM monitoring

Part 2 – Squared Up – get a better picture of your SCOM monitoring

Previous articles

Part 1 – Background

Later articles

Part 3 – Application Monitoring – Setting the scene

Part 4 – Monitoring Overview

Part 5 – Create the Management Pack Solution and Project

Part 6 – Create the Management Pack components

Part 7 – Create the Squared Up Dashboard

Even after all these years; System Center Operations Manager (SCOM) is still going strong as an on-premises performance and application monitoring solution. It has its quirks and anyone who believed the marketing hype of “quick to deploy” and “best of breed management packs” soon realises that the reality is somewhat more complex. However, that could be said of any monitoring solution. One thing that is definitely true though is that to get real value from SCOM you need to take time deploying and tuning SCOM, building processes that help you sort out the noise from the real issues.

Once you have the solid foundations in place, another challenge is that despite collecting huge amounts of what could be useful data giving real insight into your infrastructure and application performance and availability; SCOM makes it as difficult as possible to display that data in user friendly and meaningful ways. Reporting is dreadful. The widgets are a little better but performance can be painful.

So take a step forward with Squared Up. Simple, easy to use and with an equally straight forward licensing model. Whether you want high level dashboards for your service managers or drill down dashboards that your application support teams can use to triage issues, Squared Up make your job as a SCOM Administrator so much easier.

And not only does Squared Up deliver¬†super-fast HTML5 dashboards, they can also provide automatic application discovery and even dynamically integrate external data – all delivered via a single, lightweight, easy-to-install product. I’ll look at that more in future articles; especially now that v4 has been released and I can talk about some of the exciting new features.