Versions Compared

Old Version 16

changes.mady.by.user Unknown User (maryamtahhan)

Saved on

compared with

New Version 17

changes.mady.by.user Unknown User (maryamtahhan)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 fieldcollectd 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
languagebash
linenumberstrue
{
	"$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
languagebash
linenumberstrue
{
	"$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):
...