-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature-Request] Invoke-IcingaCheckScheduledTask - involve also information from Cmdlet "Get-ScheduledTaskInfo" #208
Comments
Hello, thank you for the idea. This is definitely something we can add to the default plugin. I will have a look on this on how we can add this globally, without the runtime of the plugin exploding (which is my current fear, but it could be fine at all) |
Thank you. BTW: If you ware wondering why I use [void] instead of Out-Null (like mentioned in your doc) in my code: Because Microsoft recommand this in following paragraph: |
I created two PR's for this - one inside the Framework and one inside the plugins. Could you please test both and ensure that monitoring, thresholds and everything related is working as expected? Documentation and plugin configuration have been updated as well inside the PR. For the Therefor I personally recommend |
Thanks for the fast change! I will test this the next few days. And about |
You are welcome :-) I will have a look on some core aspects of Icinga for Windows - maybe we can gain additional performance by removing Thanks for the input! |
I tested the check and really like the output. Very detailed information! 👍 Only a small note to "last task result": If you compare the output in the task scheduler, you'll see there is written the return code as hex notation. The same in the official docs: https://docs.microsoft.com/en-us/windows/win32/taskschd/task-scheduler-error-and-success-constants. I think if somebody is searching the error code in the web, it's a little bit easier to find solutions. I don't know how you see it? I'll took some diffrent Microsoft tasks from task tree \Task Scheduler Library\Microsoft\Windows. E.g.
and deployed the service to a Windows Server 2012R2, 2016 and 2019 server. If the task ist not configured or named in diffrent way, the check doesn't work and quits with following exception: |
Thank you for the input. I just updated the PR on plugins with a new version. The issue should be resolved now. For the error: It is using the hex code. I assume in your case the error is 0x000420. I'm not adding a 0x before and 0 before seems to be removed. It should match the exit code in your scheduled tasks. |
Thank you, looks good now! Yes the error code matches. My intention here is, if somebody mabe not recognize on the first view, that it's the same number because of diffrent notation. ;-) But it's ok, if it's not possible to change the behaviour. |
Thank you very much. For some reason, PowerShell interprets the hex value always to 420 for example at the moment. For the moment, this is sadly not possible. |
Feature: Adds array thresholds and date time support Adds support to parse arrays to Icinga Check thresholds functions like `WarnOutOfRange` and adds two new functions `WarnDateTime` and `CritDateTime`, for easier comparing of time stamps. Required for new `Invoke-IcingaCheckScheduledTask` features requested on [Plugin Feature Reqest #208](Icinga/icinga-powershell-plugins#208)
Now the check Invoke-IcingaCheckScheduledTask only use the PowerShell-cmdlet "Get-ScheduledTask". This one has as return the value "state" for monitoring. If you really want to check if a ScheduledTask works correctly and as expected, you have to involve the Cmdlet ""Get-ScheduledTaskInfo". This returns following two values, which are more usefully and meaningful for monitoring: LastTaskResult and LastRunTime.
With the solutation now you can only say which state you expect. But e.g. you expect "Ready" this doesn't say anything if the the task is really running nor if work correctly. If I'm correct, you will catch only an error if the a script which the task triggers produces an endless loop and as a result the state is "running". Or vica versa if you expect "running" but for some reason the task is "ready".
E.g. this is a standard task from Microsoft:
As you can see this task is ready but has as last run result 0x800710E0. In such cases the check would be ok.
And as an example for LastRunTime: If you configure a task that it should run every hour. but for some reasons the task doesn't run (config error or what ever) like this, the state is still ok. So you won't recognize that something is wrong.
For us I expand the check with fowolling code:
The result looks like this. For us this is ok, but maybe you have better ideas.
The text was updated successfully, but these errors were encountered: