...
and the meter code itself can be found here: https://github.com/openstack/collectd-ceilometer-plugin/blob/master/collectd_ceilometer/meters/base.py. 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 | 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
Looking at a combine Schema. This schema describes the collectd internal types, and the ceilometer fields that reference them
Code Block | ||||
---|---|---|---|---|
| ||||
{
"$schema": "http://json-schema.org/draft-04/schema#",
"title": "collectd Base Schema",
"description": "A schema that defines the collectd meters and events",
"definitions": {
"value list": {
"description": "Statistics in collectd consist of a value list",
"type": "object",
"properties": {
"values" : {
"type": "array",
"anyOf" : [
{ "type" : "object", "properties" : { "absolute" : { "type" : "number" } } },
{ "type" : "object", "properties" : { "counter" : { "type" : "number" } } },
{ "type" : "object", "properties" : { "derive" : { "type" : "number" } } },
{ "type" : "object", "properties" : { "gauge" : { "type" : "number" } } }
]
},
"value length" : {
"description": "The number of values in the data set",
|
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
This schema describes the collectd internal types. This schema will be referenced from other mapping schema.
Code Block | ||||
---|---|---|---|---|
| ||||
{ "$schema": "http://json-schema.org/draft-04/schema#", "title": "collectd Base Schema", "description": "A schema that defines the collectd meters and events", "definitions": { "value list": { "description": "Statistics in collectd consist of a value list", "type": "object"number" }, "propertiestime" : { "description"values" : {: "Time stamp at which the value was collected", "type": "array"number" }, "anyOfInterval" : [ { { "typedescription" : "object", "properties" : { "absolute" : { "type" : "number" } } }, interval at which to expect a new value", { "type" : "object", "properties"number" }, "host" : { "counter" : { "type" : "number" } } }, "description": "used to identify the host", { "type" : "object", "properties" : { "derivestring" }, "plugin" : { "type" "description": "number" } } }, used to identify the plugin", { "type" : "object", "propertiesstring" }, "plugin instance" : { "gauge" : { "type" : "number" } } } "description": "used to group a set of values together", ]"type": "string" }, "value lengthtype" : { "description": "Theunit numberused ofto valuesmeasure in the data seta value", "type": "numberstring" }, "timetype instance " : { "description": "Time stamp at which the value was collectedused to distinguish between values that have an identical type", "type": "numberstring" }, "Intervalmetadata" : { "description": "interval at which to expectan opaque data structure that enables the passing of additional information about a newvalue valuelist", "type": "numberstring" } }, }, "hostnotifications" : { "description": "usedNotifications in tocollectd identifyare thegeneric hostmessages", "type": "stringobject", },"properties": { "pluginseverity" : { "description": "used to identify the plugincan be one of OKAY, WARNING, and FAILURE", "type": "string" }, "plugin instancetime" : { "description": "usedTime tostamp groupat awhich setthe ofevent valueswas togethercollected", "type": "stringnumber" }, "typemessage" : { "description": "unitThe used to measure a valuenotification message", "type": "string" }, "type instance host" : { "description": "used to distinguishidentify between values that have an identical typethe host", "type": "string" }, "metadataplugin" : { "description": "anused opaque data structure that enables the passing of additional information about a value listto identify the plugin", "type": "string" } }, }, "notificationsplugin instance" : { "description": "Notifications in collectd are generic messagesused to group a set of values together", "type": "objectstring", "properties": {}, "severitytype" : { "description": "canunit be one of OKAY, WARNING, and FAILUREused to measure a value", "type": "string" }, "timetype instance " : { "description": "Time stamp at which the event was collectedused to distinguish between values that have an identical type", "type": "numberstring" }, "messagemetadata" : { "description": "The notification messagean opaque data structure that enables the passing of additional information about a value list", "type": "string" } }, } }, "hostcounter_name": :[ { {"description$ref": "used to identify the host", "type": "string"#/definitions/value list/plugin"}, {"$ref": "#/definitions/value list/plugin instance"} }], "plugincounter_unit": :[ { "description {"$ref": "used to identify the plugin", "type": "string" }, "plugin instance" : { "description": "used to group a set of values together", "type": "string" }, "type" : { "description": "unit used to measure a value", "type": "string" }, "type instance " : { "description": "used to distinguish between values that have an identical type", "type": "string" }, "metadata" : { "description": "an opaque data structure that enables the passing of additional information about a value list", #/definitions/value list/type_instance"}, {"$ref": "#/definitions/value list/type"} ], "counter_volume": { "$ref": "#/definitions/value list/values" }, "resource_id": [ {"$ref": "#/definitions/value list/host"}, {"$ref": "#/definitions/value list/plugin"}, {"$ref": "#/definitions/value list/plugin instance"} ], "timestamp": { "$ref": "#/definitions/value list/time" }, "resource_metadata": { "$ref": "#/definitions/value list/metadata" }, "source": { "type": "string" }, } }"user_id": { "type": "string" } } |
...
collectd to ceilometer mapping example
Issues:
Proposal 1 is too highlevel high level 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):
...