Nagios – self-compiled or out-of-the-box? (Part 1 – the story before)

In my company we have been using Nagios for monitoring for years. Nagios is a freeware with which you can monitor devices and appliances in a network. The core of product is completely free – however there can be extensions and plug-ins which are commercial and therefore, you have to pay for.

But even with the free version you already get a full toolset for monitoring your environment. To be more concrete I want to list some examples. With the Nagios Core you can monitor:

  • Particular ports on switches regarding errors or bandwidth usage. In our company we mainly monitor trunk ports, because they are the veins of the network.
  • Monitoring servers and their disk space, processes, swap partitions, memory.
  • Monitoring services such as http, ftp or mailserver.

In summary: You have the possibility to monitor anything – if you have a working plug-in. Fortunately there is a big community around Nagios which is developing plug-ins for any purpose and offers them for free. To give you a short impression you can go to the Nagios Exchange.

Without going to deep in the details I want to report from my experiences with Nagios. I started to build up a new Nagios system around 3 months ago. We already had a Nagios system before, which was running on the old Nagios Core version 3.0.3 and the configuration component Centreon. After getting in touch with the system I realized that the configuration of our old server was corrupt. Configuration files were messed up and centreon isn´t really helpful to clean the configuration. For my opinion centreon is offering too much features – especially compared to the needs we have in our company. Another annoying thing about our old server was that the virtual machine had disproportional I/O activity.

In the end I decided to build up a new Nagios server based on the current release 3.2.3 and extend it with useful plug-ins and add-ons. The goals were to provide my co-workers with

  • a modern front-end in which you can access the most used functions directly


  • a customizable interfaces which only shows information that the user really needs

With this goal in my head I started looking around for useful add-ons and plug-ins for the future set-up. I found the following add-ons, which are kind of “state-of-the-art” for a nagios configuration:

Check_MK: This add-on is founded by Matthias Kettner, a german programmer specialized in Nagios developement. Check_MK is a substitude to NRPE and NSClient++ for collecting host data. Besides this plug-in he also develops a new front-end called mk_livestatus, which offers a full integration of the Check_MK plug-in. Since we are using NSClient++ on our servers I can´t make any use of check_mk for now – the interesting fact for me was that mk_livestatus is highly customizable thru the implementation of Snap-Ins. With this Snap-Ins every Nagios user has the possibility to customize their front-end as they need it. This is a mayor advantage compared to the oldschool, non-customizable Nagios Core interface.

NagVis: With NagVis you can create or generate maps visualizing the dependency between hosts. This gives you the possibility of producing nice looking dashboards in seconds.

NConf: Traditionally the Nagios Core gets configured with text files. In order to keep overview and make the configuration easier there are a lot of different web front-ends for the generation of those configuration files. I personally chose NConf, because of it´s simplicity. The only really disadvantage of NConf is that there is no possibility to configure escalations. All other necessary configuration can be done using NConf. A nice introduction over the most common configuration interfaces is given under

Pnp4Nagios: Stores performance data in RRD databases and visualizes them in nice-looking graphs. The visualization is customizable by templates.

After finding  this add-ons I decided to build up a new Nagios server test installation on a local virtual machine with the following configuration: Nagios Core 3.2.3, mk_livestatus 1.1.10 and NagVis 1.5, NConf 1.2.6, pnp4nagios 0.6 on SuSE Linux Enterprise Server SP1. The how-to under gave me good help at the installation process. After fixing several small problems I had a running configuration and added 200 services. In the next I moved the local virtual machine to one of our centralized ESX servers for further performance testing. Everything seemed fine untilI a coworker brought an interesting point to my attention: Even though the test configuration only hosted 200 service checks the vSphere console showed I/O values around 500 in average. Knowing this I started optimizing my Nagios configuration with the help of different wikis. In the end I had a noticeable success of reducing the values to 450 – still too high compared to the low number of service checks.

Since I don´t have enough time to evaluate the problem in more detail I looked around for other possibilities. I ended up on Matthias Kettners website again and found omd – the Open Monitoring Distribution. Omd is nothing else then a precompiled and preconfigured rpm with all extensions you need for running a “state-of-the-art” nagios system. Beside the Nagios Core it consists of the plug-ins PNP4Nagios, NagVis, Check_MK, Livestatus, Multisite and also installs the Apache Webserver with php, which is a prerequisite for running a web-interface. The complete package is offered for all common linux distributions like SuSE, Ubuntu, Debian and CentOS. Compared to my old, self-installed configuration there was only the configuration back-end NConf missing. As a result I had to install it manually.

This is how I found my way to omd. In the next article I want to report about my experiences with the Open Monitoring Distribution and what are the pros and cons of this precompiled solution. Furthermore I will post a tutorial on how to integrate NConf into a standard omd installation.



About sitweak
Monitoring, Network, Firewall, Mobile Security. I´m totally into that stuff!

2 Responses to Nagios – self-compiled or out-of-the-box? (Part 1 – the story before)

  1. Pingback: Configuring OMD for LDAP (Domain) Authentication « l0lsen

  2. Pingback: Configuring OMD for LDAP (Domain) Authentication « sitweak

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: