Odd behavior of cpu-load check
asachs01 opened this issue · comments
Greetings Windows folks! I'm trying to wrap my mind around and issue that I'm seeing with the cpu-load ps script.
I'm testing the scripts out using @samroy92 's asset version of the plugin (https://github.com/samroy92/sensu-plugins-windows) and seeing some odd behavior.
When using this check from the readme:
---
type: CheckConfig
api_version: core/v2
metadata:
namespace: default
name: win-cpu-check
spec:
command: powershell.exe -ExecutionPolicy ByPass -C check-windows-cpu-load.ps1 90
95
subscriptions:
- windows
handlers:
- slack
- email
runtime_assets:
- samroy92/sensu-plugins-windows
interval: 10
publish: true
Sensu only ever shows a warning, even if the load is over the threshold:
However, if the full path to the check executable is provided, the check will return a critical status as expected.
Since my knowledge of Windows arcana isn't great, I was wondering if anyone else had seen this sort of behavior. I'm not quite sure if this is pathing (seems like it's not), or something in the way that the script itself is handling things.
Looking at the logic, the condition is greater than, where this is equal so reports as warning. This does seem to be a bit ambiguous and should probably be updated to be greater than or equal to.
The equal to is probably good to add, but I don't think that is why we were seeing the issue. I've seen this with more than just the CPU check. The RAM check also behaves similarly. You can see in these two screenshots that if I hardcode very low thresholds to force a critical status, it still will show that it exits with a warning, despite the check output showing a critical status.
It only seems to behave this way when you're using an asset and using the command Scheme "powershell.exe -ExecutionPolicy ByPass -C [check-name].ps1 [warn] [crit]"
If you use the -File flag and specify a path, it the status will match the check output's status, but then it defeats the nice advantage of not having to specify a path when using assets.
The documentation provides that -File is used because the -C argument is actually -Command which expects "as though they were typed at the PowerShell command prompt." In this case, I would see if . calling the check behavior similar to calling the check via -File
I understand the -C vs -File switches. Using -File works, and is the workaround I'm using at the moment. I would like to use -C if possible so I don't have to specify a path. Looking at the documentation on this page, it looks like you should be able to use the -C switch without using a path. Using -C also works fine with metrics, but those don't really have exit statuses of 0, 1, or 2