[openstack-dev] [ceilometer][aodh][vitrage] Raising custom alarms in AODH

Julien Danjou julien at danjou.info
Mon Dec 7 09:59:50 UTC 2015


On Mon, Dec 07 2015, AFEK, Ifat (Ifat) wrote:

> Our goal is to get as much information as we can from various data 
> sources. If you connect Nagios to telemetry project, and we can get 
> nagios alarms directly from Aodh, it would be great. Is it something 
> that you planned on doing for Mitaka?

Unfortunately nobody planned to work on a Nagios -> Ceilometer/Gnocchi
connector. That maybe a good idea, and the fact that is not planned is
not necessarily a blocker. If someone wants to jump in…

> Our current use cases focus on giving value to the cloud admin. These 
> are mostly UI use cases; the admin will be able to:
>
> - view the topology of his environment, the relations between the 
> physical, virtual and applicative layer and the statuses all resources
> - view the alarms history (there is an existing blueprint for it[1])
> - view alarms about problems that Vitrage deduced could happen, even
> if no other OpenStack component reported these problems (yet)
> - view RCA information about the alarms

I find it odd to have UI use cases first, as their terribly large for a
MVP. Unless Vitrage already exists and you have all the code figured
out. :)

The way I see the big pictures, Vitrage should be done as some sort of
an engine on top of Ceilometer/Gnocchi/Aodh and leverage them to do RCA
analysis. So what's missing in those projects to make that happen should
be done, and Vitrage should start as a MVP; and then we can iterate,
both on Vitrage side and both on the telemetry projects.

I have the feeling that you're trying to bite a too large portion at
once and that you may crash because of that.

> In order to support these use cases, we will get input from various 
> data sources, process and evaluate it based on configurable templates, 
> trigger new alarms in Aodh and calculate RCA information. 
> On top of it, we will have Vitrage API to query the information and
> show it in horizon. 
> In case you haven't seen in yet, our high level architecture is on 
> Vitrage main page[2], and in the coming days we plan to document also 
> the lower level design.

I just looked at it, at it's very interesting. All the high level
functionalities make sense and provide values. But if you try to solve
them all 5 at once, I'm afraid you're going to either build a monster
(with a lot of overlap with other projects, hard to maintain, etc) or
just crash because you'll be blocked by all other OpenStack projects.
That's the big issue when starting to build a project on top of others
OpenStack bricks.

Overall I'm just saying that because it's still not clear to me which
part you're trying to solve in this thread and how we can help you. What
can we provide in our projects, that you miss, that could help you,
concretely? What feature we need to work on next?

It would be awesome to have _one_ use-case described end-to-end that you
would like to solve with Vitrage, leveraging various OpenStack projects,
that you cannot solve right now because of missing pieces. Then we could
start identifying these missing pieces and implement/fix them. :-)

-- 
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/20151207/2333c24f/attachment.pgp>


More information about the OpenStack-dev mailing list