Re: [Nagios-devel] New Nagios implementation proposal
Posted: Tue Dec 01, 2009 8:43 pm
--000e0cdfce50267f210479b0cfdc
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I don't want to sound negative, but the performance of your clone with
"echo; exit;" checks isn't really interesting. In a real-world Nagios
installation, checks take a *long* time to execute because they are
dependent on so many factors external to the local machine.
To get more realistic numbers, I would suggest using a plugin that does a
random-length sleep, between 0 and 10 seconds long.
The reason why your numbers are not realistic is because you're testing for
the wrong thing: in your test environment, the system spends most of its
time spawning and handling processes, reporting back data etc. Of course
you'll get better performance by drastically reducing the total population
of processes on the machine. But in a real-world Nagios environment, there
will be a lot of time spent waiting on the network & remote machines - this
time is simply not present in your test case.
This is not to say that I don't believe that your solution may be an
improvement or have better performance - it is saying that nobody knows,
because your test parameters are not anything like the real world.
All the best and looking forward to seeing your code,
Martin Melin
On Tue, Dec 1, 2009 at 8:07 PM, William Leibzon wrote=
:
>
> Go and program it but don't hope that this will ever become nagios4 -
> nagios name is trademark and its entirely up to Ethan what it gets used f=
or.
> But that does not mean its bad to have different compatible (as far as
> config and database and frontened).
>
> Nagios has very long history so chances of rewrite in different language
> are very low although I kind-of hope people would open up to at least C++=
.
> But as far as language for something alike nagios, but new, python is not
> bad but its rather inflexible in how it forces you to write (both good an=
d
> bad, don't start pointless discussion here) and does not give you quite a=
s
> much flexibility for memory and few other ops. Also looking at your
> architecture I immediately see that best language for it is probably Erla=
ng,
> but then finding people to support and develop it further would be a lot
> more difficult. So if you want to do it in python go for it, just don't h=
ope
> that id would become nagios4 but do report back on your progress time-tim=
e
> if you like (this would call for plugins written in python too, and
> preferred language is actually perl). Personally if I'm to consider
> rewriting nagios in interpreted language I'd wait for Perl6 to come out,
> it'd be taken a lot better by nagios users.
>
> On Tue, Dec 1, 2009 at 9:09 AM, nap wrote:
>
>> Hi list,
>>
>> I would like to have your feed back about a (unfinished)
>> reimplementation of Nagios named "Shinken" I wrote in Python that is
>> faster and more modular than the current Nagios implementation in C
>> (yes faster, you read correctly. I was the first surprised by that).
>>
>> =3D=3D The Shinken's history =3D=3D
>> Few months, I start to work on a proof of concept for Nagios focus on
>> distributed environments and performances. The main goal was to look
>> for a distributed and high availability architecture. I was also
>> thinking that Nagios' performances were quite good, but we can have
>> more.
>>
>> For quick test and development, I used Python. I thought a process
>> pool can make Nagios be quicker instead of forking a new process to
>> kill it few seconds after for each checks. I also bypass the reaping
>> way of Nagios : reading flat file is just too slow. Instead, the
>> results are a structure that is send directly to the scheduler. No
>> files, more performances. To be equal to Nagios, I add the same
>> monitoring logic in the scheduler : HARD/SOFT states, dependencies
>> (parents, servicedep, hostdep, etc) and database export (Merlin).
>> Shinken used the standard Nagios conf file.
>>
>> And the perf are quite good : with a Nagios3, a small check (do a
>> echo + exit) and a medium range server I ru
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I don't want to sound negative, but the performance of your clone with
"echo; exit;" checks isn't really interesting. In a real-world Nagios
installation, checks take a *long* time to execute because they are
dependent on so many factors external to the local machine.
To get more realistic numbers, I would suggest using a plugin that does a
random-length sleep, between 0 and 10 seconds long.
The reason why your numbers are not realistic is because you're testing for
the wrong thing: in your test environment, the system spends most of its
time spawning and handling processes, reporting back data etc. Of course
you'll get better performance by drastically reducing the total population
of processes on the machine. But in a real-world Nagios environment, there
will be a lot of time spent waiting on the network & remote machines - this
time is simply not present in your test case.
This is not to say that I don't believe that your solution may be an
improvement or have better performance - it is saying that nobody knows,
because your test parameters are not anything like the real world.
All the best and looking forward to seeing your code,
Martin Melin
On Tue, Dec 1, 2009 at 8:07 PM, William Leibzon wrote=
:
>
> Go and program it but don't hope that this will ever become nagios4 -
> nagios name is trademark and its entirely up to Ethan what it gets used f=
or.
> But that does not mean its bad to have different compatible (as far as
> config and database and frontened).
>
> Nagios has very long history so chances of rewrite in different language
> are very low although I kind-of hope people would open up to at least C++=
.
> But as far as language for something alike nagios, but new, python is not
> bad but its rather inflexible in how it forces you to write (both good an=
d
> bad, don't start pointless discussion here) and does not give you quite a=
s
> much flexibility for memory and few other ops. Also looking at your
> architecture I immediately see that best language for it is probably Erla=
ng,
> but then finding people to support and develop it further would be a lot
> more difficult. So if you want to do it in python go for it, just don't h=
ope
> that id would become nagios4 but do report back on your progress time-tim=
e
> if you like (this would call for plugins written in python too, and
> preferred language is actually perl). Personally if I'm to consider
> rewriting nagios in interpreted language I'd wait for Perl6 to come out,
> it'd be taken a lot better by nagios users.
>
> On Tue, Dec 1, 2009 at 9:09 AM, nap wrote:
>
>> Hi list,
>>
>> I would like to have your feed back about a (unfinished)
>> reimplementation of Nagios named "Shinken" I wrote in Python that is
>> faster and more modular than the current Nagios implementation in C
>> (yes faster, you read correctly. I was the first surprised by that).
>>
>> =3D=3D The Shinken's history =3D=3D
>> Few months, I start to work on a proof of concept for Nagios focus on
>> distributed environments and performances. The main goal was to look
>> for a distributed and high availability architecture. I was also
>> thinking that Nagios' performances were quite good, but we can have
>> more.
>>
>> For quick test and development, I used Python. I thought a process
>> pool can make Nagios be quicker instead of forking a new process to
>> kill it few seconds after for each checks. I also bypass the reaping
>> way of Nagios : reading flat file is just too slow. Instead, the
>> results are a structure that is send directly to the scheduler. No
>> files, more performances. To be equal to Nagios, I add the same
>> monitoring logic in the scheduler : HARD/SOFT states, dependencies
>> (parents, servicedep, hostdep, etc) and database export (Merlin).
>> Shinken used the standard Nagios conf file.
>>
>> And the perf are quite good : with a Nagios3, a small check (do a
>> echo + exit) and a medium range server I ru
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]