...
| Code Block | ||
|---|---|---|
| ||
metric:
- name: 'meter name'
event_type: 'event name'
type: 'type of meter eg: gauge, cumulative or delta'
unit: 'name of unit eg: MB'
volume: 'path to a measurable value eg: $.payload.size'
resource_id: 'path to resource id eg: $.payload.id'
project_id: 'path to project id eg: $.payload.owner'
|
The meter.yaml file, it contains the sample definitions for all the meters that Telemetry can collect.The required fields for sending a sample using the command-line client are:
ID of the corresponding resource. (
--resource-id)Name of meter. (
--meter-name)Type of meter. (
--meter-type)Predefined meter types:
- Gauge
- Delta
- Cumulative
Unit of meter. (
--meter-unit)Volume of sample. (
--sample-volume)
POST /v2/meters/(meter_name)
Post To post a list of new Samples to Telemetry.
| Parameters: |
|
|---|---|
| Return type: |
Ceilometer OldSample schema
| Code Block | ||
|---|---|---|
| ||
{
"counter_name": "instance",
"counter_type": "gauge",
"counter_unit": "instance",
"counter_volume": 1.0,
"message_id": "5460acce-4fd6-480d-ab18-9735ec7b1996",
"project_id": "35b17138-b364-4e6a-a131-8f3099c5be68",
"recorded_at": "2015-01-01T12:00:00",
"resource_id": "bd9431c1-8d69-4ad3-803a-8d4a6b89fd36",
"resource_metadata": {
"name1": "value1",
"name2": "value2"
},
"source": "openstack",
"timestamp": "2015-01-01T12:00:00",
"user_id": "efd87807-12d2-4b38-9c70-5f5c2ac427ff"
} |
Currently data normalization or mappings are managed manually in the ceilometer write plugin:
A snippet from Units for meter samples are set manually in https://github.com/openstack/collectd-ceilometer-plugin/blob/master/collectd_ceilometer/units.py:
...
and the meter code itself can be found here: https://github.com/openstack/collectd-ceilometer-plugin/blob/master/collectd_ceilometer/meters/base.py fields . Fields in the ceilometer write plugin at the moment are mapped as follows:
| ceilometer meter field | collectd field |
|---|---|
counter_name | plugin, type |
counter_type | "gauge"-> "gauge", "derive"-> "delta "absolute"-> "cumulative" "counter"-> "cumulative" |
counter_unit | unit |
counter_volume | value |
message_id | - |
project_id- | obtained from the auth token |
recorded_at | - |
resource_id | hostname, plugin_instance, type_instance |
resource_metadata | meta |
source | collectd |
timestamp | time | user_id | -
_metadata | meta |
source | collectd |
timestamp | time |
user_id | obtained from credentials to obtain the auth token |
As you can see, the meter sample aren't mapped to look like the meter samples submitted from an OpenStack service where there is overlap.
So where there is overlap in meters in terms of the samples collected by collectd and published to ceilometer, we would like to describe the mapping in a generic way.
Proposal 1
collectd json schema
...
Proposal 1 is too highlevel and doesn't get into the internals of what meters get mapped to what and what units should be associated with the meters/events - in essence it doesn't improve on what's there today for overlapping meters. However is good for new meters.
Proposal 2
collectd simple mapping schema (note this is too clunky so it can be ignored):
...