Testing and comparing new Nagios version (3.2.3 to 4.0/3.99.95)

Written by - 0 comments

Published on - Listed in Nagios Monitoring


Followers of my blog know that I'm a long time user of Nagios. When I started, Nagios was still in its version 1.x and since then a lot of changes happened. In the last few years I stuck with different versions of the 3.x branch (mainly 3.1.1, 3.2.3 and 3.3.6). Now it's time to check out the newer versions.

Followers of the Nagios mailing list were in advance informed about the new capabilities of Nagios 3.4. One of the main developers, Andreas Ericsson, wrote on April 5th 2012:

Nagios 3.4 will be a single-threaded and event-driven application that sports an I/O-broker and vastly improved check performance.
In essence, we've removed 2 fork() calls, 4 disk searches, 2 filewrites and 2 filereads from each check being performed.
There's also a fixed usage of the current scheduling queue implementation which turns scheduling new checks from its current O(n) behaviour to O(1).
This will provide a huge benefit for large installations, and combined with the worker process code we're currently seeing a 12-fold increase in the amount of checks Nagios can execute

Ever since this post, I was eager to test the new version.

Meanwhile version 4.x is almost out, the current version in the svn trunk is 3.99.95 (which basically is the new Nagios 4). Let's check out some differences between one of my old installations (3.2.3) to the current SVN trunk 3.99.95.

worker processes

The first thing catching my eye were the worker processes being "there" since the start of Nagios daemon. On 3.2.3 only one process is up and is then being forked when checks are executed:

11:29   0:00 /usr/local/nagios/bin/nagios -d /pub/nagios/etc/nagios.cfg
11:29   0:00  \_ /usr/local/nagios/libexec/check_nrpe -H somehost.example.com -c check_cpu_stats

On new 3.99.95 the worker processes are "ready to handle action":

11:09   0:00 /usr/local/nagios/bin/nagios --worker /usr/local/nagios/var/rw/nagios.qh
11:09   0:00 /usr/local/nagios/bin/nagios --worker /usr/local/nagios/var/rw/nagios.qh
11:09   0:00 /usr/local/nagios/bin/nagios --worker /usr/local/nagios/var/rw/nagios.qh
11:32   0:00  \_ /usr/local/nagios/lib/check_ping -H 127.0.0.1 -w 100.0,20% -c 500.0,60% -p 5
11:32   0:00      \_ /bin/ping -n -U -w 10 -c 5 127.0.0.1
11:09   0:00 /usr/local/nagios/bin/nagios --worker /usr/local/nagios/var/rw/nagios.qh
11:09   0:00 /usr/local/nagios/bin/nagios --worker /usr/local/nagios/var/rw/nagios.qh
11:09   0:00 /usr/local/nagios/bin/nagios --worker /usr/local/nagios/var/rw/nagios.qh
11:09   0:00 /usr/local/nagios/bin/nagios -d /usr/local/nagios/etc/nagios.cfg
11:09   0:00  \_ /usr/local/nagios/bin/nagios -d /usr/local/nagios/etc/nagios.cfg

So there are (by default) 6 worker processes and checks are handled by these pre-existing processes. This means less forking and more parallel check possibilities.

These worker processes will be officially released with the upcoming Nagios 4.x release.
I'm again quoting Andreas Ericsson, this time from his e-mail on September 14th, 2012:

Yes, you read it right. Nagios 4 is approaching, but it needs your help to reach the finish-line, so pretty please HELP!
Right now, config parsing is a lot quicker. Check execution is done through workers, except on-demand host chekc execution, which is still handled by the serial model.

libexec becomes lib

Over the last few years I got used to the so-called libexec folder for the nagios-plugins. By default the destination folder for the compiled nagios-plugins was /usr/local/nagios/libexec. If one looks at the folder structure of Nagios 3.99.95, this has now changed:

 # ls -a /usr/local/nagios
.  ..  bin  etc  include  lib  sbin  share  var

At the begin I was curious and wondered what that 'lib' is, but a look into it showed me all the nagios-plugins I compiled right after the Nagios core. Another hint can be found in the resource.cfg:

# grep USER1 /usr/local/nagios/etc/resource.cfg
# Nagios supports up to 32 $USERx$ macros ($USER1$ through $USER32$)
# Sets $USER1$ to be the path to the plugins
$USER1$=/usr/local/nagios/lib

New theme 'exfoliation'

Nagios 3.99.95 comes with the new theme called exfoliation. It has more or less the same structure of the old theme (now called classic-ui) but is completely in white.

Nagios new theme exfoliation

The interface change is not that dramatic that it's a must use, I'll probably continue with the classic-ui or even install a complete different theme/skin.

Limit results in GUI

It's now possible to limit the listed services and hosts. Remember the click on "Services" and hundreds and thousands of your service checks showed up? This can now be limited. By default, the results are limited by 100 entries:

Nagios 4 limit results

The drop down menu allows to select 50, 100, 250, 1000 or ALL results.

-------------------

If I stumble across other major changes or new features, I'll add it on this article. Basically a quick look at the Nagios Core Version History already tells a lot, too.


Add a comment

Show form to leave a comment

Comments (newest first)

No comments yet.

RSS feed

Blog Tags:

  AWS   Android   Ansible   Apache   Apple   Atlassian   BSD   Backup   Bash   Bluecoat   CMS   Chef   Cloud   Coding   Consul   Containers   CouchDB   DB   DNS   Database   Databases   Docker   ELK   Elasticsearch   Filebeat   FreeBSD   Galera   Git   GlusterFS   Grafana   Graphics   HAProxy   HTML   Hacks   Hardware   Icinga   Icingaweb   Icingaweb2   Influx   Internet   Java   KVM   Kibana   Kodi   Kubernetes   LVM   LXC   Linux   Logstash   Mac   Macintosh   Mail   MariaDB   Minio   MongoDB   Monitoring   Multimedia   MySQL   NFS   Nagios   Network   Nginx   OSSEC   OTRS   Office   PGSQL   PHP   Perl   Personal   PostgreSQL   Postgres   PowerDNS   Proxmox   Proxy   Python   Rancher   Rant   Redis   Roundcube   SSL   Samba   Seafile   Security   Shell   SmartOS   Solaris   Surveillance   Systemd   TLS   Tomcat   Ubuntu   Unix   VMWare   VMware   Varnish   Virtualization   Windows   Wireless   Wordpress   Wyse   ZFS   Zoneminder   


Update cookies preferences