Client Monitoring // Successor of NSCA

General
1

Dear everybody

client computers / notebooks are characterized by the following criteria:

  • they are turned on/off at unpredictable times
  • they might come online under different IPs (via WiFi, Ethernet or VPN; IPs might be dynamic via DHCP)
  • you might not want to have a port open, listening on an external interface - especially for security reasons or because corporate policies do not allow this

However there are some topics worth monitoring on clients, such as filesystems filling up or pending updates.
Reporting problems on these usually is not super time critical - delays of several hours or a few days are acceptable in the most cases.

It has proven to be a good way to deal with the challenges above by executing the checks on the client locally, e. g. via systemd timer or via a cronjob and report the result back to Checkmk. On the server they are simply defined as passive checks with freshness checks.

In the past results from the clients could be transported to the Checkmk server via NSCA.
However, I understand in newer Checkmk versions NSCA is not integrated any more.

What is now the supposed method for transporting check results from clients to Checkmk?

2

Use the Checkmk agent. Deactivate notifications for such hosts.

3

As @martin.hirschvogel said the normal CMK agent or if you use the Ultimate version you could also use the Push Agent. Then only data is sent if the host is online.
In booth situations you need to define some rules for the CheckMK service as this goes to critical if the system is not reachable or does not sent data over a longer period of time.

4

I’m afraid, I not yet completely understood your suggestion: How do I deal with the problem of changing IP addresses in this case?

5

No, I don’t have Ultimate. How is push realized in the community edition?

6

in general, checkmk was built for server and network monitoring.
for client monitoring, i think a pull based approach is very challenging if the systems don’t have fixed IP, which you likely don’t have.
that’s why the push based approach is from my opinion the only valid one for client monitoring. push-based monitoring is an ultimate-exclusive feature

7

That’s really a pity! Checkmk provided a very proper monitoring solution for clients too in the past (see my description above) in all editions, including community.

Then - due to a very questionable product decision - NSCA was removed and all other editions besides ultimate in that step was stripped down to provide “server only” monitoring!

:frowning:

8

I do it that way (but don’t tell my boss)… On the host, as cronjob and maybe additionally in /etc/rc.local to run at boot:

cmk-agent-ctl dump > hostname.txt
rsync -avHP hostname.txt someuser@checkmk.mydomain.test:/tmp/

Then on the Checkmk server configure a data source program that just does cat /tmp/$HOSTNAME$.txt. And as host check command just a test for a certain age.

9

NSCA was rarely used from our research. Not maintained upstream anymore. Hard to justify why we shouldn’t drop it. See: Werk #13644: Deprecating NSCA as part of Checkmk
At least I wasn’t pinged on any support ticket which really couldn’t live without NSCA anymore. Maintaining unsupported software doesn’t come for free, so we have to make such decisions.

For your case:
Just install nsca on your checkmk site, configure it. Your clients have send_nsca already anyway.
Keep in mind: there is a reason why we removed it (libmcrypt is dead). Do at your own risk.

Alternatively, you could also probably use “Integrate Nagios plugins”, leave everything unset but check freshness. Then use from livestatus PROCESS_SERVICE_CHECK_RESULT. That might work as well.