Monitoring CPU Wait Time in SCOM 2012 R2

Dear readers,

For the purpose of this article and readability I will write in English (or Engrish …). First of all, in the default Hyper-V MPE 2012 SCOM MP there are a lot of nice things and monitors. One of them, however, is missing from this bunch. This is the CPU Wait Time Per Dispatch. This counter is read from the Virtual CPU instance of the Hyper-V host. The counter itself means “how much time does it take before my vCPU can get some real CPU time”. In VMWare they call this the CPU Ready counter by the way. One of our consultants mentioned we need to monitor this thing. So, all good and well, let’s get to it!

Within SCOM I will show you two things, basically eveyone can do this. How to create a rule for measuring Performance. This will output some nice graphs and might be handy in troubleshooting or judging performance base lines. After that we’ll be making a Monitor to send out alerts if VM’s bite of more than they can chew.

First, the rule. Start by creating a new Performance Based Rule and select your destination management pack.

2014-11-21-14_58_05-SCOM-log

The target for this rule is not a default target, so don’t forget to select “View all targets” and search for the Hyper-V MPE 2012 Virtual Processor:

2014-11-21-14_58_58-Create-Rule-Wizard

After that, set the counter to “CPU Wait Time Per Dispatch”. This name is exactly as it comes from the perfmon counters (really weird huh…?), so type that in. This way you can also create other counters if you’d like to do that 🙂

As a rule of thumb I set the interval to 5 minutes. You shouldn’t go to fast because you will take up too much time processing all the requests. The other Hyper-V MP rules also are set for five minute intervals in most case, hence my choice. For the target select “VP Instance” from the Arrow-ed menu. Also, type in the object manually. I’ve done this whole rule based on the “% Guest Run Time” rule (which is bullocks if you ask me) and it was in there like that. I figured I’d do that too.

2014-11-21-15_02_14-SCOM-log

Well, next and finish!

For the performance view I used the following settings. Note the “Show data related to” setting. Select your rule, et voilá! It can take some time before the stats start piling up. In my case I had to take a big lunch break of about 45 minutes…

2014-11-21-15_10_32-SCOM-log

After that, we create a Performance Based monitor. It’s a single treshold monitor, nothing too fancy. I like to use consectutive samples because that way you can tweak your monitor pretty good when all is setup. It allows for maximum flexibility when overriding.

2014-11-21-15_11_28-SCOM-log

I like my custom monitor disabled so I can tweak a bit before I turn them on, your choice!

2014-11-21-15_12_02-SCOM-log

Here I also set the interval at five minutes because I will override the monitor anyway when I enable it.

2014-11-21-15_12_44-SCOM-log

I basically set the monitor to 100.000. From what I’ve seen, a starting VM will rise up to about 80k and running VM’s between 30k ~ 50k. But you can see for yourself and see what counters work for your enviroment.

2014-11-21-15_13_04-SCOM-log

I like to see this as a warning. After all, your VM is just like a snail breaking before a corner, but it’s still working.

2014-11-21-15_13_16-SCOM-log

And finish up by making a really cool message of sorts.

2014-11-21-15_13_33-SCOM-log

So, after this, override the Monitor to whatever group you see fit. Here’s an example of a performance graph (these machines just restarted after a Host reboot):

2014-11-21-15_23_14-Hyper-V-CPU-Wait-Time-Per-Dispatch-SCOMMZH-Operations-Manager

Leave a Reply