Understanding (Windows PS) Plugins, Icinga2Agent and Director

[opendev]

Hi,

I am currently taking my first steps in Icinga2 to understand the construct in its entirety and, if necessary, have it fully implemented/implemented in our company at a later date. Essential for this is a) the involvement of the director, because my colleagues can’t find their way around on the basis of comma lines and b) of course external checks using plugins on Windows machines.

While I successfully completed the first part with the installation Icinga2, Icingaweb2 and Director with the help of the Netways webinars and also the construct from commands->templates->service templates->host templates->etc. … it still hangs at the second point.
Since this would be an interesting point at the moment, I have the check_exchange_powershell
(https://github.com/NETWAYS/check_exchange_powershell) plugin and would now like to implement it for testing purposes. The Icinga2Agent runs on the Exchange and also memory and disksize are already checked successfully. The problem is that I can’t find any instructions or explanations on how to integrate such external plugin commands into the directory. Maybe I overlooked something, I don’t want to exclude that, but somebody would have to show me this place. But now I’m a bit helpless and can’t reach the point to include checks beyond the standard.
I would be happy about a small (or big) tip.
Thanks in advance.

Greetings

[rsx (Roland Sommer)]

Powershell for the first run is a bit tricky, you might have a look at Infos at Monitoring Portal.

First, you need a new CheckCommand that is used for every new service definition. This definition needs to be available on all instances (master/satellite(s)/client(s)), therefore, it’s recommended to create a new global zone e.g. windows-commands. To do so you need to add this zone to every instance’s zone config, create a folder e.g. /etc/icinga2/zones.d/windows-commands and put the CheckCommand conf file there (it will then be distributed by icinga2 to every satellite and client that have that global zone configured).

Second, you need to place check_exchange_powershell on the corresponding client (or “misuse” the the icinga config distribution - like I do - and place the check script in the windows-commands folder).

Third, you need a service check definition usally “apply Service” to define a new check object for that check.

[opendev]

Thanks Roland, you’re link helped a lot. Now I understand how to use the icinga2-commands.conf in director (hopefully there is an easier way to implement the commands in the director instead of creating it by hand). I’ll give it a try implementing the command and creating the service, etc. now. Hope it will work. Thank you.

Regards

[dnsmichi (Michael Friedrich)]

Interesting, I thought we’ve migrated all howtos. Obviously not, it is now located here: Windows PowerShell Checks with Icinga2

Since the question targets the Director, you’ll need to figure out the command parameters first, e.g. by calling it on the command line. Once you’ve extracted such, you can start with the Commands tab inside the Director.

Add a new “plugin check command”, give it a name, and set the command to powershell.exe including its path, similar to what https://github.com/NETWAYS/check_exchange_powershell/blob/master/icinga2-commands.conf describes (you of course include this once in your icinga2.conf, restart icinga2, and let the Director treat this as external command - the better way is to integrate it into the Director natively).

Then put that command in the global-templates cluster zone.

The arguments tab now appears, and you can start adding the arguments as key-value pairs following the model here: https://github.com/NETWAYS/check_exchange_powershell/blob/master/icinga2-commands.conf#L10

Change into the Fields tab and make the script parameter mandatory.

That’s the base powershell command, now you’ll need to put in the script actually being executed. You can do so either by setting powershell_script as data field (needs to be defined first) in your services, or you’ll create a new CheckCommand object which imports this one, and sets this parameter (preferred).

Add a new CheckCommand, import the existing one and set powershell_script to a default value.

Then hit deploy, to see that the configuration is actually rendered.

Next up, define a new service which uses the powershell plugin (and set the correct path of course).

First, go to “Define data fields” and verify that powershell_script is defined there.
Second, define a service template which uses the check_command and may override the custom properties for powershell_script.

The task left for you is to actually create the service apply rule / set then and see this working

Cheers,
Michael

PS: The steps I’ve done here are reproducible with the standalone Vagrant box.