We can sometimes have attributes that can have a high cardinality, which seems to be problematic in the backend. For example, a request path attribute of an Akka Http request can be infinite:
foo/bar/1
foo/bar/2
foo/bar/3
foo/bar/4
...
We could aggregate such paths to one path attribute value: foo/bar/{id}.
To do
investigate if aggregating path attribute in the processor is actually doable and a good idea
see if it's easier than pre-aggregating the paths in mesmer's otel extension
what are the other pros/cons of using the processors?
which approach is better? pre-aggregation (in the otel extension) or the processors (in the collector)? Does it make sense to implement both approaches?
@adamgadomski I'm removing it from the scope of 0.8.0. We don't need this right now. We should focus on ZIO instead. Please reinstate the issue in the 0.8.0 milestone if you think otherwise.
An Opentelemetry Collector can be extended with a "processor": https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/resourceprocessor/README.md. Such a processor can add/remove/modify attributes right before the metric data is exported to a backend, eg. a prometheus instance.
We can sometimes have attributes that can have a high cardinality, which seems to be problematic in the backend. For example, a request path attribute of an Akka Http request can be infinite:
We could aggregate such paths to one path attribute value:
foo/bar/{id}
.To do