NServiceBus.Extensions.Diagnostics
NServiceBus.Extensions.Diagnostics copied to clipboard
jbogard
Discriminating between different message types
We've recently introduced this library into one of our NServiceBus endpoints that is hooked up to New Relic through OpenTelemetry. While we are seeing metrics and traces now in New Relic, we don't seem to be able to discriminate between the various message types that are being processed by the endpoint. It would be great if we could see these as different transactions and also have it as a dimension on the metrics. Is this something that could be added? Or are we missing something somewhere?
Are you referring to Command/Event/Reply etc? Unfortunately those aren't in the OpenTelemetry spec. But I do include the NServiceBus headers in the span attributes, there would be one there that is the message intent.
I was referring to the actual message types that your handlers accept, ie. PlaceOrderCommand or OrderShippedEvent.
Actually, come to think of it, I think the name of the message type should be part of the Activity name as well, which it currently is not. Each message that is processed results in an Activity with the name being a summary of the transport being used, causing New Relic to treat them all as the same transaction which obviously they aren't?
The enclosed message types are also in the header. But the span name comes from the OTel standard. If you want something different, you can add an activity listener to modify it if you like.
Hmm, I'm assuming you're referring to this part of the spec. That does seem to limit our options a bit, although I guess the destination name isn't exactly specified what it should be. Currently this is set to the logical address of the endpoint, which in the case of the SQL Server transport is the endpoint name, the schema name and the database name. I guess this could be the handler name though, as that is ultimately the destination of the message?
I'm mirroring what other providers do here - peeking in at what like Java, Go, Node etc. are doing. I'd rather be consistent since this package is meant to follow the OTel spec. I'm not a fan of the span naming either but I erred on the side of being consistent.
I talked with the Particular folks and some other message/actor libraries, the specs are written more at the transport, not application protocol level. I could see two levels of spans, one having what you're describing and this one at the lower transport level.
It looks like NServiceBus 8 will have OpenTelemetry built-in, so I had a look at their implementation. By the looks of it, they are starting an additional activity when handling the message.