Nagios – self-compiled or out-of-the-box? (Part 2 – experience with the OMD installation process)

In my last post I described how OMD – the Open Monitoring Distribution – came to my attention. The main reason was that I kept noticing high I/O stats in my vSphere console. For this reason I tried to optimize my Nagios configuration – with only small success.

OMD is described as a precompiled package which includes everything you need for a full working “state-of-the-art” installation. It is preconfigured and optimized for hosting thousands of service checks.

In this post I don’t want to give more information about the product itself – instead I want to report my personal experiences with OMD. If you are looking for more information, you should check the following links of the official websites: German introduction, English introduction

Installation process
The installation process is pretty easy: Download the package for your distribution and install it with the built in package manager. This is the first advantage compared to self-compiling and installing all the add-ons separately: The package manager checks if the necessary packages FOR ALL components are installed. In my first attempt I had to look for particular packages which were needed by the add-ons. This was permanently interrupting the installation process. After the installation of the OMD package you are ready to create your first site with the command omd create <sitename>. Then you can start the site with omd start <sitename> and access the Webinterface for the first time – your first Nagios installation is ready for production! Unfortunately there is no configuration front-end coming with the OMD package. This is a minor problem as the only way adding hosts and services is to change configuration files by hand. I will probably cover that topic in a later post by explaining on how you install NConf with OMD. NConf is a webinterface for generating the configuration files.
A nice thing about OMD is that it puts all data from your site in the folder/omd/sites /<sitename>. On a self-compiled system I had often problems on finding the needed configuration files as they were spread all over the system. In OMD all configuration files are saved under /omd/sites/<sitename>/etc. On the other site I have to say that the first look in the etc folder shocked me. There are tons of configuration files under different add-on folders. Probably you will need some time to understand the structure of the configuration files folder. On the other hand you get a full working configuration – most of the users won´t need to change the configuration in the beginning. Also it´s even better to have all the files in one folder then having them spread all over the system. This is definitely a plus for OMD.

Conclusion: The installation process with the OMD package needs 1 % of the time you will need with self-installing and self-configuration. To get an idea of how many steps you need by manually installing you can take a look at this tutorial.
On the other side, I have to say that the self-compiling and configuration in my first attempt (see Part 1) helped me to understand on how things are interacting (mk_livestatus with Nagios Core, pnp4nagios with the Nagios Core). This is important for the later use – especially trouble shooting for configuration errors. But for new users it is definitely better to install OMD – also because you have the security that every add-on is working as designed. In my first attempt I spent hours on investigating small errors. With OMD you get a working system out-of-the-box, have a consistent folder structure and a perfectly pre-configured system.

So don´t be scared: Try OMD for yourself! For all of you who prefer Incinga: there is also a OMD package which is based on Incinga (I didn´t try it on my own).

I hope my experience helps anyone – maybe some people who stopped building up a Nagios server because of the complicated installation of old the add-ons. In my next post I will concentrate on my root problem: the high I/O values.