[openstack-dev] [Ceilometer][AODH] Timeout Event Alarms
liusheng
liusheng1175 at 126.com
Wed Aug 5 04:12:23 UTC 2015
Hi,
Maybe the event transformer is needed in some use cases to generate new
events or do transformations like the samples handling. but for this
timeout event alarming requirement, the 'timeout' of alarms will be
various, it not a good idea of changing event_pipeline.yaml to generate
new events based on events timeout when we need an event-timeout alarm.
and also, the access of event pipeline definitions to users is
inadvisable. I personally think it'd better to implement the second
option and based on Ryota's proposal.
Best Regards
Liusheng
在 2015/8/5 3:36, gord chung 写道:
> hi Igor,
>
> i would suggest you go with second option as i believe your
> implementation will overlap and reuse some of the functionality Ryota
> would code for his alarm spec [1]. also, since Aodh is working on an
> independent release cycle, it'll give you some more time as i don't
> think we'd be able to get this into Liberty if we went the pipeline route.
>
> [1]
> http://specs.openstack.org/openstack/ceilometer-specs/specs/liberty/event-alarm-evaluator.html
>
> On 04/08/2015 10:00 AM, Igor Degtiarov wrote:
>> Hi folks,
>>
>> On our meatup we agreed to add timeout event alarms [1](Event-Base
>> Alarming part).
>> In ToDo task "Сhoose the optimal way for timeout alerting implementation"
>> Now we have two proposition for implementation:
>> - first is to add timeout param in event pipeline (transformer part)
>> [2]
>> -- weakness of this approach is that we cannot allow user change
>> config files, so only administrator will be able to set rules for
>> timeout events alarms, and that is not what we are expecting from alarms.
>> - second is additional optional parameters in event alarms
>> description like sequence of required events and timeout threshold.
>> Event alarm evaluator looks thru getting events and evaluates alarm
>> if even one event from required sequence isn't received in set
>> "timeout".[3]
>>
>> It seems that second approach is better it doesn't have restrictions
>> for end user.
>> Hope for your help in choosing optimal way for implementation.
>> (In specs review there is silence now)
>>
>> [1]
>> https://wiki.openstack.org/wiki/Meetings/Ceilometer/Liberty_Virtual_Mid-Cycle
>> [2] https://review.openstack.org/#/c/162167
>> [3] https://review.openstack.org/#/c/199005
>>
>> Igor Degtiarov
>> Software Engineer
>> Mirantis Inc.
>> www.mirantis.com <http://www.mirantis.com>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> --
> gord
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/20150805/fcfe0c55/attachment.html>
More information about the OpenStack-dev
mailing list