Open Stack

Hi Juha,

Smells like a bug in the sample POST API, in the sense that:

  "resource_metadata" : { ... "user_metadata": {"server_group": "Group_B"} }

is flattened to:

  "metadata": { ... "user_metadata.server_group": "Group_B" }

in the metering message generated from the sample.

I'll dig some more and file bug. BTW what exact version are you using?

Cheers,
Eoghan

----- Original Message -----
> Hi Eoghan,
> 
> Thank you. Tried this, but unfortunately it seems the user_metadata part
> causes a failure.
> Command having just AutoScalingGroupName as a metadata goes through ok:
> 
> curl -X POST -H 'X-Auth-Token: f66288ad283d4ee0a322d03c95db2a4b' -H
> 'Content-Type: application/json' -d '[ { "counter_name": "vm_cpu_load",
> "resource_id": "8d326543-cde9-4c3c-9c7e-3973cfbcb057", "resource_metadata"
> : { "AutoScalingGroupName": "tykyauto-Group_B-ljhkoj244qzh" },
> "counter_unit": "%", "counter_volume": 11, "counter_type": "gauge" } ]'
> http://192.168.100.5:8777/v2/meters/vm_cpu_load
> 
> ...but when I add the user_metadata part:
> 
> curl -X POST -H 'X-Auth-Token: f66288ad283d4ee0a322d03c95db2a4b' -H
> 'Content-Type: application/json' -d '[ { "counter_name": "vm_cpu_load",
> "resource_id": "8d326543-cde9-4c3c-9c7e-3973cfbcb057", "resource_metadata"
> : { "AutoScalingGroupName": "tykyauto-Group_B-ljhkoj244qzh",
> "user_metadata": {"server_group": "Group_B"} }, "counter_unit": "%",
> "counter_volume": 11, "counter_type": "gauge" } ]'
> http://192.168.100.5:8777/v2/meters/vm_cpu_load
> 
> ...the following error occurs:
> 
> <43>Apr  4 09:08:56 node-6
> ceilometer-ceilometer.collector.dispatcher.database ERROR: Failed to record
> metering data: not okForStorage
> Traceback (most recent call last):
>   File
> "/usr/lib/python2.7/dist-packages/ceilometer/collector/dispatcher/database.py",
> line 65, in record_metering_data
>     self.storage_conn.record_metering_data(meter)
>   File
> "/usr/lib/python2.7/dist-packages/ceilometer/storage/impl_mongodb.py", line
> 451, in record_metering_data
>     upsert=True,
>   File "/usr/lib/python2.7/dist-packages/pymongo/collection.py", line 487,
> in update
>     check_keys, self.__uuid_subtype), safe)
>   File "/usr/lib/python2.7/dist-packages/pymongo/mongo_client.py", line
> 969, in _send_message
>     rv = self.__check_response_to_last_error(response)
>   File "/usr/lib/python2.7/dist-packages/pymongo/mongo_client.py", line
> 911, in __check_response_to_last_error
>     raise OperationFailure(details["err"], details["code"])
> OperationFailure: not okForStorage
> 
> I have mongo configured as a database for Ceilometer (otherwise
> ceilometer-alarm-evaluator error ERROR: Server-side error: "metaquery not
> implemented" occurs).
> 
> In our environment the following versions of Ceilometer components have
> been installed:
> 
> 2013.2.2:
> ceilometer-agent-central
> ceilometer-alarm-evaluator
> ceilometer-alarm-notifier
> ceilometer-api
> ceilometer-collector
> ceilometer-common
> python-ceilometer
> 
> 1:1.0.5:
> python-ceilometerclient
> 
> Br,
> -Juha
> 
> 
> On 3 April 2014 17:18, Eoghan Glynn <eglynn at redhat.com> wrote:
> 
> >
> > Juha,
> >
> > Your problem is the embedded period in the metadata key:
> > "metering.server_group"
> >
> > If the metric were gathered by ceilometer itself in the usual way, then the
> > compute agent would transform that problematic payload as follows, from:
> >
> > { ..., "resource_metadata" : { "AutoScalingGroupName":
> > "tykyauto-Group_B-hmknsgn35efz", "metering.server_group": "Group_B" }, ...
> > }
> >
> > to:
> >
> > { ..., "resource_metadata" : { "AutoScalingGroupName":
> > "tykyauto-Group_B-hmknsgn35efz", "user_metadata": {"server_group":
> > "Group_B"} }, ... }
> >
> > You should follow the same pattern.
> >
> > Cheers,
> > Eoghan
> >
> > ----- Original Message -----
> > > Maybe this is because I didn't fill in instance related metadata (scaling
> > > group name and such) to the REST call I made when adding custom metric
> > data
> > > to Ceilometer. I tried to create metric data again, now with metadata
> > > filled:
> > >
> > > $ curl -X POST -H 'X-Auth-Token: 0722fcd0f403425bb8564808c37e8dc8' -H
> > > 'Content-Type: application/json' -d '[ { "counter_name": "vm_cpu_load",
> > > "resource_id": "e7eaf484-38b6-4689-8490-40aa8f0df8ae",
> > "resource_metadata" :
> > > { "AutoScalingGroupName": "tykyauto-Group_B-hmknsgn35efz",
> > > "metering.server_group": "Group_B" }, "counter_unit": "%",
> > "counter_volume":
> > > 11, "counter_type": "gauge" } ]'
> > > http://192.168.100.5:8777/v2/meters/vm_cpu_load
> > >
> > > ...but as a result I can see the following error in ceilometer log:
> > >
> > > <43>Apr 3 14:24:01 node-6
> > ceilometer-ceilometer.collector.dispatcher.database
> > > ERROR: Failed to record metering data: not okForStorage
> > > Traceback (most recent call last):
> > > File
> > >
> > "/usr/lib/python2.7/dist-packages/ceilometer/collector/dispatcher/database.py",
> > > line 65, in record_metering_data
> > > self.storage_conn.record_metering_data(meter)
> > > File
> > "/usr/lib/python2.7/dist-packages/ceilometer/storage/impl_mongodb.py",
> > > line 451, in record_metering_data
> > > upsert=True,
> > > File "/usr/lib/python2.7/dist-packages/pymongo/collection.py", line 487,
> > in
> > > update
> > > check_keys, self.__uuid_subtype), safe)
> > > File "/usr/lib/python2.7/dist-packages/pymongo/mongo_client.py", line
> > 969, in
> > > _send_message
> > > rv = self.__check_response_to_last_error(response)
> > > File "/usr/lib/python2.7/dist-packages/pymongo/mongo_client.py", line
> > 911, in
> > > __check_response_to_last_error
> > > raise OperationFailure(details["err"], details["code"])
> > > OperationFailure: not okForStorage
> > >
> > > Hmm. What am I doing wrong here?
> > >
> > > Thanks,
> > > -Juha
> > >
> > >
> > >
> > >
> > > On 2 April 2014 14:04, Juha Tynninen < juha.tynninen at tieto.com > wrote:
> > >
> > >
> > >
> > > Hi,
> > >
> > > I'm sending custom Ceilometer metrics from inside VM instance with REST
> > call
> > > to
> > > http://192.168.100.5:8777/v2/meters/vm_cpu_load .
> > >
> > > This is successful and I can see the entered metric data with Ceilometer:
> > >
> > > # ceilometer sample-list -m vm_cpu_load
> > > -q="resource_id=91951d0a-9a43-4894-99fb-ac67a1098771" | tail -n +4 |
> > head -n
> > > -1 | sort -k 12
> > > ...
> > > | 91951d0a-9a43-4894-99fb-ac67a1098771 | vm_cpu_load | gauge | 2.6 | % |
> > > | 2014-03-30T19:20:38.080000 |
> > > | 91951d0a-9a43-4894-99fb-ac67a1098771 | vm_cpu_load | gauge | 3.3 | % |
> > > | 2014-03-30T19:20:58.223000 |
> > > | 91951d0a-9a43-4894-99fb-ac67a1098771 | vm_cpu_load | gauge | 2.6 | % |
> > > | 2014-03-30T19:21:18.078000 |
> > > | 91951d0a-9a43-4894-99fb-ac67a1098771 | vm_cpu_load | gauge | 28.6 | % |
> > > | 2014-03-30T19:21:38.894000 |
> > > | 91951d0a-9a43-4894-99fb-ac67a1098771 | vm_cpu_load | gauge | 1.0 | % |
> > > | 2014-03-30T19:21:59.370000 |
> > > | 91951d0a-9a43-4894-99fb-ac67a1098771 | vm_cpu_load | gauge | 2.3 | % |
> > > | 2014-03-30T19:22:20.255000 |
> > > | 91951d0a-9a43-4894-99fb-ac67a1098771 | vm_cpu_load | gauge | 0.3 | % |
> > > | 2014-03-30T19:22:40.351000 |
> > > | 91951d0a-9a43-4894-99fb-ac67a1098771 | vm_cpu_load | gauge | 1.9 | % |
> > > | 2014-03-30T19:23:00.317000 |
> > >
> > > # ceilometer meter-list | grep vm_cpu_load | grep
> > > 91951d0a-9a43-4894-99fb-ac67a1098771
> > > | vm_cpu_load | gauge | % | 91951d0a-9a43-4894-99fb-ac67a1098771 |
> > > | 2884e2f624224227bb63d77a040126e6 | a12aee6f0da04d8d976eb4b761a73e14 |
> > >
> > > I've started the instance with a Heat template having AutoScaling
> > defined and
> > > I'm trying to base the scaling actions to this custom metric.
> > > The problem is that the autoscaling does not occur.
> > >
> > > "Resources" : {
> > >
> > > "Group_B" : {
> > > "Type" : "AWS::AutoScaling::AutoScalingGroup",
> > > "Properties" : {
> > > "AvailabilityZones" : { "Fn::GetAZs" : ""},
> > > "LaunchConfigurationName" : { "Ref" : "Group_B_Config" },
> > > "MinSize" : "1",
> > > "MaxSize" : "3",
> > > "Tags" : [
> > > { "Key" : "metering.server_group", "Value" : "Group_B" }
> > > ],
> > > "VPCZoneIdentifier" : [ { "Ref" : "Private Application Subnet ID" } ]
> > > }
> > > },
> > > ...
> > > "Group_B_Config" : {
> > > "Type" : "AWS::AutoScaling::LaunchConfiguration",
> > > "Properties": {
> > > "ImageId" : { "Ref" : "Image Id" },
> > > "InstanceType" : { "Ref" : "Instance Type" },
> > > "KeyName" : { "Ref" : "Key Name" }
> > > }
> > > },
> > > ...
> > > "CPUAlarmHigh": {
> > > "Type": "OS::Ceilometer::Alarm",
> > > "Properties": {
> > > "description": "Scale-up if CPU is greater than 80% for 60 seconds",
> > > "meter_name": "vm_cpu_load",
> > > "statistic": "avg",
> > > "period": "60",
> > > "evaluation_periods": "1",
> > > "threshold": "80",
> > > "alarm_actions":
> > > [ {"Fn::GetAtt": ["ScaleUpPolicy", "AlarmUrl"]} ],
> > > "matching_metadata":
> > > {"metadata.user_metadata.server_group": "Group_B" },
> > > "comparison_operator": "gt",
> > > "repeat_actions" : true
> > > }
> > > },
> > > ...
> > > nova show 91951d0a-9a43-4894-99fb-ac67a1098771
> > > ...
> > > | metadata | { u'AutoScalingGroupName': u'tykyauto-Group_B-76nubm24bnf6',
> > > | u'metering.server_group': u'Group_B'} |
> > >
> > > For some reason the statistics query does not return anything when
> > queried
> > > with the scaling group name, this probably explains why auto scaling
> > actions
> > > are not triggered...? Without query parameter data is returned. Data is
> > > returned also ok for some other counter e.g. for cpu_util.
> > >
> > > # ceilometer statistics -m vm_cpu_load -q
> > > metadata.user_metadata.server_group=Group_B -p 60
> > >
> > > # ceilometer statistics -m vm_cpu_load
> > >
> > +--------+----------------------------+----------------------------+-------+-----+-------+--------+---------------+------------+----------------------------+----------------------------+
> > > | Period | Period Start | Period End | Count | Min | Max | Sum | Avg |
> > > | Duration | Duration Start | Duration End |
> > >
> > +--------+----------------------------+----------------------------+-------+-----+-------+--------+---------------+------------+----------------------------+----------------------------+
> > > | 0 | 2014-03-28T21:14:34.370000 | 2014-03-28T21:14:34.370000 | 520 |
> > 0.3 |
> > > | 100.0 | 5865.5 | 11.2798076923 | 170135.609 |
> > 2014-03-28T21:14:34.370000 |
> > > | 2014-03-30T20:30:09.979000 |
> > >
> > +--------+----------------------------+----------------------------+-------+-----+-------+--------+---------------+------------+----------------------------+----------------------------+
> > >
> > > Any ideas what might be the cause for this behaviour...?
> > >
> > > Many thanks,
> > > -Juha
> > >
> > >
> > > _______________________________________________
> > > Mailing list:
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> > > Post to     : openstack at lists.openstack.org
> > > Unsubscribe :
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> > >
> >
>