Re: [Nagios-devel] New Nagios implementation proposal
Posted: Tue Dec 01, 2009 7:07 pm
--001636d3392b00fe6e0479af77e5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Go and program it but don't hope that this will ever become nagios4 - nagio=
s
name is trademark and its entirely up to Ethan what it gets used for. 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 ar=
e
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 and bad,
don't start pointless discussion here) and does not give you quite as much
flexibility for memory and few other ops. Also looking at your architecture
I immediately see that best language for it is probably Erlang, 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 hope tha=
t
id would become nagios4 but do report back on your progress time-time if yo=
u
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 run at 10000 checks in
> 5minutes (latency near 1s), 30K with full tweaks. With my tool, I run
> 150K !!
>
>
> =3D=3D The global architecture =3D=3D
> For the Architecture, I think we must use the Unix Way of doing things
> : one tool by usage. For now, Nagios do nearly every things : reads
> conf, schedule, launch checks and raise notifications. I try an
> architecture where the administrator can have any host/services he
> wants and the daemons are just resources to manage this. The
> architecture I propose is the following :
> *Arbiter : a daemon that read the configuration, cut it automatically
> (keep relations like parents in the same conf) in N confs, where N is
> the number of schedulers we have. It dispatchs the configuration and
> also read the orders in nagios.cmd and dispatch orders to schedulers.
> *Schedulers : do the scheduling by looking at states of
> hosts/services. It just do checks/notifications/event handlers queues
> for others daemons. Same things for event broker informations : it's
> just a queue.
> *pollers : use a processes Pool, get checks to launch in schedulers
> and returns results to schedulers.
> *reactionners : same than pollers, but for notifications and event
> handlers.
> *brokers : get event broker informations from schedulers and "do
> things" why them (like create the
...[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
Go and program it but don't hope that this will ever become nagios4 - nagio=
s
name is trademark and its entirely up to Ethan what it gets used for. 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 ar=
e
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 and bad,
don't start pointless discussion here) and does not give you quite as much
flexibility for memory and few other ops. Also looking at your architecture
I immediately see that best language for it is probably Erlang, 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 hope tha=
t
id would become nagios4 but do report back on your progress time-time if yo=
u
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 run at 10000 checks in
> 5minutes (latency near 1s), 30K with full tweaks. With my tool, I run
> 150K !!
>
>
> =3D=3D The global architecture =3D=3D
> For the Architecture, I think we must use the Unix Way of doing things
> : one tool by usage. For now, Nagios do nearly every things : reads
> conf, schedule, launch checks and raise notifications. I try an
> architecture where the administrator can have any host/services he
> wants and the daemons are just resources to manage this. The
> architecture I propose is the following :
> *Arbiter : a daemon that read the configuration, cut it automatically
> (keep relations like parents in the same conf) in N confs, where N is
> the number of schedulers we have. It dispatchs the configuration and
> also read the orders in nagios.cmd and dispatch orders to schedulers.
> *Schedulers : do the scheduling by looking at states of
> hosts/services. It just do checks/notifications/event handlers queues
> for others daemons. Same things for event broker informations : it's
> just a queue.
> *pollers : use a processes Pool, get checks to launch in schedulers
> and returns results to schedulers.
> *reactionners : same than pollers, but for notifications and event
> handlers.
> *brokers : get event broker informations from schedulers and "do
> things" why them (like create the
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]