On Wed, Jan 25 2017, Afek, Ifat (Nokia - IL) wrote: > As we see it, alarms can be generated by different sources – Aodh, Vitrage, > Nagios, Zabbix, etc.
I think "generated" is the wrong word here. Aodh does not generate any alarms: it allows users to create them. And then it evaluates them and triggers them. Nagios and Zabbix do *exactly* the same thing: users defined alarms and they are evaluated and triggered by Nagios/Zabbix. The particularity of Aodh is that it does gather nor store data itself (as Nagios and Zabbix do) but is only a definition and evaluation of alarms. So you can implement what Nagios and Zabbix do in Aodh. And you could use Nagios instead of Aodh (instead that it has no REST API so…). Vitrage seems to me to be a middle man, which indeed, seems to *generate* (create) alarms based on thing it sees triggered by Nagios, Zabiix or Aodh. IIUC. > 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. This "specialization" you describe is entirely artificial. Aodh can triggers alarm on the physical layer. It already does if you monitor your hardware with e.g. SNMP or IPMI, puts data in Gnocchi and create alarm rules based on those metrics. And it could be extended to do more (that'd be cool :) What Vitrage does is using the existing software that might be (already) deployed (Nagios, Zabbix) and consolidate things. > 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. I don't see in the case of Vitrage why alarms should be stored by Aodh and not by Nagios, for example. What the rationale? To circle back to the original point, the main question that I asked and started this thread is: why, why Aodh should store Vitrage alarms? What are the advantages, for both Aodh and Vitrage? So far the only answer I read is "well we though Aodh would be a central storage place for alarm". So far it seems it has more drawbacks than benefits: worst performances for Vitrage, confusion for users and more complexity in Aodh. As I already said, I'm trying to be really objective on this. I just really want someone to explain to me how awesome this will be and why we should totally go toward this direction. :-) Cheers, -- Julien Danjou ;; Free Software hacker ;; https://julien.danjou.info
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev