Jan/101
Ninja – The alternative Nagios GUI
Ninja is a new webinterface for Nagios. Ninja is the first project which intended to create the new Nagios GUI to replace the existing CGIs completely.
The project has the activity, power and relations to bring that task to success. Maybe someday Ninja will be included within the official Nagios package. But it seems this will still take some time. The current version of Ninja is 0.3.6.
The benefits
Ninja solves different requirements which could not be solved by the CGI based webinterface of Nagios. The Ninja GUI is written in PHP which results in a wider flexibility and a bigger community to contribute to the project. Ninja is template based which makes it easy to change the style of the GUI to fit corporate standards. There is also multilanguage support which may help some users in multi lingual environments.
The Ninja frontend intends to be much more scalable to work well in very large environments where the CGIs are unusable. The Ninja team has an eye on easy integration of 3rd party addons for Nagios like pnp4nagios, NagVis and so on.
During the developement of Ninja the developers started working on extending the NagVis project with the geomap which is a new Google maps based way of viualizing objects. The geomap is based on Flash Flex and part of the official NagVis package.
Connecting Nagios and Ninja
Ninja uses the Merlin MySQL Database as default information source. The initial target of Merlin was to make the setup of distributed Nagios installations easier. Seeing the Merlin Database can easily be used for simple connections of 3rd party applications to Nagios in even single seated Nagios installations the developers decided to use it as default status information backend for Ninja.
You only need a MySQL database to setup the Merlin MySQL Database for Ninja. The setup is like for the NDO. You need to setup the Merlin MySQL Database, add a Nagios Event Broker module to the Nagios process, start the Merlin Daemon (merlind) and enjoy it.
Developement
The Open Source project has been started and is powered by op5. op5 is a Swedish IT company which focuses on Open Source IT monitoring. They release a lot of their programs and solutions as Open Source and create benefits for other users. The platform for such releases is op5.org.
You can take a look at the Ninja webinterface on the demo page. You can access it with the user and password: monitor.
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/101
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.
Dec/091
Nagios Addons
Larger projects to extend the functionality of Nagios are called addons. There are many different addons which have different focuses on improving Nagios in different ways. There are graphing addons for graphing performance informations, mapping addons for creating nice views on the monitored systems, analyzing addons for creating reports. Other addons improve the default notification mechanism with more flexible ways notifying the administrators.
Dec/092
Nagios Plugins
The Nagios core does not perform check of hosts or services on it’s own. Instead of that it calls small scripts or programs to gather the status of the configured hosts or services. These scripts or programs are called Nagios Plugins.
Nagios Plugins are small scripts or programs which are called with special parameters. A Nagios Plugins can output a string as status output and additionally some performance data. The Nagios Plugins als need to return a valid exit code. Nagios uses this exit code to gathers the status of a configured host or service. Depending on the exit code Nagios fires actions like notifications or eventhandlers. The output is only for giving more information to the users. The performance data is for creating graphs from the current object state.
Offers
Projects
Misc
