A NDOUtils replacement : CentreonBroker

[Matthieu Kermagoret]

On Wed, Jul 1, 2009 at 5:17 PM, Andreas Ericsson<ae at op5.se> wrote:
> Matthieu Kermagoret wrote:
> This means there are four major contenders for the spot of being the
> default database broker for Nagios; NDOUtils, Merlin, IDOUtils and
> CentreonBroker. This is great, as it means the best technical solution
> will win. At the same time, it's not so great since it means at least
> four developers are working toward similar goals, but not working
> together towards that goal.
>

I agree with you that there will certainly be some efforts wasted but
it seems to me that each broker has its own peculariarity (replication
for Merlin, performance for CentreonBroker, ...).

>>  - written in C++ (more stability)
>
> This really is a very bogus claim, so please refrain from touting one
> language as better or more stable than some other, unless you actually
> *want* to run headlong into "is it more stable than <insert 30 year old
> program that has *never* failed here>".
>

I knew that someone would pick that up ;-)

I won't say that a C++ program is *always* more stable than a C
program but it's generally true. Like saying that C is faster than C++
is not always true. Just often.

> Personally, I'd call this a drawback, since C is the lingua franca of
> opensource daemon-style programs. There are simply fewer people who
> write good C++ than it is who write good C. But I digress.
>

Yeah I guess you're right.

>>  - multiple input ports
>>  - multiple database output
>>  - configurable logs
>
> These sound neat though, although I fail to see how it can be useful to
> have a single daemon output to more than one database since all databases
> worth their salt already have replicating capabilities.
>
>>  - TLS connection
>
> This doesn't parse, or TLS doesn't mean thread-local storage to you.
>

I thought that now TLS is more known as the new name of SSL than of
the name of a low-level feature.

>>  - optimized DB schema
>
> While this is good to hear, as the DB schema of the original NDOutils
> was largely what prevented it from scaling even close to linearly, it
> also makes me quite sad since there's now 3 separate projects that try
> to achieve the same thing, and addon authors (like NagVis, Nagios-BP,
> PNP4Nagios et al) have to add support for all of them if end-users are
> to retain freedom of choice in the backend.
>
> At a first glance, your schema looks remarkably like that of the merlin
> database (which in turn is derived from the monitor_gui database, which
> in turn is derived from the nacoma database), with the major difference
> that you use pluralistic names for your object tables ("hosts" instead
> of "host") and some different names for some of your columns. Since
> NagVis, Nagios-BP and PNP4Nagios already supports the Merlin database,
> perhaps you should have a look and see what would be simple to change
> to conform to that at least.
>

We discovered your project too recently. But that's almost certainly
what we will try to do in the near future.

>>  - multithreaded (use modern processors)
>
> This doesn't buy one so much for an event-daemon running outside Nagios
> as one may think, since Nagios is more than capable of saturating one
> core by itself. Why was this determined necessary?
>

I don't really see what you mean (sorry for my poor english) but I'll
try to explain why our daemon is multithreaded.

Merethis is starting to work with some big client installation with
many pollers. We just want to be able to collect all the event streams
these pollers are sending at a single point. But there's so much data
that the single-threaded ndo2db cannot process all events. So we'd
like to have a broker daemon that can scale on multi-processor
multi-core touchy machines.

>>  - lower network footprint
>>  - lower DB server load (optimized queries)
>>
>
> This sounds worthwhile though.
>

Thanks.

> Hmm. So long as it's not a drop-in replacement I think it'd be better
> to announce it as an NDOUtils alternative. Otherwise you'll most likely
> get a lot of complaints from people when it doesn't work with their
> ndo database.
>

I guess my words were not careful enough. I apologize. It's not yet
planned to be a NDOUtils replacement, but our intention was to propose
this as the new basis of NDOUtils developments.

>> Despite its name Centreon-Broker
>> do not rely on Centreon at all. Also, the name can be changed and more
>> documentation provided. If you're interested you can checkout the code
>> at http://svn.centreon.com/trunk/centreon-broker or the homepage at
>> http://forge.centreon.com/projects/show/centreon-broker .
>>
>> With this software, we try to address the main NDOUtils drawbacks in a
>> modern way. As we have a good code start, we would like to share it
>> with the community and avoid it to reinvent the wheel. So feel free to
>> tell us what you think about it.
>>
>
> Where can I find the public repository to pull the latest changes from?
>

With Subversion you can directly checkout the repository over HTTP :
 $> svn co http://svn.centreon.com/trunk/centreon-broker

Best regards,

-- 
Matthieu KERMAGORET | Développeur

mkermagoret at merethis.com

MERETHIS est éditeur du logiciel Centreon.

------------------------------------------------------------------------------