Thanks for the excellent feedback on these, guys! I’ll be working on making updates over the next week and will send a fresh link out when done. Anyone else with feedback, please feel free to fire away.
Best, Liz On Jun 4, 2014, at 12:33 PM, Eoghan Glynn <[email protected]> wrote: > > Hi Liz, > > Two further thoughts occurred to me after hitting send on > my previous mail. > > First, is the concept of alarm dimensioning; see my RDO Ceilometer > getting started guide[1] for an explanation of that notion. > > "A key associated concept is the notion of dimensioning which defines the set > of matching meters that feed into an alarm evaluation. Recall that meters are > per-resource-instance, so in the simplest case an alarm might be defined over > a particular meter applied to all resources visible to a particular user. > More useful however would the option to explicitly select which specific > resources we're interested in alarming on. On one extreme we would have > narrowly dimensioned alarms where this selection would have only a single > target (identified by resource ID). On the other extreme, we'd have widely > dimensioned alarms where this selection identifies many resources over which > the statistic is aggregated, for example all instances booted from a > particular image or all instances with matching user metadata (the latter is > how Heat identifies autoscaling groups)." > > We'd have to think about how that concept is captured in the > UX for alarm creation/update. > > Second, there are a couple of more advanced alarming features > that were added in Icehouse: > > 1. The ability to constrain alarms on time ranges, such that they > would only fire say during 9-to-5 on a weekday. This would > allow for example different autoscaling policies to be applied > out-of-hours, when resource usage is likely to be cheaper and > manual remediation less straight-forward. > > 2. The ability to exclude low-quality datapoints with anomolously > low sample counts. This allows the leading edge of the trend of > widely dimensioned alarms not to be skewed by eagerly-reporting > outliers. > > Perhaps not in a first iteration, but at some point it may make sense > to expose these more advanced features in the UI. > > Cheers, > Eoghan > > [1] http://openstack.redhat.com/CeilometerQuickStart > > > > ----- Original Message ----- >> >> Hi Liz, >> >> Looks great! >> >> Some thoughts on the wireframe doc: >> >> * The description of form: >> >> "If CPU Utilization exceeds 80%, send alarm." >> >> misses the time-window aspect of the alarm definition. >> >> Whereas the boilerplate default descriptions generated by >> ceilometer itself: >> >> "cpu_util > 70.0 during 3 x 600s" >> >> captures this important info. >> >> * The metric names, e.g. "CPU Utilization", are not an exact >> match for the meter names used by ceilometer, e.g. "cpu_util". >> >> * Non-admin users can create alarms in ceilometer: >> >> "This is where admins can come in and >> define and edit any alarms they want >> the environment to use." >> >> (though these alarms will only have visibility onto the stats >> that would be accessible to the user on behalf of whom the >> alarm is being evaluated) >> >> * There's no concept currently of alarm severity. >> >> * "Should users be able to enable/dis-able alarms." >> >> Yes, the API allows for disabled (i.e. non-evaluated) alarms. >> >> * "Should users be able to own/assign alarms?" >> >> Only admin users can create an alarm on behalf of another >> user/tenant. >> >> * "Should users be able to acknowledge, close alarms?" >> >> No, we have no concept of ACKing an alarm. >> >> * "Admins can also see a full list of all Alarms that have >> taken place in the past." >> >> In ceilometer terminology, we refer to this as alarm history >> or alarm change events. >> >> * "CPU Utilization exceeded 80%." >> >> Again good to capture the duration in that description of the >> event. >> >> * "Within the Overview section, there should be a new tab that allows the >> user to click and view all Alarms that have occurred in their >> environment." >> >> Not sure really what "environment" means here. Non-admin tenants only >> have visibility to their own alarm, whereas admins have visibility to >> all alarms. >> >> * "This list would keep the latest alarms." >> >> Presumably this would be based on querying the alarm-history API, >> as opposed to an assumption that Horizon is consuming the actual >> alarm notifications? >> >> Cheers, >> Eoghan >> >> ----- Original Message ----- >>> Hi All, >>> >>> I’ve recently put together a set of wireframes[1] around Alarm Management >>> that would support the following blueprint: >>> https://blueprints.launchpad.net/horizon/+spec/ceilometer-alarm-management-page >>> >>> If you have a chance it would be great to hear any feedback that folks have >>> on this direction moving forward with Alarms. >>> >>> Best, >>> Liz >>> >>> [1] >>> http://people.redhat.com/~lsurette/OpenStack/Alarm%20Management%20-%202014-05-30.pdf >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
