… Is the top dog of open source monitoring slowly going into retirement?

Among open-source-friendly admins, Nagios has long been synonymous with network monitoring, just as the Tesa brand is for transparent adhesive rolls. This is also the case for us at WorNet. We operated our first installations about ten years ago, at that time they were still called “Netsaint”, before the project had to be renamed due to trademark disputes. At the time, the Netsaint impressed with its wealth of features, reliability and easy-to-understand concept. You could even write and integrate your own check plugins in a very simple way. Even today, the Nagios is the best-known and by far the most frequently used monitoring solution, which also holds a firm place in the enterprise segment. Nagios is probably the de facto standard for network monitoring systems.

Who hasn’t thought that Nagios could no longer be state of the art? Unfortunately, his technology has not risen nearly as brilliantly under the hood as his popularity. The project grew quickly at first and soon it became clear that the architecture would not support the required extensions, which is why new features were not included in the code of the Nagios core, but were included as plugins and external services via numerous interfaces. Notification escalations were implemented as one of the last core features, and they have not yet reached the required level of maturity. But module-based extensions also faltered a little later, for example, the database interface called NDO-Utils has not progressed beyond the beta stage since 2005.
Three years ago, Nagios 3.0 was the last noteworthy innovation. Since then, it has mainly been heard from the exasperated community that submitted patches by Nagios inventor and sole programmer Ethan Galstad are left unnoticed for months before a few of them make it into the source code. The Lord of the Nagios doesn’t really seem to be interested in further development. This may also be related to his paid enterprise solution, which he sells.

Alternatives
From today’s point of view, one has to wonder why none of the numerous newer monitoring projects, such as Zenoss, OpenNMS or Zabbix, some of which are much more modern, performant and easier to use, has so far been able to buy the cutting edge from Nagios worth mentioning. Surely this has to do with the huge user and developer community that has formed around the system over the years and is constantly producing new plugins and addons. Nevertheless, there are signs of an impending upheaval, because renewal is long overdue.

I became aware that it was soon time to switch to a less dusty monitoring solution when I received several inquiries from customers on the subject of monitoring last year and found out during my research that the technology had hardly changed for five years now. I just had a bad feeling about introducing technology to customers that seems to be little developed, even though it was obviously still the standard tool.
The search for alternatives finally resulted in a number of modern and lively opensource projects. Among them is a project called Icinga, which emerged from a Nagios code fork in 2009 out of frustration over the development backlog at Nagios. They were able to get some good developers on board and give the whole thing new momentum – Incinga comes with a modern Ajax-based web interface and has long since left the actual Nagios behind in other respects as well. It can be installed and operated with less effort, because important modules have become an integral part of the package, which you previously had to “tinker with” yourself. The configuration of Icinga is currently still 100% Nagios compatible. Very promising.
But what ultimately also ails Icinga is the almost unmaintainable code that has grown over ten years and the outdated architecture. In the long run, it is hardly possible to win a flower pot with it. A code rewrite would have been due a long time ago.

Code Rewrite
This is exactly the approach pursued by Frenchman Jean Gabès, who programmed a complete new implementation of Nagios in the modern scripting language Python as a proof of concept one and a half years ago. Originally, he wanted to convince the Nagios boss to use this rewrite as a new code base for upcoming Nagios versions. The much smaller entry hurdle for new developers due to the modern code and its extensibility would have been a great advantage. Ethan Galstad has probably not commented on the initiative to this day. For this reason, Jean Gabès has started to continue the project under the name “Shinken” himself and as an independent Nagios alternative. It has been supposedly suitable for enterprise use since version 0.4.

Shinken
Shinken is no longer a monolithic tool, but has been programmed in several task-related processes. For example, there are several processes that work independently of each other without blocking each other and do not necessarily have to run on one and the same server. These components are called arbiters, schedulers, bollards, reactionners, and brokers; Details can be found on the website . An advantage here is the possibility of setting up a distributed system in a simple way. Distributed configuration files, in contrast to the Nagios, are then synchronized by Shinken itself. As a personal monitoring highlight, I see the following feature, which has been available in Shinken since the last release: Time-based escalations! Another killer feature, and one that can be presented to the troubled Nagios Escalation users as Good News. According to the website, all previous features of the Nagio have now been implemented in Shinken, which makes me look to the future full of exciting anticipation.

Result
Compatibility with Nagios is important for an easy migration in certain places. The painstakingly collected, modified or self-knitted check plugins, for example, represent an important basis. It remains to be seen whether the numerous peripheral tools such as Nagstamon, Nagroid or the Nagios plugin will continue to be usable.
Perhaps, however, we can finally crack an egg over the ancient Nagios problem with Shinken. Although I have not yet been able to gain any practical experience with Shinken, the information so far sounds so promising that I will certainly take the next opportunity to test this opportunity to finally put our monitoring back on a modern footing extensively. I will get back to you when there is experience on this. All in all, however, the Nagios is and remains the standard monitoring tool for the time being, even if sooner or later it will be replaced by a promising Shinken or one of the other modern projects. Icinga is already a good alternative.

By the way, if you are also open to completely different opensource monitoring approaches, you should take a look at one of the other popular systems such as Zenoss, Zabbix or OpenNMS.

IT remains exciting!

Best regards
, Hannes Wilhelm

Sources:
http://en.wikipedia.org/wiki/Comparison_of_network_monitoring_systems
http://de.wikipedia.org/
http://www.icinga.org/
http://www.shinken-monitoring.org
http://www.linuxtechnicalreview.de/Foren/Monitoring/Shinken-neues-Nagios-Release-oder-Nagios-Nachfolger