Hi, monasca looks overcomplicated for the purposes we need. Also it requires Kafka which is Java based transport protocol. I am proposing Sensu. It's architecture is tiny and elegant. Also it uses rabbitmq as transport so we won't need to introduce new protocol.
-- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Mon, Nov 24, 2014 at 10:55 AM, Przemyslaw Kaminski < pkamin...@mirantis.com> wrote: > I proposed monasca-agent in a previous mail in this thread. > > P. > > > On 11/21/2014 04:48 PM, Fox, Kevin M wrote: > > How about this? > https://wiki.openstack.org/wiki/Monasca > > Kevin > > ------------------------------ > *From:* Dmitriy Shulyak > *Sent:* Friday, November 21, 2014 12:57:45 AM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Fuel] fuel master monitoring > > > I have nothing against using some 3rd party service. But I thought this >> was to be small -- disk monitoring only & notifying the user, not stats >> collecting. That's why I added the code to Fuel codebase. If you want >> external service you need to remember about such details as, say, duplicate >> settings (database credentials at least) and I thought this was an overkill >> for such simple functionality. >> > > Yes, it will be much more complex than simple daemon that creates > notifications but our application is operating in isolated containers, and > most of the resources cant be discovered from any particular container. So > if we will want to extend it, with another task, like monitoring pool of > dhcp addresses - we will end up with some kindof server-agent architecture, > and this is a lot of work to do > > Also, for a 3rd party service, notification injecting code still needs >> to be written as a plugin -- that's why I also don't think Ruby is a good >> idea :) >> >> Afaik there is a way to write python plugins for sensu, but if there is > monitoring app in python, that have friendly support for extensions, I am > +1 for python > > >> So in the end I don't know if we'll have that much less code with a 3rd >> party service. But if you want a statistics collector then maybe it's OK. >> >> I think that monitoring application is fits there, and we kindof > already introducing our whell for collecting > statistic from openstack. I would like to know what guys who was working > on stats in 6.0 thinking about it. So it is TBD > > > > _______________________________________________ > OpenStack-dev mailing > listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev