Datasource to monitor Windows Services/Processes automatically?

Please ignore my above post ... dont know what i was thinking.?

Thanks Mike , Vitor & Stuart for this datasource. Much Appreciated

Notice there is a ProcessID normal datapoint which doesnt have any threshold value set. We can alert if there is no data available which can mean the process is not running but if we want to setup alert trigger interval what would be the alert threshold?

Can we configure something like below as a complex datapoint? 

On 4/21/2020 at 11:53 PM, Stuart Weenig said:

set 0=OK and 1=Not OK

On 4/17/2020 at 2:00 PM, Mike Moniz said:

set 0=OK and 1=Not OK

This is exactly what I attempted to do, but I took it a step further. The WMI collector polls the string contained in status/state and checks for presence of one good value. Since this version is groovy, we can enumerate like this:

//Enumerations obtained from https://docs.microsoft.com/en-us/windows/win32/cimwin32prov/win32-service and put in my preferred order so that they are in ascending severity. This allows thresholds for >= 1 3 5.
stateEnum = [
  "Running",
  "Start Pending",
  "Stop Pending",
  "Continue Pending",
  "Pause Pending",
  "Stopped",
  "Paused",
  "Unknown"
]

statusEnum = [
  "OK",
  "Error",
  "Degraded",
  "Unknown",
  "Pred Fail",
  "Starting",
  "Stopping",
  "Service",
  "Stressed",
  "NonRecover",
  "No Contact",
  "Lost Comm"
]

I took all the possible values and tried to sort them into ascending order of problem so that 0 is the optimum state and the higher the number, the higher the criticality of the problem.  If you have suggestions on a better, I'm completely open to reordering this.

1 minute ago, Stuart Weenig said:

Yes, that needs to happen. Otherwise, this metric is very much like CPULoad in Linux boxes, where 100% = one fully loaded core. The thing is that you can't just divide by the number of cores, because you don't know for sure that the threads are split evenly across cores.  

Oh I see.
Well, I guess despite that, diving by the number of cores will reflect the process usage on the whole CPU anyways, right?
Even if it's not split evenly, that calculation will reflect the actual process use over the CPU (in a whole). Maybe I'm confusing.
 

Another suggestion for the services check, although this does deviate from the existing WinServices- check is instead of doing 0=Not OK and 1=OK, is to set 0=OK and 1=Not OK. Several other LM Datasources generally work this way in that the larger the number the more urgent the problem so you can do thresholds like > 0 1 2. In this case it that doesn't matter since it's binary option, but it also helps with widgets like table color bars where < does not work very well or gauge widgets and others that also seem to assume this.

Just now, Vitor Santos said:

I guess we need to divide that number by the number of CPU Cores for the server in question.

Yes, that needs to happen. Otherwise, this metric is very much like CPULoad in Linux boxes, where 100% = one fully loaded core. The thing is that you can't just divide by the number of cores, because you don't know for sure that the threads are split evenly across cores.  

12 minutes ago, Stuart Weenig said:

So, this is what I ended up with (publishing to GitHub after a bit more data is gathered). Notice PercentProcessorTime is a counter and the formula on the complex dp.

Thanks a lot for sharing!

I've applied that to my datasource as well. 

By checking the values against a process that's currently consuming 30-36% of the CPU, it's returning values like '143.5667' for that ProcessCPUPercent.
I guess we need to divide that number by the number of CPU Cores for the server in question.

In my case the box I'm testing that has 4 CPU Cores, which results in a value of 35.89%.
It seems to reflect the actual usage of the process (shown in Task Manager) ?

So, this is what I ended up with (publishing to GitHub after a bit more data is gathered). Notice PercentProcessorTime is a counter and the formula on the complex dp.

1 minute ago, Stuart Weenig said:

like too small by a factor of 10 or 100.

Duh, i need to multiply by 100 to convert it to percent.

7 minutes ago, Mike Moniz said:

I think you need to query the value twice over a set period

This is exactly what changing the datapoint to type counter does. It takes the delta between the current polled value and the previously polled value and divides by the time between the two polls.

The results i'm getting are pretty low, like too small by a factor of 10 or 100.