I needed to be able to send reports back to NSCA easily from Perl programs (and without needing to go through the send_nsca program that comes with NSCA). I came across Net::Nsca, which mostly works, besides for the fact that I need to change the packet version in the code to 3 (which is not easy to do since it wasn’t made to be changed).

I decided to make my own NSCA client, using Moose and would be hopefully more flexible. A sort example of sending a report in some routine in a server would be:

sub nsca_heart_beat {
    my ($self) = @_;
 
    $self->nsca_client->send_report(
        hostname => $self->hostname,
        service  => 'server',
        message  => 'Running',
        status   => $Net::NSCA::Client::STATUS_OK,
    );
 
    return;
}

This is good and all, but not really a killer feature by any means. What really is a winner here is the Net::NSCA::Client::ServerConfig class that was added in version 0.007. One of the biggest problems with NSCA is that what is sent over the network is not portable. Yes, the data is made to be aligned in network order, but it actually sends a native C structure over the network. The problem is what happens when the server and client happen to compile different structures? This is what ServerConfig is for. It also makes it easy if it any of the constants defined in the NSCA source files were changed when NSCA was built. This client is the only one of the currently three others on the CPAN to support this.

I’ve currently been working on this module in my spare time and coming up is support for encryption methods besides XOR (like AES) as well as complete support for the standard send_nsca.cfg configuration file, plus much more.

My current thoughts on support for getting performance data from the remote page would be to just scrape it from the standard plugin output, which is supported as the body:

PLUGIN OK - Good to go! | time=0.012s;1;10;10;0

I was also thinking about how to add support for receiving as headers, since the other supported aspects of the plugin may be transmitted as headers. My current thoughts are for a header named X-Nagios-Performance which would hold the name=value pair, separated by spaces like the normal plugin and would also allow more than one header with the data to be present:

X-Nagios-Performance: time=0.012s;1;10;10;0
X-Nagios-Performance: count=2;;;50;0 other=4;;;4;0

For Nagios::Plugin::OverHTTP itself, since the remote plugin can provide critical and warning thresholds, I was thinking of allowing for actually changing the status based on that to be made optional by default (because if the remote plugin said the status was OK but yet a performance metric it sent said that it should really be in a WARNING state, by default Nagios would have kept that as OK so I believe that my plugin should honor that as well by default). New options for the plugin would be:

--warning name=threshold
--critical name=threshold
--use-transmitted-thresholds
--override-transmitted-thresholds

The last option --override-transmitted-thresholds would cause the performance data written as the plugin’s output to be changed to match the thresholds given as the plugin’s options. This means a plugin with the given options --override-transmitted-thresholds --critical time=4 would cause the performance data to say time=0.012s;1;4;10;0 instead of time=0.012s;1;10;10;0 (note that this setting does not affect the decision of the final status code).

define command{
        command_name check_over_http
        command_line check_over_http --url=$ARG1$ $ARG2$
        }

This means the following would need to be in a service definition:

define service{
        use                            noncritical-service

        host_name                      server1
        service_description            Connection to MySQL
        notes                          Checks if the server can connect to remote MySQL
        check_command                  check_over_http!http://server1/nagios/check_remote_mysql
        }

As you can see, the check command duplicates the hostname, which is not the way of Nagios plugins. Now With version 0.04 and up, we can have the following definitions:

define command{
        command_name check_over_http
        command_line check_over_http --hostname=$HOSTADDRESS$ --path=$ARG1$ $ARG2$
        }

define service{
        use                            noncritical-service

        host_name                      server1
        service_description            Connection to MySQL
        notes                          Checks if the server can connect to remote MySQL
        check_command                  check_over_http!/nagios/check_remote_mysql
        }