On Wed, Sep 8, 2010 at 3:51 PM, NICOLAS DUPEUX <nicolas.dup...@arkea.com>wrote:
> Hi,
>
> I think that you can extend "nearly fully compatible with Nagios
> configuration" to "nearly fully compatible with Nagios interface". By
> interface, I mean the way shinken talk to his environment (not GUI).
>
> - configuration is compatible
> - status.dat, livestatus and ndo are implemented
> - nagios.cmd interface is the same
> - NRPE can be use to run check
> - NSCA can be use (Although not built-in)
>
> It think this compatibility is quite important as it's ease migration and
> adoption by former nagios users.
>
Yes, this is very important. But I think users can wonders if
"configuration" is in interfaces. We should be even more clear in this point
:
*nearly fully compatible with Nagios configuration
*fully compatible with Nagios interfaces and plugins
Thanks for the correction.
Jean
>
> Regards,
>
> ----- Mail original -----
> > Hi all,
> >
> > In this thread we will discuss about the project vision. It's a small
> > resume
> > about what we cant for this project, and what we won't.
> >
> > We propose : A open monitoring tool that is :
> > *fully and easily scalable,
> > *with high availability,
> > *multi-platform (and not just unix ones),
> > *utf8 compatible,
> > *nearly fully compatible with Nagios configuration
> > *configuration should be in a unique place and should be as easy as
> > possible
> > for the admin to manage it
> > *and fully compatible with plugins,
> > *easy install
> > *not too slow
> > *fun to code :)
> >
> >
> > The 2 first points are for the global architecture. We should be able
> > to
> > scale the load within some minutes without lost the high availability
> > feature. Hopefully for this points it's already done :)
> >
> > Multi platform is also important. If we focus on GNU/Linux only we
> > will
> > loose quite a lot of users need for Windows environments. Of course
> > such
> > features inherited from Nagios are unix only like named pipes, but we
> > should
> > promote some other way for users to bypass this (like commands send to
> > livestatus or in a webbased API for example). Such "os limited" points
> > should be if possible limited in modules. (named pipes will be modules
> > in
> > the future for example).
> >
> > UTF8 compatible : ¤§² should be a valid name for a server... ok, it's
> > a joke
> > :) But some users want to have Japanese and Chinese characters. UFT8
> > is not
> > a option in the 21century ;)
> >
> > Nearly compatible with Nagios configuration : you saw the "nearly".
> > Yes,
> > Shinken is not a Nagios fork. And it will never be 100% compatible
> > with it.
> > Because some Nagios parameters will never be useful in our
> > architecture like
> > OCSP (it's only use for Ha, we already have it),
> > external_command_buffer_slots (why limit it? it's just some strings!
> > some Mo
> > ram more is not such a problem) or retained_host_attribute_mask (is
> > someone
> > use it?). We should be able to manage them. But is it useful?
> > No. Users won't use them, and there a plenty others configuration part
> > to
> > improve (service_dependencies simply defined in services as with
> > parents for
> > hosts, or have a way to SMS will be only send the night for a contact
> > for
> > example). Let focuses on what users want first. If we have some
> > additional
> > times we can backport some features if it do not make the code ugly.
> > But
> > it's not a priority. Users wishes are.
> >
> > Fully compatible with plugins : plugins are the key of the monitoring
> > system. It's here that the real smart thing is, not in the core, even
> > with
> > "alike cloud system". It's easy to be fully compatible with (we are).
> > So let
> > still be it, and do not complexify the plugins part. Easy plugins is
> > why
> > Zenoss did not crush Nagios.
> >
> > Easy install : the installation process should be as automated and
> > easy as
> > possible. And it's a sysadmin that talk here :)
> >
> > Not too slow : yes, we do not say "ultra huge performances". We got
> > scalability. with decent speed, it can be easy to all sysadmin to have
> > what
> > he want. Of course put 20 pollers servers where 1 is enough in the
> > first
> > version is not acceptable. But hunting the last few percent of
> > performance
> > always cost a lot in code hacking, making it far more hard to
> > maintain. Let
> > this few percent where they are, we don't need them.
> >
> > Fun to code : the code should be "good". Technical debt should always
> > be
> > paid one day. So let do good code, without if possible hacks. We can
> > wait
> > some few weeks for a good solutions if it make the code better (and
> > still
> > funny to hack!).
> > Another point to say is that nobody wants to touch and experiment with
> > old
> > C-code. But Shinken's Python code (and the fresh air it brings) will
> > inspire
> > people to develop visions of future features.
> > Python's readability and the needlessness of a compile cycle should
> > motivate
> > people to actually play around with the code and try new things. This
> > will
> > be the source of inspiration. So the "Fun to code" is not just for
> > fun, but
> > for real improvements :p
> >
> >
> >
> > That was what we want to have (and already got in fact for the major
> > part).
> >
> > For what we do not want, we think the major point is a WebUI. There
> > plenty
> > of good ones around us, like Thruk, Ninja or Centreon. Let us
> > concentrate to
> > our primary job, doing a great monitoring tool, not a monitoring
> > solution.
> >
> > If someone want to do a Shinken specific UI why not, but it should do
> > something more than others. If it's just "I did my own" it's better to
> > propose help to others project to better integrate Shinken (like
> > problem/impact for example that can be a very good tactical overview
> > for
> > Thruk :) or a view to show satellites).
> >
> >
> > What do you think about this vision? We should agree with it, because
> > all
> > features will be put in front of it and should be compatible with it
> > (a
> > feature that will all the scalability thing will not be incorporated
> > to the
> > core but in a module for example).
> >
> > It's all open to discussion, and when it's ready, it will be our
> > vision for
> > some versions, so let be agree with it :)
> >
> >
> > Jean & Gerhard
> >
> >
> ------------------------------------------------------------------------------
> > This SF.net Dev2Dev email is sponsored by:
> >
> > Show off your parallel programming skills.
> > Enter the Intel(R) Threading Challenge 2010.
> > http://p.sf.net/sfu/intel-thread-sfd
> > _______________________________________________
> > Shinken-devel mailing list
> > Shinken-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/shinken-devel
>
> --
> Nicolas DUPEUX <nicolas.dup...@arkea.com>
> Arkea - Domaine Systèmes
> tel : 02.98.00.36.68
>
> --
> Ce message et toutes les pieces jointes (ci-apres le "message") sont
> confidentiels et etablis a l'intention exclusive de ses destinataires.
> Toute utilisation ou diffusion non autorisee est interdite. Tout
> message etant susceptible d'alteration, l'emetteur decline toute
> responsabilite au titre de ce message s'il a ete altere, deforme ou
> falsifie.
> -----------------------------------
> This message and any attachments (the "message") are confidential and
> intended solely for the addressees. Any unauthorised use or
> dissemination is prohibited. As e-mails are susceptible to alteration,
> the issuer shall not be liable for the message if altered, changed
> or falsified.
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Shinken-devel mailing list
> Shinken-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shinken-devel
>
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Shinken-devel mailing list
Shinken-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shinken-devel
