Support Processor & Aggregator Plugins

[sparrc]

Required for all PRs:

• CHANGELOG.md updated (we recommend not updating this until the PR has been approved by a maintainer)
• Sign CLA (if not already signed)
• README.md updated (if adding a new plugin)

TODO:

• Cleanup TODOs
• Handle name_override, name_suffix, name_prefix in running aggregator.
• Handle adding adhoc tags in running aggregator.
• drop_original arg: Provide a way of dropping the original metric after it gets sent to the aggregator(s)
• Determine how to handle adding aggregate metrics that are getting gathered at the same time as the aggregator flushing. Maybe introduce a configurable delay before each ticker fires.
• Print processors and aggregators in the telegraf auto-generated config file
• support for --processor-filter and --aggregator-filter command-line args.
• Document contributing guidelines for processor and aggregator plugins.
• Document configuration of processor and aggregator plugins.
• Support aggregator plugin period argument. Flush the aggregator period outside of the plugin itself.

closes #1726

[dgnorton]

This drops metrics at the beginning of each period.

[sparrc]

If you look at the <-periodT.C case I tried to make it so that each interval is overlapping by the "delay" amount. So for example:

:00 <- 1st period starts
:10 <- 2nd period starts
:10 + delay <- 1st period ends
:20 <- 3rd period starts
:20 + delay <- 2nd period ends

[dgnorton]

But once a metric is read from the channel and dropped, it won't be available on the channel during the next period. Seems like points where end < t < end+delay would have to either go into a buffer or back into the metric chan.

[sparrc]

end is defined as: start + period + delay (see 735a564#diff-65518ad6bfcfeef60e9881df019b20a8R116)

so a metric where end < t < end+delay would always be accepted.

Maybe it's not very clear the way I've done it. Instead of defining end to include the delay, I could make this if-statement include the delay.

[dgnorton]

Ah, I see. I missed something in the code earlier. I thought the ticker was firing on period + delay intervals.

[dgnorton]

👍 with changelog update

[johnrengelman]

@sparrc I didn't want to open a new issue for this cause it's just a simple question. If a processor wants to add a Tag to a metric, does it need to copy the whole metric? It seems like Metric.Tags() returns a copy of the map, so modifying it has no affect.

[sparrc]

I think you'd need to, although it would probably be more efficient to add a passthru function to the underlying influxdb points object, which I believe has a some sort of AddTags method: https://github.com/influxdata/influxdb/blob/master/models/points.go

[johnrengelman]

Yup. That's what I ended up doing in my PR. Thanks.
On Mon, Nov 14, 2016 at 5:45 AM Cameron Sparr notifications@github.com
wrote:

I think you'd need to, although it would probably be more efficient to add
a passthru function to the underlying influxdb points object, which I
believe has a some sort of AddTags method:
https://github.com/influxdata/influxdb/blob/master/models/points.go

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#1777 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA90JDZHq2dsU74l4gYw-d0gWpEY_B7iks5q-EnOgaJpZM4J-3k0
.