[openstack-dev] [Ceilometer][Horizon] Exposing and showing associated resource_id within alarms/combined alarms

Eoghan Glynn eglynn at redhat.com
Mon Jun 16 12:33:03 UTC 2014



> Hello guys,
> 
> I was taking a look at the proposed alarm-page designs [1] for the bp:
> https://blueprints.launchpad.net/horizon/+spec/ceilometer-alarm-management-page
> and I saw that the alarms table has a column named “Resource Name”. The
> intention of that column is to show the resources associated within an alarm
> (also for the case of more complex alarms or “combined alarm” if you prefer)
> but right now, ceilometer does only retrieve the associated resources id’s
> inside the “query” param (at least, for the threshold alarms, in the case of
> combined alarms you won’t get any resource id).

I don't really understand what you're getting at with ...

 "ceilometer does only retrieve the associated resources id’s inside
  the “query” param"

But I'll take a guess that you're concerned that ceilometer doesn't
map eagerly from resource ID to resource names?

Ok, let's back up a bit here and level-set ...

* A ceilometer alarm *may* include a resource-based constraint

* The resource-based constraint *may* be based on a resource ID,
  or else on any other aspect of resource metadata that ceilometer
  persists (e.g. in the case of a Heat autoscaling alarm, resource
  ID wouldn't even enter into the equation, instead a group of
  instances is referred to via their common user metadata)

* Either way, the resource constraint isn't evaluated until the
  stats query underpinning the alarm is evaluated

* It has to work this way, as for a start the set of matching
  resources may be different at the time the alarm is evaluated
  as compared to when the alarm was defined

> From the Horizon POV, getting the resource name represents a lot of work and
> a huge impact in performance because, if we choose to show this “Resource
> Name” column, we would need to do, for each alarm retrieved :
> 
> 1. Check the query parameter and then extract the resource id

Note the resource ID is not a required constraint. Not all alarms will
include this constraint. So it shouldn't be assumed in the UI.
 
> 2. Then, depending on the type of resource (because it could be a vm, an
> image, etc.) ask for its name to the appropriate service (not sure if that
> is right way of doing it)
> 
> 3. Save that name and then show it on the UI
> 
> 
> 
> In the case of combined alarms, not only we’ll have to do all that but also:
> 
> · Extract the alarms_ids used for the alarm combination (which can be also
> combined alarms, so take that into account)
> 
> · For each threshold alarm, run previous 1-3 steps
> 
> o In case of step 3, instead of show the name to the UI, store it into a list
> of resource names that needs to be showed after finishing the processing
> 
> 
> 
> As you can see, for an alarm table of, let’s say 10 combined alarms (which it
> could be a valid use case), we would need to do one call to alarm-list, 20
> calls to alarm-shows and then other 20 calls to each of the service that
> could give us the name of the resources.
> 
> 
> 
> I’m seeing a couple of possible solutions:
> 
> 1) not rendering the “Resource name” column J (not actually an option)
> 
> a. but I know it is the “coward” solution and I also know that showing and
> filtering alarms based on resources it’s a good and necessary feature.

This seems like the only sane solution IIUC, because as stated above there
is *no assumption* of a 1:1 mapping between alarms and resources.

Let me know if I've misunderstood what you're getting at here,

Cheers,
Eoghan
 
> 2) Expose the resource_id as we do with “meter_name”, although we still need
> to ask for the resource name on the horizon side
> 
> a. For the combined alarms, expose a list of resources and (why not) a list
> of meter associated with the combined alarms.
> 
> 3) Save the resource id in the alarm table in a separated column and then
> retrieve it
> 
> a. For combined alarms, save a list of resource_id’s?
> 
> 4) Any solution that you consider J
> 
> 
> 
> 
> 
> Any thoughts around this?
> 
> 
> 
> Thanks for all the help!
> 
> Christian
> 
> 
> 
> [1]:
> http://people.redhat.com/~lsurette/OpenStack/Alarm%20Management%20-%202014-06-05.pdf
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



More information about the OpenStack-dev mailing list