[processor/spanmetrics] Allow turning off default dimensions

[adam-kiss-sg]

Component(s)

processor/spanmetrics

Is your feature request related to a problem? Please describe.

I would like to use the spanmetrics processor to extract http call metrics. I'm not intrested in the operation/status.code dimensions.

Describe the solution you'd like

I would like an option to turn off default dimensions (service.name, operation, span.kind, status.code), preferably one-by-one.

Describe alternatives you've considered

I tried using metricstransform processor's aggregate_labels option. With v0.64.0 it doesn't work because the timestamp of each data point is slightly different, so the transformer won't merge them.

I think it might be resolved in main by this change, but i'm not sure how to build the main branch with the collector builder, so I couldn't test it.

Additional context

No response

[github-actions]

Pinging code owners:

• processor/spanmetrics: @albertteoh

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

[JaredTan95]

Did you have tried with empty dimensions like:

spanmetrics
    dimensions: []

[adam-kiss-sg]

@JaredTan95 that only controls the "extra" dimensions, the default dimensions are always added.

In the docs:

Each metric will have _at least_ the following dimensions because they are common across all spans:
- Service name
- Operation
- Span kind
- Status code

In the code:

opentelemetry-collector-contrib/processor/spanmetricsprocessor/processor.go

Line 462 in 24ac3f8

func buildKey(dest *bytes.Buffer, serviceName string, span ptrace.Span, optionalDims []dimension, resourceAttrs pcommon.Map) {

// buildKey builds the metric key from the service name and span metadata such as operation, kind, status_code and
// will attempt to add any additional dimensions the user has configured that match the span's attributes
// or resource attributes. If the dimension exists in both, the span's attributes, being the most specific, takes precedence.
//
// The metric key is a simple concatenation of dimension values, delimited by a null character.
func buildKey(dest *bytes.Buffer, serviceName string, span ptrace.Span, optionalDims []dimension, resourceAttrs pcommon.Map) {
	concatDimensionValue(dest, serviceName, false)
	concatDimensionValue(dest, span.Name(), true)
	concatDimensionValue(dest, traceutil.SpanKindStr(span.Kind()), true)
	concatDimensionValue(dest, traceutil.StatusCodeStr(span.Status().Code()), true)

	for _, d := range optionalDims {
		if v, ok := getDimensionValue(d, span.Attributes(), resourceAttrs); ok {
			concatDimensionValue(dest, v.AsString(), true)
		}
	}
}

[albertteoh]

I think it might be resolved in main by this change, but i'm not sure how to build the main branch with the collector builder, so I couldn't test it.

@adam-kiss-sg have you tried: make docker-otelcontribcol and referencing the otelcontribcol tag of the built image in docker/docker-compose?

[adam-kiss-sg]

@albertteoh

Thanks, using that method I could test it and the timestamp issue is resolved.

Unfortunately the same commit caused another issue for me: #16387 and #16388

[github-actions]

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/spanmetrics: @albertteoh

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

[albertteoh]

Hi @adam-kiss-sg, is this requirement still useful to you?

If so, and if your requirement is to get a call count of all HTTP requests, just wondering if this can be achieved through a query in your metrics storage layer by not filtering on any dimensions (i.e. calls_total{}).

For example, to get the total request rate (calculated in a 1m window) across all services, I think the following prometheus query can achieve this:

sum(rate(calls_total[1m]))

[adam-kiss-sg]

Hi @albertteoh !

Yes, this would still be useful. Even thought i could get the metric the way you recommend, having all these labels increases metric cardinality by a lot. On self-hosted prometheus this could potentially result in performance issues. On cloud services (like what we use), they charge based on metrics cardinality. This is most troublesome for Operation.

[github-actions]

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/spanmetrics: @albertteoh

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

[LaserPhaser]

I think we can close it now.

[evan-bradley]

Closing as completed via #23039.