[openstack-dev] [Fuel] fuel master monitoring
sgolovatiuk at mirantis.com
Mon Nov 24 10:09:17 UTC 2014
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.
On Mon, Nov 24, 2014 at 10:55 AM, Przemyslaw Kaminski <
pkaminski at mirantis.com> wrote:
> I proposed monasca-agent in a previous mail in this thread.
> On 11/21/2014 04:48 PM, Fox, Kevin M wrote:
> How about this?
> *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 at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev