Thresholds\alert rules on services created by an agent custom script

General
1

Checkmk Raw Edition 2.4.0p17

I manually added a custom script to this pfsense agent installed on a monitored pfsense host: GitHub - albertfont/checkmk_agent_pfsense

The custom script works and it adds to the pfsense host some services with counters\graphs via
echo "<<<local>>>"

How can I add thresholds to change the services status to warn\crit according to the counters values?

I guess this is a generic question on how to apply thresholds using checkmk rules in the web gui, when services are created and checked by custom scripts.

2

In your case (local check) you can only apply thresholds in the output of your local check.

The general syntax of a local check output is described here Local checks
Important for your problem is the section “Dynamic calculation of state”, here you find information how to modify the local check output to also include thresholds.

3

Any way to not hardcode the thresholds values in the script? i.e. is there a way to pass parameters from the checkmk server (preferably via the gui) to the script running on pfsense?

I suspect I’m basically asking the same question I asked before, so I’m expecting a “no way” answer…

Thanks.

4

There is a way if you use the enterprise edition with the agent bakery feature.
If you have a bakery rule where you can specify parameters (that also need to be build first) that results in a config file for your agent script.

With Raw edition as you use it you need to rewrite the script to be an agent plugin and then you have to build an check for this agent data on the CMK server side. That’s way to much work for a single check. If i had many of these devices with the same local check then i would migrate it to an agent plugin that can have then check parameters.

5

It’d be really nice if CheckMK had a generic mechanism for local checks that modifies the service’s state depending on arbitrary metrics & thresholds (arbitrary in the sense that thresholds should be configurable for any of the metrics provided by that service, not for metrics of other services). That’d allow for fully centrally managed state decisions.

I’m not a fan of having to bake host-specific config files into agents… first of all you have to write bakery code for that. Next it’ll blow up agent build times as each custom config results in yet one more agent having to be baked. Takes long enough already.

6

That’s exactly what i was hoping for.

Actually, I was hoping for a generic rule type that would apply to all services\checks.

This rule type would have the usual conditions (folders, host, service, etc), plus an additional condition to match the desired metric name.

The rule would then have fields where one would type the warning\critical threshold values

7

To solve this now I would move this check to a agent based plugin ( Developing agent-based check plug-ins ). With this you have all the flexibility you need.

To add a new feature for local checks to CheckMK, best would be to add it to the ideas portal (https://ideas.checkmk.com/).

8


Before I try do do that, can anyone confirm that an agent based plugin will work with this non standard checkmk agent?
GitHub - albertfont/checkmk_agent_pfsense

9

The mentioned agent has the plugin logic inside. Easy test for you is –> put a script inside the folder “/usr/lib/check_mk_agent/plugins/” and check the agent output if you see anything from the test script. If you see some output the agent plugins are executed.

10

Thanks Andreas.
It works.
The correct base dir is this and I had to create it

set_variable_defaults() {
    : "${MK_LIBDIR:=/usr/local/lib/check_mk_agent}"

Not sure it’s safe to use /usr/local/lib/check_mk_agent, because i wonder if this directory will be pfsense-upgrades resiliant.
The guy who forked the agent decided to put the agent in /opt/bin instead.

Not knowing how to add a custom script to an agent, i originally added my script by inserting some lines to the end of the original agent code that trigger my script and I saved my script in /opt/bin as well.