Open Stack

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 <
pkaminski at 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 at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141124/dbd0a2fb/attachment.html>