Wednesday, 6 December 2017

Nagios and NRPE - There's more ...

Following on from my earlier post: -

things are starting to become more clear.

As far as I can establish, on the NRPE client/agent side, we have several components at work here.

So we have the NRPE agent itself, as started using xinetd : -

# default: on
# description: NRPE (Nagios Remote Plugin Executor)
service nrpe
        flags           = REUSE
        socket_type     = stream    
port = 5666    
        wait            = no
        user            = nagios
group = nagios
        server          = /usr/local/nagios/bin/nrpe
        server_args     = -c /usr/local/nagios/etc/nrpe.cfg --inetd
        log_on_failure  += USERID
        disable         = no
# only_from       =

and then we have the command(s) that we want to invoke from the Nagios server itself: -

ls -1 /usr/local/nagios/libexec


and then we have the configuration file that acts as the lookup/aliasing agent: -

cat /usr/local/nagios/etc/nrpe.cfg

command[check_users]=/usr/local/nagios/libexec/check_users -w 5 -c 10
command[check_load]=/usr/local/nagios/libexec/check_load -r -w .15,.10,.05 -c .30,.25,.20
command[check_sda1]=/usr/local/nagios/libexec/check_disk -w 20% -c 10% -p /dev/sda1
command[check_zombie_procs]=/usr/local/nagios/libexec/check_procs -w 5 -c 10 -s Z
command[check_total_procs]=/usr/local/nagios/libexec/check_procs -w 150 -c 200

This means that, from the Nagios server, I can invoke any of the above commands: -

/usr/local/nagios/libexec/check_nrpe -H -c check_users

USERS OK - 2 users currently logged in |users=2;5;10;0

/usr/local/nagios/libexec/check_nrpe -H -c check_load

CRITICAL - load average: 0.39, 0.24, 0.17|load1=0.390;0.150;0.300;0; load5=0.240;0.100;0.250;0; load15=0.170;0.050;0.200;0; 

/usr/local/nagios/libexec/check_nrpe -H -c check_sda1

DISK OK - free space: /boot 274 MB (55.29% inode=100%);| /boot=222MB;396;446;0;496

/usr/local/nagios/libexec/check_nrpe -H -c check_zombie_procs

PROCS OK: 0 processes with STATE = Z | procs=0;5;10;0;

/usr/local/nagios/libexec/check_nrpe -H -c check_total_procs

PROCS WARNING: 185 processes | procs=185;150;200;0;

/usr/local/nagios/libexec/check_nrpe -H -c sayHello

Hello, World!

/usr/local/nagios/libexec/check_nrpe -H -c diskFree

FREE SPACE OK: '/' is 26.00% full

From a Nagios console perspective, I can define all/any of these

sudo vi /usr/local/nagios/etc/servers/mfp.cfg 

define command {
        command_name                    check_nrpe_with_args
        command_line                    $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$

define service {
        use                             generic-service
        service_description             Check_Load
        check_command                   check_nrpe_with_args!check_load
        notifications_enabled           1
define service {
        use                             generic-service
        service_description             Hello_World
        check_command                   check_nrpe!sayHello
        notifications_enabled           0
define service {
        use                             generic-service
        service_description             Disk_Free
        check_command                   check_nrpe!diskFree
        notifications_enabled           0

sudo systemctl restart nagios.service

and then check the Nagios dashboard: -

Finally, purely for the record, whilst the shipped plugins are mainly C/C++ binaries e.g.

file /usr/lib64/nagios/plugins/check_disk 

/usr/lib64/nagios/plugins/check_disk: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0f75d7633e74455320d40f0b75071f8eabe148de, stripped

but I also have a Perl script: -

file Perl script, ASCII text executable

and a Python script: -

file Python script, ASCII text executable

( kudos to Linux Magazine for this latter script )

No comments:

Yay, VMware Fusion and macOS Big Sur - no longer "NAT good friends" - forgive the double negative and the terrible pun ...

After macOS 11 Big Sur was released in 2020, VMware updated their Fusion product to v12 and, sadly, managed to break Network Address Trans...