Nagios open source system monitor software

nrpe Nagios Remote Process Execution

nrpe - Daemon and plugin for executing plugins on remote hosts

Overview: Allows you to execute plugins on remote hosts in a relatively easy and transparent manner.
Files:
check_nrpe - Plugin used to send execution requests to the nrpe agent on the remote host
nrpe - Agent that runs on the remote host and processes plugin execution requests
nrpe.cfg - Configuration file for the remote host agent
Description:

This addon is designed to provide a way for executing plugins on a remote host. The check_nrpe plugin runs on the Nagios host and is used to send plugin execution requests to the nrpe agent on the remote host. The nrpe agent will then run an appropriate plugins on the remote host and return the plugin output and return code to the check_nrpe plugin on the Nagios host. The check_nrpe plugin then passes the remote plugin's output and return code back to Nagios as if it were its own. This allows for a rather transparent method of executing plugins on remote hosts. The nrpe agent can either be run as a standalone daemon or as a service under inetd.

Subject

Passive Service Checks

Introduction

On of the features of Nagios is that is can process service check results that are submitted by external applications. Service checks which are performed and submitted to Nagios by external apps are called passive checks. Passive checks can be contrasted with active checks, which are service checks that have been initiated by Nagios.

Why The Need For Passive Checks?

Passive checks are useful for monitoring services that are:

  • located behind a firewall, and can therefore not be checked actively from the host running Nagios
  • asynchronous in nature and can therefore not be actively checked in a reliable manner (e.g. SNMP traps, security alerts, etc.)

How Do Passive Checks Work?

The only real difference between active and passive checks is that active checks are initiated by Nagios, while passive checks are performed by external applications. Once an external application has performed a service check (either actively or by having received an synchronous event like an SNMP trap or security alert), it submits the results of the service "check" to Nagios through the external command file.

The next time Nagios processes the contents of the external command file, it will place the results of all passive service checks into a queue for later processing. The same queue that is used for storing results from active checks is also used to store the results from passive checks.

Subject

Choosing Active or Passive Montioring with Nagios

When setting up alerts in Nagios some are better to be active while others can be passive.  Further Active monitoring can be executed either on the Nagios server or started from Nagios but executed remotely, see diagram.

  1. Active Service Checks are initated by Nagios
    • Ping or service check of exposed resources
    • Remote Execution (nrpe) (ssh) for checking local resources like disk usage, processor load
  2. Passive Service Checks are initated by exteral commands
    • Passive Checks are good for handling asynchronous events such as:
      • security alerts
      • when scanning log files for errors
      • handling alerts from 3rd party software.

Subject

Gartner Magic Quadrant and Research on Monitoring

Event Correlation and Analysis Market Definition and Architecture Description, 2009
Debra Curtis, David Williams


When embarking on an event correlation and analysis (ECA) project, it's important to consider the right event management specialist  products, manager of managers (MoMs) and business service management (BSM) options, pulling together the appropriate sources and data types supported by the right ECA architecture.

Subject

Nagios Basic Setup

Basic Setup

On fedora or CentOS just install the RPM for Nagios and the plugins

yum install nagios

Edit the config files in /etc/nagios/objects

Check the config files are valid by typing

nagios -v /etc/nagios/nagios.cfg

Start nagios by typing

/etc/init.d/nagios restart

Subject

Nagios Addons

The main difference between a NagiosPlugin and an NagiosAddon is Nagios addons are an extensions to the base-system monitoring on the server. There are two types of Nagios Addons available.

  • Core-Addons (Addons provided by the Nagios-Developer Ethan Galstad)
  • Community-Addons(Addons provied by the Nagios-Community)

Nagios Core Addons

Database

NDOUtils
NDOUtils allows you to export current and historical data from one or more Nagios instances to a MySQL database. Several community addons use this as one of their data sources.

Distribution

NSCA
NSCA allows you to integrate passive alerts and checks from remote machines and applications with Nagios. Useful for processing security alerts, as well as redundant and distributed Nagios setups.
NRPE
NRPE allows you to remotely execute Nagios plugins on other Linux/Unix machines. This allows you to monitor remote machine metrics (disk usage, CPU load, etc.). NRPE can also communicate with some of the Windows agent addons, so you can execute scripts and check metrics on remote Windows machines as well.

Subject

Nagios Monitoring

Nagios, the most popular open source solution for system and network monitoring, is extremely robust, but it's also intensely complex.

Nagios Monitoring Capabilities

  • Tracking of network services such as SMTP, HTTP, FTP, and NNTP
  • Monitoring of host machines: CPU load, disk and memory utilization, running processes, etc.
  • Capability to define host hierarchy, allowing distinction between machines that are down as opposed to ones that are unreachable
  • Support personnel notifications by e-mail, beeper, or other user-specified means when service or machine problems are detected or are fixed
  • Ability to define event handlers to be executed upon the detection of service or host events for proactive problem resolution
  • Support for implementing backup and distributed network monitoring computers
  • External command option that allows ad hoc modifications to be made to the tracking and alerting activity via the utilization of event handlers, the web interface, and third-party software
  • Retention of host and service state across program restarts
  • Planned downtime for suppressing machine and service alerts during deliberate service breaks
  • Web interface for examining current network status, notification and problem archive, log file, etc.
  • Permissions scheme that enables you to limit what customers can view and modify from the web applet

 

Subject