Open Stack

> > 3. There is a thought about watching correlation of multiple alarm
> > histories in one Chart (either Alarm Histories, or the real statistics
> > the Alarm is defined by). Do you think it will be needed? Any real
> > life examples you have in mind?
> 
> I think the first use case is to debug combined alarms.
> There's also a lot of potential to debug an entire platform activity by
> superimposing several alarm graphs.

Yep, this is where it gets useful for admins. For a regular user a basic set of alarms is fine, you just want to react to certain conditions in your app/workload/whatever. But for an admin if you can correlate alarms to hosts and metrics and cross-project resource creation/deletion/etc. and start to understand the cloud as a whole. I think this is an end-game use case that's very valuable, and which many companies have built their entire businesses around (which is to say it's not an easy problem or a small problem, but the need is very real).

> > 4. There is a thought about tagging the alarms by user defined tag, so
> > user can easily group alarms together and then watch them together
> > based on their tag.
> 
> The alarm API don't provide that directly, but you can imagine some sort of
> filter based on description matching some texts.

I'd love to see this as an extension to the alarm API. I think tracking metadata about alarms (e.g. tags or arbitrary key-value pairs) would be tremendously useful.

> > 5. There is a thought about generating a default alarms, that could
> > observe the most important things (verifying good behaviour, showing bad
> behaviour).
> > Does anybody have an idea which alarms could be the most important and
> > usable for everybody?
> 
> I'm not sure you want to create alarm by default; alarm are resources, I don't
> think we should create resources without the user asking for it.

Seconded.

> Maybe you were talking about generating alarm template? You could start
> with things like CPU usage staying at >90% for more than 1 hour, and having
> an action that alerts the user via mail.
> Same for disk usage.

We do this kind of "template" for common user tasks with security group rules already. The same concept applies to alarms.

> > 6. There is a thought about making overview pages customizable by the
> > users, so they can really observe, what they need. (includes
> > Ceilometer statistics and alarms)
> 
> I think that could be as easy as picking the alarms you want in overviews with
> a very small and narrowed graph.

Conceptually easy pickings, non-trivial work. But agreed.

All the best,

    - Gabriel