[Openstack] [Ceilometer/Heat/Havana]: Ceilometer statistics not available for custom metrics.
Juha Tynninen
juha.tynninen at tieto.com
Wed Apr 2 11:04:29 UTC 2014
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140402/e3e91db9/attachment.html>
More information about the Openstack
mailing list