Overview of CentreonBroker

As some of you might be aware of, Merethis is currently developping an alternative to the old NDOUtils : CentreonBroker. The goal of these tools is globally the same : store Nagios events in a database, but where NDOUtils have hardly been updated in years, CentreonBroker tries to take a new approach by using latest available technologies. As we’re almost reaching beta release, let’s have an overview of what CentreonBroker can (or will soon) do.

Since the beginning, performance was the primary objective. First rough benchmarks show that, for the same amount of data, CentreonBroker reduces load on a MySQL server from a 2 to 3 factor. The main reason for this performance gain is the new database schema we’re using (somehow similar to Merlin‘s). We’ve not reached optimal performances yet, we can do better !

Unlike NDOUtils, CentreonBroker will soon be capable to store data in different kinds of DBMS. MySQL is our reference, PostgreSQL support is under progress and we’re planning Oracle support. This is possible because of our carefully designed custom database abstraction layer. This layer also allows us to store events in multiple databases simultaneously !

On the input side, CentreonBroker can accept data from IPv4 sockets, IPv6 sockets and Unix domain sockets. All these inputs methods can be encrypted with TLS is desired. Unlike NDOUtils (again), TLS in CentreonBroker does not only provides encryption but also an optional authentication mechanism. This means that you can reject events from unknown Nagios instances ! Long-awaited hum ? Of course, CentreonBroker can accept incoming data from multiple sockets simultanously.

Another main difference with NDOUtils is the way events are treated internally. Where ndo2db is a single-threaded, per-client process, CentreonBroker is a multi-in multi-out fully multithreaded application which means that it can scale easily on modern multicore processors.

Of course those features are just a taste of what CentreonBroker has to offer, but it can do much more (on-the-fly configuration reload, listen on specific network interfaces are just examples). So the next big question probably is why isn’t it released yet ?

The answer is simple : we’re waiting on what we consider to be a mandatory feature : the ability to dump events to a file and load them again. That’s pretty much what is holding us to release it. Once done, we hope that some people will give it a try and give us feedbacks (hopefully positives).

Leave a Reply