For OpenTelemetry metrics, allow Func<string, string> to be specified to trim the enclosed message types tag

[bbrandt]

Describe the feature.

Is your feature related to a problem? Please describe.

When we see the assembly qualified names in Grafana, the view becomes too cluttered.

Describe the requested feature

Allow a Func<string, string> OpenTelemetryEnclosedMessageTypesMutator to be specified in endpoint config. Where Headers.EnclosedMessageTypes is read in ReceiveDiagnosticsBehavior, call this func to allow the messageTypes string to be modified before tagging the metrics.

Describe alternatives you've considered

Somehow replace ReceiveDiagnosticsBehavior with a custom implementation when configuring my endpoint?

Another alternative is to implement a common behavior across all your NSB-driven microservices to replace the EnclosedMessageTypes header with the Type.FullName for outgoing messages, but this will affect downstream consumers which may or may not be desirable.

Additional Context

No response

[kentdr]

Hi @bbrandt,
Thank you for raising this issue.
We will look into it and consider it for an upcoming enhancement release.

[lailabougria]

Hi @bbrandt, We've reviewed your request, but I don't think we can support this change.
We capture the message headers as tags to provide visibility into message processing behavior. We can't modify the message header content as this would break serialization. If we provide a way to change the captured message headers, it doesn't represent the actual message header that was present, which defeats the purpose of capturing it.

One possible thing we could consider is providing an API that allows you to opt-out from capturing message headers at all or selecting the desired ones, but for such a feature, we'd have to raise a dedicated issue and first understand whether there's a need across the user base. Our current assumption is that users are interested in the message headers and won't generally want to filter any out, as message headers can affect how a message is processed and is, therefore, essential to the span.

I understand this causes a visualization issue, but wouldn't it be more suitable to raise this in Grafana instead? Other tags in other systems (user-defined or libraries) could be longer than what Grafana can appropriately visualize.

[ramonsmits]

The value passed to nservicebus.message_type is just too large. It contains ALL types while it should only contain the first (concrete) type

But additionally that value is just way too large and contains assembly info and what not which is useless in likely all scenarios.

Tags likely should be sanitized by default to only include the FIRST namespace + type name and optionally other details like assembly, version and key as these are not very useful for metrics.

For example, something like:

var telemetry = endpointConfiguration.EnableOpenTelemetry(); 
telemetry.Metrics.MessageTypeTagSanitizer(messageTypes => messageTypes.Substring(0, messageType.IndexOf(","));

If you have "sane" namespace conventions that would result in tag values like SystemX.Sales.OrderCreated. Will not work well when the namespaces leak message type info like SystemX.Sales.Events.OrderCreated.

The problem here is in that unfortunately we leak technical details like assembly and type info into something that likely requires another description. Users might want to strip SystemX. and .Events. literals from such a value.

[ramonsmits]

Our current assumption is that users are interested in the message headers and won't generally want to filter any out, as message headers can affect how a message is processed and is, therefore, essential to the span.

@lailabougria I don't understand this comment in relation with metrics.

[lailabougria]

@ramonsmits Well, I agree with you. Looks like I didn't have enough coffee when I read the issue and misunderstood. I thought this related to the trace tags. Regarding the metrics tag, I completely agree, this is a way too long tag to add to a metric.

This is a good use case, we'll keep it in the backlog and consider it for the next set of work on our OpenTelemetry support. Thanks for raising @bbrandt and my apologies for the confusion.