@opengamer29 thanks for your contribution! However, I don't think this is the right thing to do here. How about creating a new processor that accumulates (cumulative sums) the values per metric-series and output the summed value for each field? This is closer to what you want and you get the absolute sample points (at least relative to Telegraf's start) in the highest frequency you want... You afterwards can still aggregate the metrics...

@srebhan It definitely makes sense. Thank you for your feedback. I'll change this MR following your recommendation this or next week.

I'm not sure what should I do with that Lint plugin readmes / run-readme-linter check. It's something new and other processor plugins don't have it. It will be great to add some recommendations to contributing documentations.

@opengamer29 ignore the linter issues for now, we are working on it.

@opengamer29 any chance you address the comments in the near future? We would really love to ship this plugin with v1.35.0...

@opengamer29 any chance you address the comments in the near future? We would really love to ship this plugin with v1.35.0...

I'm on vacation right now, but I will look through all the comments next week. Do you think it will work for you?

@srebhan I’m keeping in mind my use case with Prometheus output, where I only need the cumulative sum, without retaining the original metrics. Based on your experience, do you foresee broader use cases for this processor plugin?

Would it make sense to split the functionality into two separate plugins:
– a processor that appends cumulative sums to existing metrics,
– an aggregator that outputs only the cumulative sum (similar to the initial commits)?

The cumulative sum aggregator would be a perfect fit for my case — minimal memory overhead, no need for additional deduplication, and a single pass through the metrics array.

The processor-based approach does look more flexible and may be useful in other use cases. However, for my use case, it’s not optimal in terms of memory usage and performance. I feel it might be more efficient and transparent to continue using a Starlark-based aggregator on my end.

You could keep this as a processor, but then use for example aggregators.final to emit only 1 (the last) metric in your desired interval.

See the docs on the difference between processors and aggregators.

You could keep this as a processor, but then use for example aggregators.final to emit only 1 (the last) metric in your desired interval.

See the docs on the difference between processors and aggregators.

Yes, using a processor combined with aggregators.final is technically possible, but it still introduces some overhead. If this plugin ends up being used primarily in scenarios like mine, where only the final cumulative value is needed, it will always be paired with the aggregators.final or similar. Do you see this as an expected usage?

That's why I asked about the cumulative aggregator plugin.

@opengamer29 sorry for the late reply, I'm travelling currently... Yes I do imagine a broader use of this plugin as e.g. some energy meters can only report the change between two gather cycles. So having a generic operation like the cumulative sum makes a lot of sense.

This being said, we have to make sure that the operation is generic but also covers your use case. Moreover, we have to keep in mind the other plugins we have and not double functionality we already provide as this would create a maintenance nightmare over time.

This being said, a drop_original_fields flag is doing just the same as the general fieldexclude. Hard resetting the metrics also hardly makes sense. However, you use case of expiring metrics does make sense. So my suggestion is to keep the expiry flag(s) but name it as such. You also could add an option for setting the "sum-field-suffix" with an empty suffix meaning override the original fields.
Regarding the processor vs aggregator discussion I fully second @Hipska! We should keep this as a processor because it makes sense! An aggregator always introduces additional delays in the data processing. For some operations that's the only way but it is unnecessary for a cumulative sum.

Does that help?

@opengamer29 could you please run make fmt on the PR!? This should fix the linter issues. Besides from the linter issues we are good to go...

make fmt doesn't make any changes even after rebase to main branch. I also tried run gofmt -w manually, still nothing...
What do I miss?

You could check the actual output of the checks:

  /github/workspace/plugins/processors/cumulative_sum/README.md:3:80 MD009/no-trailing-spaces Trailing spaces [Expected: 0 or 2; Actual: 1]
  /github/workspace/plugins/processors/cumulative_sum/README.md:4:80 MD009/no-trailing-spaces Trailing spaces [Expected: 0 or 2; Actual: 1]
  /github/workspace/plugins/processors/cumulative_sum/README.md:8:81 MD009/no-trailing-spaces Trailing spaces [Expected: 0 or 2; Actual: 1]

plugins/processors/cumulative_sum/README.md:1: metadata is missing

plugins/processors/cumulative_sum/cumulative_sum_test.go:4:1  gci  File is not properly formatted
1 issues:
* gci: 1

You could check the actual output of the checks:

@Hipska Thank you for provided output. I don't have any output after make fmt command. I don't know why :(

And what should you do with metadata is missing. Following rules.go it's something new in project and none of processors have it. Should I add something like?

⭐ Telegraf v1.35.0
🏷️ statistics
💻 all

The output came from the failing checks here on GitHub.

Download PR build artifacts for linux_amd64.tar.gz, darwin_arm64.tar.gz, and windows_amd64.zip.
Downloads for additional architectures and packages are available below.

☺️ This pull request doesn't significantly change the Telegraf binary size (less than 1%)