Passing parameter to check

Hi,
I use Icingaweb2 to check my Linux servers. I install agent on my Linux server. When I made a «service-set» with «load» check command, I want to ajust the warning or critical parameter.
How can I do that ? Do you have doc that explain how to do that ?

Hi Alain,

I was about to paste something, but I don’t want to accidentally go down the wrong rabbit hole here. Can you clarify what the command you’re executing is (included or written yourself), where it runs, and if it takes any arguments? Not sure if we’re looking to tweak the Icinga config or standard Nagios plugin best-practices here.

Hi
Icingaweb2 is just an interface, so it does not actually does any monitoring, icinga ( the core is doing that), and if you are using the UI to configure checks, that means you are using Director.

To alter warning / critical thresholds in Director, you will need to define a custom field an associate it to the service check in which you want to apply that change.
You can find the detailed documentation on how to do that in Director here: https://icinga.com/docs/director/latest/doc/12-Handling-custom-variables/

Hi,

welcome to the community. Just a gentle tip up front: Pick a category when creating a topic which fits your question. #community isn’t really the one, #icinga-2-core fits better for questions towards check parameters.

General understanding on threshold parameters mapped into the Icinga configuration helps here. Since you’ve mentioned service sets, I’d assume that you want to have that within the Icinga Director.

First off, navigate into the Commands > External Commands section and search for the load check command. This one is imported from Icinga’s template library from the core. Other commands may be created by yourself.

In order to work with parameters from services to check commands, you’ll need to export the ones which are needed. This might be complicated but serves a good purpose: Admins can define which parameters are available while users are just allowed to use the existing ones. That way one can implement a real RBAC model with permissions into the Director, large companies require that.

Anyhow, click the load command and choose fields. Now pick the warning threshold parameter and save it. Repeat this for the critical threshold parameter. This way you’ve exported the data fields for these check commands.

Now go back into your service set, specifically modify the load service. Within the custom properties tab, you can now select the previously exported parameters and set them to values of your desire.

You can either do that in a service template or service set service, doesn’t really matter. I’ve added both examples clicked in my Vagrant box.

The procedure is always the same - define the command parameter fields first, then use them in your templates and service apply rules and sets.

Cheers,
Michael

1 Like

What if the external command lists command-line options, and even variables, but those don’t show up in the ‘Fields’ drop down?

I’m basically trying to find how to specify that I want httpS, not plain http. It’s the ‘http’ check command either way. In the ‘Preview’ for ‘http’ under Director > Commands > External I can see “vars.http_ssl = false”, but nothing with ‘ssl’ in it shows up in the Fields tab.

Debian buster/10.1 system with:

icinga2 & icingaweb2 (and dependencies) installed from the Debian packages.
director (and dependencies) git clone’d and checked out on their latest tag.

In that case you can prepare such simple (and even pretty advanced) Fields when going from the Director Dashboard to “Define Data Fields”. Please have a look at the example in the documentation to get an idea of the available possibilities.

For http_ssl I’d suggest to create a boolean field. The Dropdown tries to guess what might be useful, but it doesn’t offer all the possibilities you get when explicitly creating them. We want to unify this in future, allowing you to have that “full power” in place right next to the wizard you’ve been using. A dedicated issue already exists on GitHub.

But you’ll see, after the first couple of fields - the current mechanism isn’t that bad :wink:

It would be helpful to include the Nagios plugin man page parameters in the presented default Description field text of the Service Template> Custom Fields. For example, if one wants to specify the check_disk plugin mount point parameter

-M, --mountpoint
    Display the mountpoint instead of the partition

the existing options in the Field dropdown box and their Description text are vague. I offer this proposal here for discussion prior to asking for an enhancement change, as I am a new user.

Many contributers use the text from the --help output in ITL command definitions. Most of the time they are enough to get a reminder what is what. By far not all plugins have their own manpage.

During normal operational you just need a simple reminder most of the time and putting longer text might clutter up the interface. That’s just my personal opinion, though.

If you want to change or enhance texts you’re always welcome to file an issue and a pull request or provide a patch. I like your approach of asking first so it can’t be that you invest a lot of work and it would be declined.