On 25/01/17 08:39 AM, Afek, Ifat (Nokia - IL) wrote: > 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.
so the purpose of 'generic alarms' proposal was just to 'log' the alarm from vitrage in a central place? tbh, i don't know if that's what we want to store in aodh. i think it should ideally be handling active alarms, not past alarms. if we store a vitrage alarm in aodh, what would the use case be for querying it? the alarm occurred and vitrage has already sent a notification warning. if i were to query aodh, what additional information would i be retrieving? it would seem much more useful to send that information to panko so you can see that alarm event with other past events relating to the resource. cheers, -- gord __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
