Open Stack

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 [1] 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: [2].
>>
>> 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:
>
>    http://gnocchi.xyz/statsd.html
>
>
>
> 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.
>
> Regards,
> Emma
>
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.

cheers,

-- 
gord