Support for adding static tags to specific meter and/or instruments

[dpk83]

Feature Request

Is your feature request related to a problem?
Yes

If so, provide a concise description of the problem.

Currently, the metric agents/extension that we use is working on adding a feature to direct different metrics to different namespaces. The way this feature is being added is by means of a tag i.e. if a user wants to direct a specific metric to a non-default namespace then the instrument needs to add an additional dimension that carries the namespace to override the default.

It's not feasible for the specific instrument add/record calls to add the specific dimensions as becomes too messy to use. E.g. consider the scenario of third party library that emits metrics. As a service owner I use 10s of 3rd party libraries that emit metrics and I want to emit metrics from different libraries to different namespaces. Not all 3rd party libraries can't be modified to support the same feature so I need an ability to add some static properties for all metrics emitted by meter objects or specific instruments.

Currently .NET instrument APIs don't provide any such mechanism and OpenTelemetry metrics implementation also doesn't provide any such mechanism either.

Describe the solution you'd like:

I should be able to configure some static tags to be included for specific instruments and/or all instruments emitted from a specific meter instance, possibly at the startup configuration time.

What do you want to happen instead? What is the expected behavior?

Describe alternatives you've considered.

There are no straightforward alternatives today when using .NET Meter APIs and OpenTelemetry. The only alternative is to wrap .NET Meter APIs behind custom meter/instrument APIs, so metrics can be customized before they are fed into .NET meter

Additional Context

Add any other context about the feature request here.

[cijothomas]

Meter can have attributes (not yet added in .NET) - https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/api.md#get-a-meter

Will this help you achieve the goal?

[dpk83]

Meter can have attributes (not yet added in .NET) - https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/api.md#get-a-meter
Will this help you achieve the goal?

Attributes at meter level should work for our scenario, and whatever the mechanism is should be efficient.

Will this be added to .NET or OpenTelemetry?

Do you have any timelines for when this will be available? The support for multiple namespace via additional dimension is being added by the MDM team and it won't be really complete without this feature :(

[cijothomas]

Will this be added to .NET or OpenTelemetry?

.NET. (The Meter ctor should be modified to optionally accept this). I don't think was requested to the .NET team, so no timeline. If you are looking for this to arrive this year, then we can ask .NET team for this right now, and see if they can accommodate this for .NET 8

[dpk83]

I requested this from .NET first and Noah said that OTel probably already has this feature or might be the right place to have it so circling back here.

[cijothomas]

If the ask is "Support for attributes in Meter" (https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/api.md#get-a-meter), then this should be in .NET. (Just like schema_url). This is same for Traces too. We can create issues in runtime repo for tracking right away. (it was not a top priority, as there were no asks for this and this is pretty new in spec too)

If the ask is something else, but the above is just a mechanism to achieve your goal, yes, we need to discuss more offline and post back updates here.

[wasker]

Can opening issues in runtime repo be prioritized, please?

I'm surprised that static dimensions is something that is not asked often. I see that some exporters implement this feature (e.g., Geneva), but this is bizarre to me. The static dimension is a property of data emitted by the telemetry system, not the exporter - one should be able to swap out exporters and keep the same set of static dimensions attached to the meter, log, or a trace.

[wasker]

Frankly, the fact that static dimensions support has dependency on .NET runtime doing something is mind boggling to me.

[cijothomas]

I'm surprised that static dimensions is something that is not asked often.

This is not about static dimensions overall - those should be modelled as Resources, which is supported aready.
This issue is about adding attributes at meter level, and the spec only added that late last year : https://github.com/open-telemetry/opentelemetry-specification/blob/main/CHANGELOG.md#v1130-2022-09-19

[cijothomas]

Frankly, the fact that static dimensions support has dependency on .NET runtime doing something is mind boggling to me.

The entire API (for tracing and metrics) is part of System.Diagnostics.DiagnosticSource package from github.com/dotnet/runtime. This repo only has the OTel SDKs. So anything changes to the API (eg: Meter, Counter etc), should come from runtime repo!

[wasker]

I'm surprised that static dimensions is something that is not asked often.

This is not about static dimensions overall - those should be modelled as Resources, which is supported aready.

Do you mind pointing me to the right sample/doc for that, please?

[cijothomas]

https://github.com/open-telemetry/opentelemetry-dotnet/tree/main/docs/metrics/customizing-the-sdk#resource

[joebeernink]

@cijothomas I was attempting to add attributes to the Resource using the .NET provider (i.e. adding the Azure Region, Stamp, dnsdomain) where the app is running in Azure) and using the AzureMonitorMetricExporter to forward to AppInsights... I see the values showing up when I use the AzureMonitorTraceExporter and use the Console Exporter, but the Metrics in the Console don't show the dimensions coming out, and I don't see them in AppInsights.

			.ConfigureResource(resource => {
				resource.AddService(DiagnosticsConfig.ServiceName);
				resource.AddAttributes(customerInstanceConfig.Values);
				}

My question with your statement above "This is not about static dimensions overall - those should be modelled as Resources, which is supported aready", if this means that the resources should be static at creation time (they are), or does this mean that only the "service_name" is currently supported?

[cijothomas]

@joebeernink If resources are showing up in Console Exporter for Metrics, but not showing up in Application Insights, this indicates an issue with Application Insights, and should be reported to Application Insights repo/team.