New component: statefulaggregator

[djluck]

The purpose and use-cases of the new component

A known restriction in the metricstransformprocessor is that aggregation of labels happens within a batch of metrics submitted from a single instance of service. This means that it's impossible to aggregate over the service.instance.id label!

Why is this useful? Aggregating away the label attribute allows us to avoid cardinality explosions. In large scale deployments of services that can run thousands of instances, it's expensive to store the per-instance metrics. This is especially true if this metric has additional labels that have a large set of values.

While keeping per-instance metrics is often useful (e.g. CPU, memory, disk, etc.) there are times when it's not helpful to understand the per-instance breakdown (e.g. user adoption metrics, business KPI metrics) and so storing this information is redundant. This component will allow users to aggregate out the instance label and control the cost of expensive metrics.

Example configuration for the component

processor:
  statefulaggregator:
    metrics: 
        # Support regex matching
      - match: my_metric.*
        aggregate_labels: [ service.instance.id ]
        # Controls how frequently the resulting aggregated metric is published
         interval: 30s
        # TODO: enable different types of aggregation in the future
        # aggregation: sum

And given these two separate batches of metrics:

1. my_metric{service.instance.id ="inst_1", value="a"} 1
   my_metric{service.instance.id ="inst_1", value="b"} 3

2. my_metric{service.instance.id ="inst_2", value="a"} 2
   my_metric{service.instance.id ="inst_2", value="b"} 4

   It would produce the following values:

   my_metric{value="a"} 3
   my_metric{value="b"} 7

Telemetry data types supported

Metrics

Is this a vendor-specific component?

• [ ] This is a vendor-specific component
• [ ] If this is a vendor-specific component, I am proposing to contribute and support it as a representative of the vendor.

Code Owner(s)

No response

Sponsor (optional)

No response

Additional context

I have prototyped a solution that has shown promise- this issue is to understand if the OpenTelemetry project would be keen to adopt it. The code is rough and so needs work but I would be happy to drive the development of this feature.

[atoulme]

OK I'm game. I'll sponsor this.

[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.

[strue36]

What needs to happen next with this? Does @djluck have a prototype that can be used as a starting point?

[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.

[djluck]

Hey, I'm unfortunately very short on time over the next month. Hopefully I'll be able to clean up and contribute the prototype next in September.

[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.