Keep in mind, this my very own and private opinion, and does not reflect the opinion of the team or project icinga in any way. Though there might be similarities 🙂

As you might have figured, Icinga is one of my hobbies next to the daily work stuff i gotta fiddle with. So, when you hit my activity in the various channels, it might just be my spare time, for the fun and honor 🙂

Regarding the current code basis (being still the forked Nagios code in most places) it became hard adding new features, or likewise fixing bugs and testing their resolval. Even if the roadmap for our releases did not contain that much issues, it is always a bunch of work. Work and time you will never get back, compared to the actual outcome. People might say, it’s our very own fault, forking others code and then complaining. Well, my situation is a bit different – i did not do the fork. I just joined the team following their vision – and the code was still the same, in places, a glory mess. Over the time fixing stuff, my mess was added in various places too (others keep complaining about unreadable idoutils code, well, heck, i know – fix that one, or fix your bug? … and so on). Long story short – time has come where hacking around is not that much fun anymore. But it should be, when you do that in your spare time, for free, right?

You might say – “hey, I can see progress with Nagios 4 Workers and other rewrites, why don’t you get on with that?”. Well. To be honest, I am following that, and also tried porting some older code branches to Icinga 1.x – experiencing a bunch of new bugs, while looking at some voodoo code one would need to maintain. Ehm – yeah, found a reason why i won’t do that in Icinga, misses the fun, hunting bugs others do in their unstable svn trees.
Another idea – port the code and name Nagios 4 Icinga 2 then? There are various people out there thinking that this would actually work, as Icinga would be just the Nagios core with a new UI. Well, tbh, I’ve put so much time into that project, that such a message really hurts. But, partly this is correct – though not the entire one. With Icinga you’ll get the whole package, it’s just more than the core.
Easy install, better documentation, 2 actively developed UIs, 2 more database backends and a big patch set also adding some values to the core – and even if only some configure flags to make the packagers happy. So, in general, Icinga does not follow the open core model, which only gives you the basic core, and wants you to pay for advanced stuff. Personally, I think that the Open Core Model just sucks, and will harm the way open source monitoring could possibly evolve with an actively growing community. Seen that e.g. with Opsview Core, now actually some more Icinga and Shinken users in the wild (still not liking the freely available config tools, but that’s a different story). So, to conclude with – porting Nagios patches where it makes sense, but since it seems that Nagios 4 does solve not all the problems we are aware of, it will be a matter of resources doing so, evaluating their stuff. Still missing the fun bit in that, you too?
Well, and looking at other Nagios Forks – everyone has gone their own way, their unsatisfied ideas, their community being built. One might say – get together, join forces, do the superduper monitoring project – well, guess we are lucky when we get over the programming language discussion again. Anyhow, just to note – those projects actually wanting to talk with each other normally do, at least I ping from time to time. For Nagios itsself, I did quit a while back, reasons are just “the past and its events”. Google for it, when you are interested. Here, it’s about Icinga2 and the bright future, and so we will do our very own do make it as bright as it should be – everything within GPLv2 and OSS means.

In the early months of 2012 we sat together and decided to finally do something about it. Previously, all talks (also with other projects, such as Shinken, or Centreon) either stopped when it came to programming language discussions, or some different ideas on how to proceed. Like a guy asking on this years OSMC during the presentation, why we did not decide to use Java as programming language for Icinga 2.
Well, easy answer – those who put their time into programming Icinga, need to know the language. Actually, I learned 1 Semester Java during my studies, and I have to admit, I do not want to code it. There’s no special reason about it – live with that opinion. My background is C on embedded systems, as well as C++ in the Windows world. So actually, the Nagios/Icinga code with C on *NIX was pretty hard to learn in the first place. Getting back to C++ and even Windows (hello again, Visual Studio!) was actually a wonderful experience remembering the time during studying. Yet, on *NIX it isn’t much change with C++ anyways, as i prefer to code in vim (syntax on of course) as I did not find a suitable IDE yet (even if i do not like the way Microsoft pushes Visual Studio, it’s still the best integrated IDE imho, but sadly not for *nix platforms).
So, the Icinga team got C++ developers, and some C developers, next to the UI developers with PHP, JS, and advanced web tech stuff I do not even understand, only trying to debug sometimes. Our knowledge base is ready for the future – experience from a growing Icinga community, plenty of feedback, a rather large team with different responsibilities (someone needs to write docs, update the website, work on the social channels, do support, write wiki howtos, run the build server, create packages, update the virtual machines, … oh. and someone needs to write code too, like i usually say – Icinga is more than just code).

Anyways – over the past months, the architecture was designed, and with the first tech preview of Icinga2, we actually got something already running, rather than talking years about a rewrite. Most likely people are more attracted by fancy design graphics and binaries working – though, to note: the 0.0.1 release allows to use the delegation and checker components, as well as basic compat support for status.dat/objects.cache, experimental ido support. If you got your hands dirty with SSL certificates, you can even run distributed instances, with builtin replication and dynamic configuration objects. There are no notifications, downtimes, timeperiods, or any other stuff that you will need as a drop-in-replacement for Icinga 1.x. But, we are heavily working on that, and the final release will allow that (important target).

The config format is new – so don’t run away. I’ve played around it for a while now, and it feels easy to organize stuff, heavy templating with the one way to do it right. And of course, I know that Icinga2 will get an API where config updates will be pushed into – so no more text file edits anymore. Such API should also redefine the way of retrieving status/historical data, as well as subscribing to events – like Icinga2 itsself is a big framework with a message bus built on json-rpc protocol. Performance Data, Commands, and what else comes to mind should then be no problem anymore – as well as distributing the logs to a dedicated box. The “History” then should remain the basis for a stable SLA reporting too, proxying stuff via the api.

You will also recognize that the hosts do not have any checks anymore, but rather a ruleset to calculate a virtual state from services. This makes sense in regards of easier parent/child or dependency resolution. This is just the first step in direction of business processes, defining your rules for a process, consisting of various underlaying services. You actually care only about the process itsself, alert on its state and so on. Stuff people miss badly on Icinga 1.x – I’ve been playing around with webserver hosts and their host state consisting of check_ping and check_http for they easyness – awesome!

Since there will be many new stuff, it’s only the core framework for now. Keep things focused, and after the sound basis is rebuilt, rework the UIs and such. For the compatibility layers, the Classic UI, Icinga Web as well as addon backends should be put in place, meaning to say – support the ido schema for compatibility reasons, implement basic livestatus support to allow addons use Icinga2 as core as well.

One question the community asks quite often – “why icinga does not have its own plugins?”. Well, answer is usually “the nagios plugins still work with icinga”. That isn’t true all the time, especially those scripts using hardcoded lib paths and so on. Plus, the basic nagios plugins plus the sample config for localhost normally confuses the just-started-users. The question after not reading the docs (they are sometimes a bit too detailed and long, but still worth reading, the advice for beginners section the least!): “how can i monitor a remote host?”. Such things should also be addressed by Icinga2 – though it’s more of an idea. The native plugin checks, calling a binary, getting back output, pipe, perfdata, exitcode is so easy, that this will always be supported. But generally speaking, an embedded or collected plugin library sounds awesome too, doesn’t it? So, that’s one of those ideas. And once a yet-to-be-designed Agent knows about the operating system, and the services to monitor (well, another todo – autoinventory *cough*), it should already have gotten the most valuable plugins. So, you might figure, community feedback on the best plugins will be important too – now, or yet better, somewhere in 2013.

Oh, and do not forget, that Icinga 2 is built as component loader, which means, you can use the skeleton, as well as the underlaying message bus protocol for anything else – just depending on the components and their subscribed messages. Which is one of the reasons why we chose to use Boost as library – easy usage of Signals and Memory Management. No need to reimplement the library somewhere in your very own code. And the code is designed to compile on Windows too – and it even runs there, did my tests with some ping checks. That was the Icinga2 Core itsself, not an agent, or a checker.
Checkers will btw behave like an intelligent agent – they get the dynamic objects replicated, so they can actually continue checking, when e.g. the connection to the master is lost, and then re-submit their results when the connection is established again (todo – figure out which data is correct, there was a splitbrain discussion already on OSMC). A different approach would be to have different domains, with different API components loaded. Or likewise, the general idea of putting the GUI stuff on a dedicated Webserver, connecting to an Icinga2 Instance not checking anything, but providing an API – receiving all the data from the actual checkers and other (distributed) Icinga2 instances – better get pen an paper and start drawing, eh? 😉

Stuff like the API, Agents, Business Processes, Autodiscovery, proxies, domains, is pretty advanced and is most likely found on the Icinga2 roadmap already. If not, suggest an idea to the feedback tracker then and let others vote for getting into Icinga2 🙂 It’s likely that the roadmap will change over time, when the most important things are sorted. And keep in mind, there are plenty of ideas and feature requests already collected – from the feedback tracker, dev tracker, the mailinglists, etc – basically all the stuff you run into when trying to help users with their problems (and since i recently hit 5k postings at monitoring-portal.org i might say – i know many of the re-occuring problems by myself).

I think i could go on a bit more on, but you’ll get the idea – Icinga 2 is fun again. And there are many of us already having fun. Like Gunnar codes this awesome stuff (I am just designing and getting used to the Boost magic, while maintaing the compatibility layer as well as Icinga 1.x), but also Rune started to work on an MSI Installer (which actually works already in a test version, check the wiki for screenshots!). Or like Bernd, playing around with Icinga Demo VMs for the presentation all weekend long right before OSMC 🙂

Don’t forget – Icinga 1.x is not dead. It will be developed and patched like you know it. Even it’s not fun all the time – just keep it active with your feedback, your tests on proposed fixes, and your ideas to make it better! You are always welcome to join our dedication and write code too 🙂

To join the discussion – get in touch on the various known channels. Probably IRC is best, where you will find me idling as dnsmichi.

Oh, and keep in mind – i will ignore messages like mocking around about either the programming language, windows support or other trolling stuff. We should focus on the real stuff happening.

More official to read here – https://www.icinga.org/2012/10/25/icinga-2-v-0-0-1-released/