Jan/101
Nagios Init-Script verifyconfig with verbose output
Did you ever wanted to restart your Nagios process and got the following message after a change to the Nagios configuration?:
CONFIG ERROR! Check your Nagios configuration.
If you changed anything in a Nagios configuration file at least once in your lifetime I am sure you know that message. Now what to do? If you are experienced with this error message you know what to do: Run the Nagios binary with the -v (verifyconfig) parameter. Mostly the command looks like this:
:> /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
Having the command output you can easily find the source of the problem in your Nagios configuration.
But wait! Why is it so complicated?
Jan/100
Thruk – A MKLivestatus webinterface
Thruk is a Webinterface for Nagios. The Nagios Webinterface called Thruk is the second Nagios Addon based on MKLivestatus. You will ask “Why yet another webinterface?”. The difference to all the other new Nagios Webinterfaces is in the focuses and goals of Thruk.
Jan/101
ICINGA
Just one year ago this topic would be totally senseless. But different things happened with the Nagios project that it was just a question of time that a fork of Nagios would become reality.
I wrote some words about ICINGA, the Nagios fork, some time ago so I don’t want to repeat these words. But I want to add some background information and thoughts about the current things that happen around.
ICINGA – The benefits
Today it seems to me that the biggest innovation in the ICINGA project is the new webinterface. The webinterface makes use of different PHP and JavaScript frameworks which make the ICINGA GUI look very much like the marriage of the Web 2.0 and the Nagios world. That may be a real benefit for the users which are messed up with the old Nagios frontend.
I also see a benefit in the IDO, which is a fork of the NDO. The DB team of the ICINGA project works on fixing the biggest problems in that database output layer. They also work hard to make the usage of other databases like Oracle for the IDO possible.
A clear statement right from the beginning of ICINGA was not to break up with Nagios and leaving the Core compatible to the Nagios Core. That is a benefit not just for users which want to switch from Nagios to ICINGA it is also a benefit for the users which like to switch back. Switching back from ICINGA may sound strange from the current point of view but I think it may be a valid step in the future.
Should ICINGA really be independent?
Expect the Nagios and ICINGA Core don’t diverge and be nearly the same as they are today a re-merge could be an option. In this case I would take the step and reduce the ICINGA project to a Nagios webinterface with IDO as database backend. Reducing the ICINGA project which is a total Nagios fork today to a webinterface may sound strange since “yet another Nagios interface” does not sound as pretty as the own monitoring solution. From my point of view at the moment ICINGA is exactly that and nothing different.
I might be wrong cause I may see not all details of the current progress of the ICINGA project but that’s what I see on the surface.
Nagios inactivity – The boost for ICINGA?
Other things may happen. Ethan Galstad is working on Nagios XI which will be a package which contains Nagios and several addons which are bundled to one package. That solution is an enterprise product so it will need to be paid. It may be that the Nagios core will benefit from this development but in the first instance there is less time to push the development of Nagios. So this may again result in inactivity of the Nagios developer team.
Having this inactivity Nagios will fall behind and there will be hope that there is more activity in the ICINGA Core project. But since the ICINGA project don’t want to break up with Nagios they may shrink from making more complex changes to the ICINGA Core which may result in some incompatibilities. This may result in total inactivity in the Nagios/ICINGA core – but it may also come totally different.
Shinken may shine brighter
Another approach came up several days ago which totally breaks up with Nagios: Shinken. The name Shinken sounds funny in German cause it sounds like the German word for ham: Schinken. Shinken is not another fork of Nagios. It is a totally reworked Nagios which is written in Python. It seems not to cause an performance issue. Apart from that, the project has some very interesting ideas which should be a big benefit for many Nagios installations. It seems that this could breath some additional fresh air into the world of Nagios.
Jan/102
Nagios Configuration
Nagios is configured through plain text files with a special syntax. There are two types configuration files in Nagios 3.x.
There are the main configuration files which control the behavior of the single components. For example the nagios.cfg which controlls the Nagios Daemon. The cgi.cfg is used to configure the CGI based web frontend. Another special file is the resource.cfg which can be used to configure general options which should be available in the object configuration files.
The second type of Nagios configuration files are the object configuration files. These files are used to add objects like hosts, services, hostgroups, servicegroups, commands, timeranges and so on.
More information about this can be found in the Official Nagios Documentation.
nagios.cfg
The nagios.cfg uses a simple syntax: key=value. Comment lines begin with a #.
The default nagios configuration file which is created when executing make install-config. The nagios.cfg contains many comments with useful information about the single configuration options.
All important information like the place of the configuration files is set in the nagios.cfg file. So this file is the central place to control the configuration of Nagios.
The Nagios Documentation is very complete at this place.
Nagios Object Configuration Files
The object configuration files are fetched like configured in the nagios.cfg file. These object configuration files can be fetched using the cfg_file for single files and the cfg_dir option to add all files in a directory.
The Nagios Documentation is very complete at this place so I won’t write anymore about the syntax of these files.
Flexible object configuration concept
While a Nagios installation grows many Nagios administrators recognize the number of objects strongly grows and grows too. Without a clear and flexible concept for managing the Nagios object configurations growing Nagios installations will end up in pure chaos.
Starting with Nagios it is very hard to find the best concept for the object configurations for the specific Nagios environment. So if you start from scratch with your Nagios installation without any previous knowledge about Nagios I strongly recommend to plan some time for a redesign of the complete configuration after some time.
If you learned you first lessons using Nagios you will recognize there are several ways to make your Nagios configuration more flexible and more compact that it can be administrated easier. At this stage most professional Nagios users define some laws for the specific Nagios installations. These rules may begin with object naming concepts and end up with complex object management standards.
Just some basic topics you should think about when optimizing your object configurations:
- Use templates (Object Inheritance) to assign common options
- Use templates assign groups
- Use hostgroups to assign services to a group of hosts
- Use default wildcards like the * or ! to match objects when assigning to each other
- Use real regular expressions to assign objects to each other
The above listed sentences are just some examples in which ways Nagios configurations may be tuned. There are a lot of other options you have.
Nagios Configuration Tools
There are a lot of different other approaches to make the configuration of Nagios easier. Most of these solutions are web based configuration tools. All these tools have the disadvantage that they cut down the choices what and how to handle the configuration in different ways.
Most of the Nagios Configuration Utitilies use own databases where the Nagios Configuration is being modified. When a modification has been finished the configuration is parsed from the database into Nagios Configuration Files. After that the Nagios process is being restarted with the new configuration. This adds the disadvantage that modifications to that configuration files will be overwritten each time the configuration is parsed. So even experienced Nagios administrators need to use that web based configuration utility.
For some Nagios configuration utilities take a look at the Nagios Addons page.
Jan/100
Offer: Nagios Plugin Development
It is not a really hard job to develop any Nagios plugin. But developing good Nagios plugins which fit the special needs and requirements while being fast and only gathering the needed information requires some more experience and skills.
Dec/093
NDOUtils: Nagios Data Out
There are a lot of cases and ways the NEB modules can be used for. For example there is a very popular Nagios Data Out (NDO) database abstraction layer. The NDOutils have been developed and are distributed by the Nagios Core Team.
The NDOutils can be separated into two components. The ndomod is the NEB module which is loaded into the Nagios process. It forwards the information to listening daemons using tcp or unix sockets. The second component is a listening daemon. The most popular daemon is ndo2db. It retrieves the information from ndomod and pushes it to a relational database.
Dec/091
Nagios Event Broker
The Nagios Event Broker (NEB) is a way Nagios makes internal information available for external libraries. NEB is based on shared code libraries which are called modules. The NEB modules are hooked into the Nagios core process when starting Nagios. The NEB uses callback routines which have to be served by the NEB modules. These routines are executed when special events occur in the Nagios server process.
Offers
Projects
Misc
