Monitor Remote Linux Host using Nagios:

Configuration steps on the Nagios monitoring server to monitor remote host:

Download NRPE Add-on:

Download nrpe-2.12.tar.gz from Nagios.org and move to /home/downloads:

Install check_nrpe on the nagios monitoring server:

# tar xvfz nrpe-2.12.tar.gz
# cd nrpe-2.1.2
# ./configure
# make all
# make install-plugin
./configure will give a configuration summary as shown below:

*** Configuration summary for nrpe date ***:

General Options:
————————
NRPE port: 5666
NRPE user: nagios
NRPE group: nagios
Nagios user: nagios
Nagios group: nagios

Note: I got the “checking for SSL headers… configure: error: Cannot find ssl headers” error message while performing ./configure. Install openssl-devel as shown below and run the ./configure again to fix the problem.

# rpm -ivh openssl-devel-0.9.7a-43.16.i386.rpm krb5-devel-1.3.4-47.i386.rpm zlib-devel-1.2.1.2-1.2.i386.rpm e2fsprogs-devel-1.35-12.5.

Verify whether nagios monitoring server can talk to the remotehost.
#/usr/local/nagios/libexec/check_nrpe -H 192.168.128.158
NRPE v2.12

Note: 192.168.128.158 in the ip-address of the remotehost where the NRPE and nagios plugin was installed as explained above.

Create host and service definition for remotehost:

Create a new configuration file /usr/local/nagios/etc/objects/remotehost.cfg to define the host and service definition for this particular remotehost. It is good to take the localhost.cfg and copy it as remotehost.cfg and start modifying it according to your needs.

host definition sample:

define host{
use linux-server
host_name remotehost
alias Remote Host
address 192.168.128.158
contact_groups admins
}

Service definition sample:

define service{
use generic-service
service_description Root Partition
contact_groups admins
check_command check_nrpe!check_disk
}

Note: In all the above examples, replace remotehost with the corresponding hostname of your

remotehost.
Dont forget to include
 cfg_file=/usr/local/nagios/etc/objects/remotehost.cfg
 in /usr/local/nagios/etc/nagios.cfg

Restart the nagios service:

Restart the nagios as shown below and login to the nagios web (http://nagios-server/nagios/) to verify the status of the remotehost linux sever that was added to nagios for monitoring.

# service nagios reload

Troubleshooting:

On Red Hat, For me the ./configure command was hanging with the the message: “checking for redhat spopen problem…”. Add --enable-redhat-pthread-workaround to the ./configure command as a work-around for the above problem.

You may also modify commands.cfg to add check_nrpe that was not by default in that file.

# ‘check_nrpe’ command definition
define command{
command_name check_nrpe
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -t 30 -c $ARG1$
}

add the following in /objects/commands.cfg of the Nagios server.

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

Comments

Post a Comment

Popular posts from this blog

Resolved: DOCKER: Error response from daemon: Could not attach to network / rpc error: code = 7 desc = network not manually attachable.

Image
I got this error: 'docker: Error response from daemon: Could not attach to network <nw-name>: rpc error: code = 7 desc = network <nw-name> not manually attachable.' when i try to create the container on the overlay network on swarm mode enabled, In docker 1.12 with swarm mode enabled, "Swarm" scoped networks (see the "SCOPE" column) cannot be used for docker run, only for services and now it has been rectified. I'm using updated version of docker, but still why i'm experiencing the error ? because the network just created but not manually attachable. To fix the issue we gonna use --attachable flag while creating network. [ --attachable             Enable manual container attachment ] (Need to create service on the overlay network, so that the overlay network will available / list on the worker node) docker inspect attnw (attnw is our test network)should show your own c
Read more

yum failed 6 times. Cannot continue!

Error while cPanel installation: (ERROR): - ssystem [EXIT_CODE] '/usr/bin/yum' exited with 1 (ignored) (DEBUG): - ssystem [END] (FATAL): yum failed 6 times. Cannot continue! fix: It looks like you have some name resolution issues on the server. Just run the following commands on your server and it will resolve the name resolution issues. #echo "nameserver 8.8.8.8" >> /etc/resolv.conf #echo "nameserver 8.8.4.4" >> /etc/resolv.conf if it is not working properly still facing same error, then here we go, # rpm -e --nodeps bind-chroot # rpm -e --nodeps bind # yum install bind
Read more

unexpectedly shrunk window (repaired) in dmesg log - TCP Peer

Don't Panic, This normally occurs when a client decides to reduce its TCP window size, without the server expecting it. This can be the case when fragmentation is an issue, or when the client is using an embedded device with very little NIC buffer memory. This is a completely normal behaviour, and you’re likely to see quite a few such packets in your log. The messages are informational only, and are used to debug networking issues. I’d be worried if you saw hundreds of thousands of these packets, since there are attacks that involve packet fragmentation and small window sizes, but otherwise it’s just the normal sort of noise you should expect to see on any internet-facing network. In fact, the “repaired” part of your message is showing that your network driver fixed the issue, which is usually done by concatenating the payloads of two fragmented packets together. Shouldn’t be an issue at all. … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … 
Read more