Jan/100
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 thats 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 incompatibilties. This may result in total inactivity in the Nagios/ICINGA core – but it may also come totally different.
Shinken may shine brigther
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 writtenin 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/101
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/090
Git merging with removal of one commit
Git grew up to my favorite version control system, I use Git on a daily base now. I like git because it is powerful but also simple for the daily usage. Git is a complex system so there are commands and steps which I do not perform every day. So I write about some more complex steps for later reference.
Today I needed to merge two git branches but remove the changes from only one commit where some files were deleted which should be left untouched in the target branch. I realized that using a temporary local merge branch where I removed the unwanted commit to later merge it with the target branch.
Dec/092
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/090
Christmas Card for Geeks
As every year I found a nice Christmas card for you. This is a funny alternative Christmas card for geeks. The Christmas card for 2008 was in German.
This Christmas Card, or as we call it in German “Weihnachtskarte“, is not as colorful as the usual Christmas Card but it wishes white Christmas in a geeky way.
So I wish you a merry Christmas!
Found on zazzle.de.
Dec/090
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.
Dec/090
Nagios – Open Source Monitoring
Nagios in general
Nagios is an Open Source solution to monitor complex IT infrastructures. Nagios can be used to perform alive checks to ensure the availability of networked systems. It is also possible to use Nagios for performance and capacity analyzes.
History
Nagios has first been developed under the name Netsaint. Since 2002 the project is Named Nagios. The name comes from the words Network + Hagios.
The concept
The concept of Nagios is to serve a smart and stable core which can be easily modified and extended with a couple of addons and plugins.
Knowing this you may notice that you get at least two components with the Nagios core package. The Nagios Core and the default web frontend which uses C based CGIs.
This concept may also be an explanation why the default Nagios Plugins are stripped from the Nagios Package and served as separate project.
Splitting the single components in different projects leads in a higher flexibility. Each user can install components the components which are needed in a special setup. The big disadvantage is the amount of time which is needed to get a running and checking Nagios installation. Especially for beginners the first steps are not easy.
