[openstack-dev] [aodh][vitrage] Aodh generic alarms

Julien Danjou julien at danjou.info
Wed Jan 25 15:12:40 UTC 2017


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170125/ee61061d/attachment.pgp>


More information about the OpenStack-dev mailing list