<div dir="ltr">Hi list,<div><br></div><div>Right now in collectd we have read, write, notification and logging plugins which cover most our use cases.</div><div><br></div><div>I think the model falls short when implementing plugins like aggregation, chaining or threshold. It seems as though we are missing an intermediate endpoint to plug in metric manipulation when collection windows end.</div>

<div><br></div><div>As some of you may know I've been playing with a lib which implements generic metric manipulation, with a simple language (example syntax: <a href="https://gist.github.com/pyr/7070364" target="_blank">https://gist.github.com/pyr/7070364</a>)</div>

<div><br></div><div>Now that the syntax is well implemented in a contained library, I'm looking for ways to implement it. I see two ways that "mangling" plugins might want to interact with collectd:</div><div>

<br></div><div>- in a streaming fashion: processing metrics as they come in</div><div>- in a block fashion: processing a full window of collected metrics</div><div><br></div><div>Writing a streaming mangling plugin is an easy task, the "aggregation" plugin is such an example, it registers a read plugin then marks the metrics it generates with an attribute to avoid looping. filter_chains also implement a similar mechanism allowing simple streaming handling.</div>
<div><br></div><div>Writing block handling plugins is much more difficult, there doesn't seem to be an idea of a full metric window event. So writing such plugins now need to be done in one of two ways:</div><div><br>
</div><div>- accumulate metrics and trigger processing at regular intervals</div><div>- accumulate metrics and trigger processing when enough events have been input</div><div><br></div><div>My current design expects a full window of metrics, it is a "pure" function which for a specific window of metrics and configuration syntax will output the same window of metrics augmented with a sink (a destination write plugin) and potentially a state.</div>
<div><br></div><div>This approach has the drawback of forcing accumulation at some point, which might be a problem on aggregation instances but will be negligible on node-local instances (actually given the in-memory size of metrics, it would take a very busy aggregation instance to make this noticeable / problematic).</div>
<div><br></div><div>The simplest way of implementing this seems to be queuing up metrics in the sent to the write plugin and scheduling processing when the read function is called (waiting for a small delay to leave time for other read plugins to submit their metrics).</div>
<div><br></div><div>My current questions are:</div><div><br></div><div>- are collectd users at large interested by an all-encompassing mangling plugin (superseding the functionality found in chains, thresholds and aggregatio plugins) ?</div>
<div>- would most people prefer a configuration that integrates in the main collectd.conf ? It seems a bit unwieldy to me but could be doable</div><div>- is there a way I missed to accumulate metrics between poll intervals in a sound way ?</div>
<div><br></div><div>Thanks for your help putting this together!</div><div>  - pyr</div><div><br></div><div><br></div>
</div>