<div dir="ltr">Many thanks again. <div><br></div><div>Seems to be I was missing the Tags definition for AutoScalingGroup in the template:<br>"Tags" : [ { "Key" : "metering.server_group", "Value" : "Group_A" } ]<div>
<br></div><div>Added that and now I can see evaluation occurring and some scaling actions triggered (some exceptions can be seen in the logs, but I'll continue investigations).   </div><div><br></div><div>Br,</div><div>
-Juha</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 12 September 2013 16:32, Eoghan Glynn <span dir="ltr"><<a href="mailto:eglynn@redhat.com" target="_blank">eglynn@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
> Hi,<br>
><br>
> Many thanks, that helped. I no longer see those errors in the log.<br>
<br>
</div>Cool, further responses below.<br>
<div><div class="h5"><br>
> However, even though cpu_util metric data gets inserted to the ceilometer<br>
> db with values bigger than the threshold defined for scaling-up in the<br>
> template (template used can be seen here:<br>
> <a href="https://bugs.launchpad.net/heat/+bug/1223710" target="_blank">https://bugs.launchpad.net/heat/+bug/1223710</a>), no actions get triggered.<br>
> All I see in the ceilometer-alarm-singleton log are "initiating evaluation<br>
> cycle on 2 alarms" entries. No entries in ceilometer-alarm-notifier log.<br>
><br>
> Any ideas / pointers what could be the reason for this...?<br>
><br>
> ---clip---<br>
> 2013-09-12 14:50:30.800 17868 INFO ceilometer.alarm.threshold_evaluation<br>
> [-] initiating evaluation cycle on 2 alarms<br>
> 2013-09-12 14:50:30.811 17868 DEBUG ceilometer.alarm.threshold_evaluation<br>
> [-] evaluating alarm 7676439e-7ed5-4748-80ca-e161083ae8ff evaluate<br>
> /opt/stack/ceilometer/ceilometer/alarm/threshold_evaluation.py:215<br>
> 2013-09-12 14:50:30.816 17868 DEBUG ceilometer.alarm.threshold_evaluation<br>
> [-] query stats from 2013-09-12 11:49:30.815225 to 2013-09-12<br>
> 11:50:30.815225 _bound_duration<br>
> /opt/stack/ceilometer/ceilometer/alarm/threshold_evaluation.py:99<br>
> 2013-09-12 14:50:30.841 17868 DEBUG ceilometer.alarm.threshold_evaluation<br>
> [-] stats query [{'field': u'metadata.user_metadata.server_group', 'value':<br>
> u'Group_A', 'op': 'eq'}, {'field': 'timestamp', 'value':<br>
> '2013-09-12T11:50:30.815225', 'op': 'le'}, {'field': 'timestamp', 'value':<br>
> '2013-09-12T11:49:30.815225', 'op': 'ge'}] _statistics<br>
> /opt/stack/ceilometer/ceilometer/alarm/threshold_evaluation.py:120<br>
> 2013-09-12 14:50:30.847 17868 DEBUG ceilometerclient.common.http [-] curl<br>
> -i -X GET -H 'X-Auth-Token:<br>
<br>
</div></div>So this ^^^ is the statistics query used to select cpu_util metrics for<br>
all instances that are part of the autoscaling group - this is done on the<br>
basis of the instance user metadata including an attribute called server_group<br>
that's set to Group_A.<br>
<div class="im"><br>
> 2013-09-12 14:50:31.206 17868 DEBUG ceilometer.alarm.threshold_evaluation<br>
> [-] sanitize stats [] _sanitize<br>
> /opt/stack/ceilometer/ceilometer/alarm/threshold_evaluation.py:111<br>
> 2013-09-12 14:50:<a href="tel:31.220%2017868" value="+13122017868">31.220 17868</a> DEBUG ceilometer.alarm.threshold_evaluation<br>
> [-] pruned statistics to 0 _sanitize<br>
<br>
</div>Since the statistics returned are effectively empty, the first thing to check<br>
is whether the existing instance has the correct user metadata set by Heat.<br>
<br>
On the basis of the query above, I would expect the instance metadata to<br>
be set as follows:<br>
<br>
  {u'metering.server_group': u'Group_A'}<br>
<br>
Can you check that Heat has the appropriate metadata, with a simple query like:<br>
<br>
  for s in $(nova list | awk -F\| '/ACTIVE/ {print $2}') ; do nova show $s ; done | grep metadata<br>
<br>
<br>
Secondly, looking at the timestamp constraint on the statistics query,<br>
effectively equivalent to:<br>
<br>
  timestamp >= 2013-09-12T11:49:30.815225 ; timestamp <= 2013-09-12T11:50:30.815225<br>
<br>
we see that the threshold evaluator is looking back a total of a single<br>
minute's duration. In order for the cpu_util samples to be available to meet<br>
this requirement depends on the configured cadence for the collection of this<br>
this meter. This defaults out-of-the-box to 600s, whether the alarm requires<br>
it be 60s at  least. Check it's current value via:<br>
<br>
  grep -A 1 cpu_pipeline /etc/ceilometer/pipeline.yaml<br>
<br>
The signature of this issue would be the alarm spending 9 of every<br>
10 minutes in the insufficient_data state. This combined with the Heat<br>
autosclaing cooldown is likely to cause scale-up to suppressed.<br>
<br>
To resolve, simply edit as follows:<br>
<br>
  sed -i '/cpu_pipeline/ {<br>
    N<br>
    s/interval: 600$/interval: 60/<br>
  }' /etc/ceilometer/pipeline.yaml<br>
<br>
and restart the ceilometer compute agent.<br>
<br>
Cheers,<br>
Eoghan<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
> /opt/stack/ceilometer/ceilometer/alarm/threshold_evaluation.py:115<br>
> 2013-09-12 14:50:<a href="tel:31.243%2017868" value="+13124317868">31.243 17868</a> DEBUG ceilometer.alarm.threshold_evaluation<br>
> [-] evaluating alarm 15b78e83-c195-485d-a9f0-fc4d5a1c8fdf evaluate<br>
> /opt/stack/ceilometer/ceilometer/alarm/threshold_evaluation.py:215<br>
> 2013-09-12 14:50:31.252 17868 DEBUG ceilometer.alarm.threshold_evaluation<br>
> [-] query stats from 2013-09-12 11:49:31.250748 to 2013-09-12<br>
> 11:50:31.250748 _bound_duration<br>
> /opt/stack/ceilometer/ceilometer/alarm/threshold_evaluation.py:99<br>
> 2013-09-12 14:50:31.261 17868 DEBUG ceilometer.alarm.threshold_evaluation<br>
> [-] stats query [{'field': u'metadata.user_metadata.server_group', 'value':<br>
> u'Group_A', 'op': 'eq'}, {'field': 'timestamp', 'value':<br>
> '2013-09-12T11:50:31.250748', 'op': 'le'}, {'field': 'timestamp', 'value':<br>
> '2013-09-12T11:49:31.250748', 'op': 'ge'}] _statistics<br>
> /opt/stack/ceilometer/ceilometer/alarm/threshold_evaluation.py:120<br>
> ...<br>
> 2013-09-12 14:50:31.391 17868 DEBUG ceilometer.alarm.threshold_evaluation<br>
> [-] sanitize stats [] _sanitize<br>
> /opt/stack/ceilometer/ceilometer/alarm/threshold_evaluation.py:111<br>
> 2013-09-12 14:50:31.395 17868 DEBUG ceilometer.alarm.threshold_evaluation<br>
> [-] pruned statistics to 0 _sanitize<br>
> /opt/stack/ceilometer/ceilometer/alarm/threshold_evaluation.py:115<br>
> --clap--<br>
><br>
> Br,<br>
> -Juha<br>
><br>
><br>
> On 12 September 2013 10:03, Eoghan Glynn <<a href="mailto:eglynn@redhat.com">eglynn@redhat.com</a>> wrote:<br>
><br>
> ><br>
> ><br>
> > Hi Juha,<br>
> ><br>
> > The problem you're encountering is a known restriction of the sqlalchemy<br>
> > storage<br>
> > driver, which doesn't yet provide the capability to select the statistics<br>
> > for the<br>
> > given Heat autoscaling group on which the scale up/down alarms are based<br>
> > (the so-<br>
> > called metaquery feature).<br>
> ><br>
> > In order for this feature to be present in the ceilometer API service,<br>
> > you'll need<br>
> > to use the mongodb storage driver instead.<br>
> ><br>
> > Thanks,<br>
> > Eoghan<br>
> ><br>
> > ----- Original Message -----<br>
> > > Hi,<br>
> > ><br>
> > > I met the problem when tried to be using autoscaling groups in heat<br>
> > templates<br>
> > > with havana (see:<br>
> > > <a href="https://bugs.launchpad.net/heat/+bug/1223710" target="_blank">https://bugs.launchpad.net/heat/+bug/1223710</a> )<br>
> > ><br>
> > > Can anyone confirm whether the autoscaling should already work with<br>
> > havana?<br>
> > ><br>
> > > Currently the evaluation of the ceilometer alarm/meter data seems to be<br>
> > > failing:<br>
> > ><br>
> > ><br>
> > ><br>
> > > ceilometer-alarm-singleton:<br>
> > > ======================<br>
> > > 2013-09-11 10:16:28.074 5326 INFO ceilometer.alarm.threshold_evaluation<br>
> > [-]<br>
> > > initiating evaluation cycle on 3 alarms<br>
> > > 2013-09-11 10:16:28.108 5326 ERROR ceilometer.alarm.threshold_evaluation<br>
> > [-]<br>
> > > alarm stats retrieval failed<br>
> > > ...<br>
> > > 2013-09-11 10:16:28.108 5326 TRACE ceilometer.alarm.threshold_evaluation<br>
> > File<br>
> > > "/opt/stack/python-ceilometerclient/ceilometerclient/v2/statistics.py",<br>
> > line<br>
> > > 29, in list<br>
> > > 2013-09-11 10:16:28.108 5326 TRACE ceilometer.alarm.threshold_evaluation<br>
> > > '/v2/meters/' + meter_name + '/statistics',<br>
> > > 2013-09-11 10:16:28.108 5326 TRACE ceilometer.alarm.threshold_evaluation<br>
> > > TypeError: cannot concatenate 'str' and 'NoneType' objects<br>
> > ><br>
> > > ceilometer-api:<br>
> > > ===============<br>
> > > 2013-09-11 10:16:28.221 4500 ERROR wsme.api [-] Server-side error:<br>
> > "metaquery<br>
> > > not implemented". Detail:<br>
> > > Traceback (most recent call last):<br>
> > ><br>
> > > File "/usr/local/lib/python2.7/dist-packages/wsmeext/pecan.py", line 70,<br>
> > in<br>
> > > callfunction<br>
> > > result = f(self, *args, **kwargs)<br>
> > ><br>
> > > File "/opt/stack/ceilometer/ceilometer/api/controllers/v2.py", line 693,<br>
> > in<br>
> > > statistics<br>
> > > for c in computed]<br>
> > ><br>
> > > File "/opt/stack/ceilometer/ceilometer/storage/impl_sqlalchemy.py", line<br>
> > 517,<br>
> > > in get_meter_statistics<br>
> > > query = self._make_stats_query(sample_filter, groupby)<br>
> > ><br>
> > > File "/opt/stack/ceilometer/ceilometer/storage/impl_sqlalchemy.py", line<br>
> > 468,<br>
> > > in _make_stats_query<br>
> > > return make_query_from_filter(query, sample_filter)<br>
> > ><br>
> > > File "/opt/stack/ceilometer/ceilometer/storage/impl_sqlalchemy.py", line<br>
> > 137,<br>
> > > in make_query_from_filter<br>
> > > raise NotImplementedError('metaquery not implemented')<br>
> > ><br>
> > > NotImplementedError: metaquery not implemented<br>
> > ><br>
> > ><br>
> > > Many thanks,<br>
> > > -Juha<br>
> > ><br>
> > > _______________________________________________<br>
> > > Mailing list:<br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
> > > Post to     : <a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a><br>
> > > Unsubscribe :<br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
> > ><br>
> ><br>
><br>
</div></div></blockquote></div><br></div>