[openstack-dev] [telemetry][ceilometer] New project: collectd-ceilometer-plugin
gord at live.ca
Fri Jan 29 16:08:24 UTC 2016
On 29/01/2016 10:48 AM, Foley, Emma L wrote:
>> So, metrics are grouped by the type of resource they use, and each metric has to be listed.
>> Grouping isn't a problem, but creating an exhaustive list might be,
>> since there are 100+ plugins  in collectd which can provide
>> statistics, although not all of these are useful, and some require
>> extensive configuration. The plugins each provide multiple metrics,
>> and each metric can be duplicated for a number of instances, examples: .
>> Collectd data is minimal: timestamp and volume, so there's little room to find interesting meta data.
>> It would be nice to see this support integrated, but it might be very
>> tedious to list all the metric names and group by resource type without any form of Do the resource definitions support wildcards? Collectd can provide A LOT of metrics.
> One also has to put into balance the upside of going through Ceilometer, as Gnocchi has direct support for statsd:
> Supporting statsd would require some more investigation, as collectd's statsd plugin supports reading stats from the system, but not writing them.
> Also, what are the usage figures for gnocchi? How many people use it, and how easy is it to convert existing deployments to use gnocchi? I mean, if someone was upgrading, would their data be preserved?
> How easy is it to consume gnocchi statistics using an external system/application?
> I'm not against the idea, but it requires a little more consideration.
Gnocchi is intended to solve the use case of timestamp+value type data,
that's essentially how it stores it. the best way i would describe it
is, if you use ceilometer statistics command, you should probably be
using Gnocchi. if you use ceilometer sample-list, it's arguable whether
Gnocchi or legacy Ceilometer db is right. so basically do you want
slower, full-fidelity data (ceilometer) or do you want responsive,
light-weight data (gnocchi)
Gnocchi implements the concept of archive policies which basically
dictates how much or little is store. it's purpose is to rollup and
pre-calculate data so less is stored, and as a side effect, is more
response as it has less clutter to deal with. in theory, you could
define a granularity to store everything with no roll ups so all the
data is preserved, but even though we store timestamp+value: the more
you store, the bigger the size.
More information about the OpenStack-dev