[Nagios-devel] New Nagios implementation proposal

Andreas Ericsson ae at op5.se
Thu Feb 4 08:08:21 UTC 2010


Sorry for taking so extremely long to respond to this. Christmas and
everything that went with it came in between and then I forgot about
it until I did some spring-cleaning in my inbox.

On 12/18/2009 03:32 PM, nap wrote:
> On Fri, Dec 18, 2009 at 2:03 PM, Andreas Ericsson<ae at op5.se>  wrote:
>> On 12/18/2009 12:42 PM, nap wrote:
>>> On Fri, Dec 18, 2009 at 10:49 AM, Andreas Ericsson<ae at op5.se>    wrote:
>>> I don't imagine how many lines we need to add for just add a new
>>> property in service. And the modules recompilation too.
>>>
>>
>> Because it's not written optimally, ofcourse. A better design would
>> have used macros to recognize, parse and obtain values of the core
>> structures. That way you add new properties in two places. In the
>> structure and once in the struct describing how to parse the value,
>> where you also set rules for valid input. Using macros makes it
>> extremely simple to make a little data go a long way.
> Yes but such a modification need a lot of rewrite in xdata/*c.
> 

Well, a fairly large rewrite of xdata/*.c scares me less than a major
rewrite in base/checks.c, for instance. We might as well go the full
mile here, imo.


>>>
>>> Are you agree for a next mailing list meeting in 6 months? All others
>>> core dev too? (I still hope for my Christmas gift :) )
>>>
>>
>> Why in 6 months? Work with me now and we can make Nagios 4 happen with
>> process pools and distributed checking builtin instead. Isn't that the
>> major gripe right now?
> OK. Let's do that :)
> I will keep my implementation as a proof of concept and quick specs
> validations for some things I think about (like critical_is_warning,
> hot_periods, or inverse_ok_critical that I will speak about in the
> next mail) or the realm role in the distributed environment.
> 

I'd rather let things like "negate" deal with "inverse_ok_critical"
and their ilk.

> I think the distributed is a Merlin things (unless you want to make
> the distributed capability a core functionality) and we can speak
> about it in the merlin list. Maybe we can look if a distant object lib
> can be used to factorize code.
> 

If core nagios learns to accept check results and commands via a socket
the only reason left for Merlin to exist is to update a database.

>>>>
>>>> Why not look into how we can implement the more important parts of
>>>> your design in C instead? It shouldn't really be hard, but I need
>>>> to get time from my boss to help out on that.
>>> Yes we can take some ideas for putting them into the code. But it is
>>> not a long term solution. If I'm wrong, we will only lose 6 month and
>>> gain a good competition :)
>>>
>>
>> Well, creating a new monitoring tool without a userbase or a developer
>> base isn't really a long term solution either. The best program in the
>> world is utterly useless if nobody uses it.
> True. But a stagnant open source program is a dead one too. I think we
> shouldn't be so sure that Nagios users will always be Nagios users.
> This discution show us that quite a lot of people want Nagios to go on
> and not just stay in it's current glory.
> 

Everybody except its competitors want Nagios to move forward. It's just
that todays codebase has grown unwieldy, and that makes for less than
stellar design decisions simply because the work involved would be so
huge. Large parts of it could do with a rewrite.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.




More information about the Nagios-devel mailing list