Adding Scheduled Tasks Collector

[mousavian]

Adding a new collector called scheduled_task that can be enabled to provide metrics about registered tasks configured in the Windows Task Scheduler Service. ( #808 )

[mousavian]

Any idea why CI failed? Not sure why it's still trying to download go-ole v1.2.1 while this PR suggests higher version in mod file.

[breed808]

This looks rather nice! I'll admit my knowledge of the Win32 API is lacking, so I'm not able to adequately review most of the getScheduledTasks() function. @carlpett could you take a look?
Documentation is also very good, thanks for putting in the effort for that 👍

You're right about the CI, I've been able to compile this PR locally with no issues. We may need to re-trigger the CI build to see if it's a repeatable error.

[carlpett]

Very nice! I have some questions on the OLE stuff, but generally 👍

[carlpett]

As getScheduledTasks is called on each scrape, do we need to run initialization every time, or would it suffice to do once? I'm somewhat concerned about interactions with how the WMI library uses OLE as well, and especially with calling CoUninitialize.

[carlpett]

Also, we need to consider concurrent scrapes.

[mousavian]

Based on my understanding and a little bit research on this:

• The Go-OLE suggests to use CoInitializeEx function instead of coInitialize. The reason is explained here.
  On the other hand, the WMI library has already initialized the connection with COINIT_MULTITHREADED value, therefore we have to follow the same.

• Microsoft website has explained here about how multiple initilizations and Uninitialization calls work, which is addressing your concern on the interaction of the existing WMI with this implementation:

  CoInitializeEx must be called at least once, and is usually called only once, for each thread that uses the COM library. Multiple calls to CoInitializeEx by the same thread are allowed as long as they pass the same concurrency flag, but subsequent valid calls return S_FALSE. To close the COM library gracefully on a thread, each successful call to CoInitialize or CoInitializeEx, including any call that returns S_FALSE, must be balanced by a corresponding call to CoUninitialize.

• Locking OS thread to minimize the number of connections (possibly sharing with WMI) and preventing the "communication" and "connection" happening on different threads, if any.

• do we need to run initialization every time? Good point, apparently not.
  The process which WMI has implemented includes creating and keeping the connection upon starting the application, and just running subsequent queries after that. I assume this is reliable enough(?).

I have updated the code according these.

[carlpett]

This looks very nice to me now, except one thing I missed earlier. With that fixed we'll be good to go :)

[mousavian]

I have rebased this... should be ready to merge :)

[carlpett]

Nice, thank you!

[breed808]

@Gerrit0284 this change hasn't yet made it into a new release yet; this was implemented after v0.18.1.
You can wait for a new release, or build the exporter from master.