Open Stack

Hi,

Alarm history and a database are definitely important, but they are not the main issue here.

As we see it, alarms can be generated by different sources – Aodh, Vitrage, Nagios, Zabbix, etc. Each source has its own expertise and internal implementation. Nagios and Zabbix can raise alarms about the physical layer, Aodh can raise threshold alarms and event alarms, and Vitrage can raise deduced alarms (e.g. if there is an alarm on a host, Vitrage will raise alarms on the relevant instances and applications). I would prefer that you view Vitrage the way you view Zabbix, as a project that has a way of evaluating some kinds of problems in the system, and notify about them.

The question is should there be a central place that provides information about *all* alarms gathered in the system, and this includes an API, database, notification mechanism and history. We can implement these in Vitrage (as we already integrate with different datasources and monitors), but we always had in mind that this is part of Aodh project definition.

What do you say?

Best Regards,
Ifat.


On 25/01/2017, 13:19, "Julien Danjou" <julien at danjou.info> wrote:

    On Tue, Jan 24 2017, gordon chung wrote:
    
    > you mean, keep alarm history in aodh and also in panko if needed? i'm ok 
    > with that.
    
    Yeah, IIRC there's an expirer in Aodh for alarm history based on TTL –
    that's enough. That should probably be replaced with just a hard limit on
    the number of history items you have (e.g. 100) and having them the
    older being dropped when the limit is hit.
    
    And if somebody wants a full audit control of what's done, Panko is the
    way to go (you know, bread crumbs ;-).
    
    -- 
    Julien Danjou
    -- Free Software hacker
    -- https://julien.danjou.info