Thanks Octo.

Currently the identifier fields are limited in length (127 chars). Hence,
was thinking of a way to store more keys in metadata.

I wanted a way to save hostname, provider service identifier (stats can be
provided by service other than monitored service), monitored service
identifier, metric type, metric subtype.

Each of these identifiers can be multiple key:value pairs.

Given current collectd design , my plan is to use the identifier fields as
follows in the client collectd daemons -

Plugin - provider service identifier
Plugin instance - monitored service identifier
Type - Metric type
Type instance - Metric subtype

Identifiers can be '.' delimited and positional instead of key:value to
save space.

I plan to use my python plugin as a generic plugin to talk to different
kinds of provider services and configure the different services in my .conf.

Will my approach cause any issues with using current or planned features of
collectd ? I am interested in using the aggregation plugin in the server
collectd instances for e.g..



On Oct 21, 2017 1:59 PM, "Florian Forster" <> wrote:

> Hi Dhananjay,
> On Fri, Oct 20, 2017 at 06:41:55PM -0400, Dhananjay Deshpande wrote:
> > Each value list has number of key:value pairs to uniquely identify the
> > value list.
> meta data is *not* used to identify metrics, only host, plugin
> (+instance) and type (+instance) are. If you create multiple metrics
> that only differ in their meta data, collectd will not behave as you
> intend.
> > However, looks like currently I cannot send the metadata from one host
> > to another using network module.
> That's right, the network plugin doesn't currently forward meta data.
> Best regards,
> —octo
> --
> collectd – The system statistics collection daemon
> Website:
> Google+:
> GitHub:
> Twitter:
collectd mailing list

Reply via email to