What Is It?
NSCA-ng is a drop-in replacement for NSCA. It provides a client-server pair which makes the command pipe accessible to remote systems. This allows for submitting passive check results, downtimes, and many other commands to Nagios or Icinga. Multiple check results or commands can be submitted in one go, and multiline plugin output is fully supported. NSCA-ng uses TLS encryption and shared-secret authentication with per-client passwords, as well as fine-grained authorization control. It's written in C and should scale very well.
The NSCA-ng client (
send_nsca) accepts all input, command line arguments, and configuration files accepted by the
send_nsca binary provided with the original NSCA package. NSCA clients cannot talk to NSCA-ng servers (nor vice versa), but NSCA and NSCA-ng servers can happily run side by side.
However, if your distribution doesn't provide a package, you can build NSCA-ng from source like this:
The NSCA-ng server then needs to be configured in
/etc/nsca-ng.cfg or (if you installed from source)
/usr/local/etc/ncsa-ng.cfg, see the comments in that file. The NSCA-ng client is configured in
If you installed the NSCA-ng server from source, you'll want to make sure it's started on boot. An example script for starting and stopping the daemon is provided in the
contrib directory of the source tarball.
Migrating from the Original NSCA
The original NSCA package uses a global password and permits all clients to submit arbitrary check results. If you'd like to start off with such a setup, you could use an
nsca-ng.cfg(5) configuration such as the following:
Existing scripts can then use NSCA-ng's
send_nsca without modification, unless they specify the NSCA port number using the
-p flag. The original NSCA uses port 5667 and NSCA-ng uses port 5668 by default.
A wrapper script such as the following could be used to call standard plugins and transmit the results via NSCA-ng.
Other commands can be submitted like this:
This assumes the server authorized the client to submit such a command, e.g.: