Metrics / instrument to export request durations via OpenTelemetry

[deinok]

The OPC UA implementation should define its own telemetry metrics similar to the approach used in OpenTelemetry for HTTP clients:
https://opentelemetry.io/docs/specs/semconv/http/http-metrics/#http-client

For reference, here’s an example of how DNS resolution metrics are handled in .NET:
https://github.com/dotnet/runtime/blob/main/src/libraries/System.Net.NameResolution/src/System/Net/NameResolutionMetrics.cs

These counters are exposed automatically without requiring explicit user configuration.

After reviewing ITelemetryContext, it appears overly complex for tracking basic request-related information. A simplified, purpose-built telemetry model for OPC UA would improve clarity and maintainability.

Proposed action:

• Define a minimal, self-contained set of OPC UA telemetry metrics (e.g., request histogram).
• Align metric naming and semantics with OpenTelemetry conventions.
• Simplify the integration layer to avoid unnecessary coupling with ITelemetryContext.
• Add this Metrics to the Semantic Conventions of OTel

I'm open to give a minimum viable product that can track durations for requests

[marcschier]

ITelemetryContext provides access to Meter and ILoggerFactory, so adding metrics is the next step. This is tracked already, but we can use this as a marker. @deinok if you have specific metrics you would like to track, please update this issue. Can you provide more details of what your concern is regard "unnessary coupling"? The ITelemetryContext?

[deinok]

Taking Observability.md as a reference, it looks like the Meters and other things are handled by the final user of the library.

What I would like is to have it provided by default. The final user just have to add the Metrics to its OpenTelemetry config.

What I'm propousing, is something like this:

	internal static class OpcUaClientMetrics
	{

                /* Names to be discussed */
		private static readonly Meter meter = new Meter("Opc.Ua.Client");

		private static readonly Histogram<double> opcUaClientRequestDuration = OpcUaClientMetrics.meter.CreateHistogram<double>(
			advice: new InstrumentAdvice<double>()
			{
				HistogramBucketBoundaries = [0.005, 0.01, 0.025, 0.05, 0.075, 0.1, 0.25, 0.5, 0.75, 1, 2.5, 5, 7.5, 10]
			},
			description: "Measures the time taken to perform an OPC UA request.",
			name: "opcua.client.request.duration",
			unit: "s"
		);

		public static void AfterRequest(TimeSpan duration, string serverAddress, int serverPort)
		{
			if (OpcUaClientMetrics.opcUaClientRequestDuration.Enabled)
			{
				var serverAddressKeyValuePair = KeyValuePair.Create<string, object?>("server.address", serverAddress);
				var serverPortKeyValuePair = KeyValuePair.Create<string, object?>("server.port", serverPort);
				OpcUaClientMetrics.opcUaClientRequestDuration.Record(duration.TotalSeconds, serverAddressKeyValuePair, serverPortKeyValuePair);
			}
		}

	}

After we have this as a prototype, open this definitions to standarization on OpenTelemetry like the Http ones:
https://opentelemetry.io/docs/specs/semconv/http/http-metrics/#http-client

And after that create an instrumentation package like this one: https://www.nuget.org/packages/OpenTelemetry.Instrumentation.Http#dependencies-body-tab

So, at the end of the day, the final user will:

• Install Opc.Ua.Client library
• Install OpenTelemetry.Instrumentation.OpcUaClient (Example name)
• Wire the Instrumentation to it's OTel configuration.

[marcschier]

No, the itelemetry context is injectable and there is a default one that is .net compliant and can be wired to otel quite easily by adding the Otel exporter. Nuget or if you don't want to use that any other exporter.

We want to move away from static functions which are not manageable in a large project like this and worse are also global per process, instead we will move to DI across the board.

The instruments you defined can be created from a meter which can be owned by a component. These can then define instruments like in your example.

The interesting question is what are the instruments you need and then we would wire them in. Do you have a list?

[deinok]

I’ve implemented a Meter("Opc.Ua.Client") with a Histogram named opcua.client.request.duration. The design was inspired by the DNS and HTTP instrumentation models.

It likely needs an additional attribute similar to http.request.method, but I haven’t finalized the exact key name yet.

Regarding the use of static functions: my goal is to keep observability simple for most users. It should work out of the box for about 90% of use cases. Those who need to integrate custom telemetry should be able to do so, but without forcing everyone down a complex configuration path.

Something like the System.Net.Http.DelegatingHandler aproach could do the work for complex cases.

[marcschier]

Ok, so I understand you would like to histogram request durations. I have updated the title to cover the request and will add support. The name opc.ua.client for client library seems like a good choice for prefix of instruments in client, essentially using the namespace names all lower caps plus the name of the instrument. For attribute it makes sense to use the service call name, as it is a finite dimension, although it is still a rather large one if combined with another dim such as bucket, we shall see how it works :-)

[deinok]

Yes, seems like by convention, Meters are named like the library. Instruments are defined by the SemCon, and we should try to follow it as much as possible. Also we should take a look on how to add OPCUA as a SemCon (https://opentelemetry.io/docs/specs/semconv/) even if its status is still on develpment, waiting for standarization, so other OPCUA libraries can follow the same