metricstransformprocessor: Snap timestamps to the previous second/minute

[csmehta]

Is your feature request related to a problem? Please describe. I am trying to group by metrics coming from different workers to the collector.

    - include: app.counter.job.input-row
          action: update
          operations:
            - action: aggregate_labels
              aggregation_type: sum
              label_set: []

But for this to be effective timestamps have to match as well.

Describe the solution you'd like Ability to snap timestamp to nearest second/minute based on config.

    - include: app.counter.job.input-row
          action: update
          operations:
            - action: update_timestamp
              round_to_nearest: 1m
            - action: aggregate_labels
              aggregation_type: sum
              label_set: []

Describe alternatives you've considered None

Additional context This will help reduce the outgoing metric volume, considering we don't require sub-second visibility into the metric.

[kamalmarhubi]

@csmehta if you're willing to either use Honeycomb's build or build your own with the builder, take a look at https://github.com/honeycombio/opentelemetry-collector-configs/tree/main/timestampprocessor

[nicolasgere]

Did you found a solution there?

[github-actions[bot]]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

[github-actions[bot]]

Pinging code owners for processor/metricstransform: @dmitryax. See Adding Labels via Comments if you do not have permissions to add labels yourself.

[dmitryax]

Given that this processor will be replaced with transform processor going forward, I don't think we should invest in any kind of time aggregation. Probably a better approach is to start with introducing timestamp trimming functionality to the transform processor.

[github-actions[bot]]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• processor/metricstransform: @dmitryax

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[github-actions[bot]]

This issue has been closed as inactive because it has been stale for 120 days with no activity.