Open Stack

Hi,


Sorry for my late response...

It seems like a fundamental question whether we should have rich function or intelligence in on-the-fly event alarm evaluation. I think we can add simple operations (like aggregating alarm) in aodh evaluator, and other operations (like deducing with referring some external DB) should be done outside of the evaluation process to reduce impact on other evaluations. But, if we separate too much, then there will be many interactions between two services that makes slow to finish sequence of alarm handling.

One approach we can take, is that you configure aodh to pass each row event (e.g. each VM downed) wrapped in alarm notification to vitrage, then do some operation (e.g. deducing, aggregating) and store resource-level alarm without any alarm_actions, so that users can see the alarms in horizon view. This may not require alarm evaluation, so we can forget the problem I raised (cache refresh interval).

BTW, is it useful to have on-the-fly evaluation of combination alarm with event alarms for alarm aggregation or other cases?

Horizon view is the different topic. Maybe we can reduce the number of alarms listed in user view by creating raw alarms in admin space that is not visible from end user, or using relevant severity or tag so that user can filter out uninterested alarms.


Best regards,
Ryota


-----------------------------------
"Ryota Mibu" <r-mibu at cq.jp.nec.com>
NEC Corporation