Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type of a message is lost for ActivityKind: Server and Internal #19

Open
prybski opened this issue Mar 12, 2024 · 9 comments
Open

Type of a message is lost for ActivityKind: Server and Internal #19

prybski opened this issue Mar 12, 2024 · 9 comments

Comments

@prybski
Copy link

prybski commented Mar 12, 2024

During incorporation of this project as a NuGet package we have encountered an issue, which results in missing type of a message for ActivityKind: Server and Internal (for Client it works fine and is visible as it should be). I saw in the source code that you are extracting type of a message with use of .GetMessageType() method, but it seems to not always return it:

/// <summary>
/// Gets the message type from the message
/// </summary>
public static string GetMessageType(this TransportMessage message)
{
    if (message == null) throw new ArgumentNullException(nameof(message));
    return message.Headers.GetValueOrNull(Headers.Type)
           ?? "<unknown>";
}

Maybe there is a better way to extract type of a message(?), because right now we have ended up with our custom implementation, which uses Rebus.Events NuGet package and with is the type of a message is always present.

I am including screenshots from our Datadog instance to illustrate what the problem is in a better way:
image
image
image

@zlepper
Copy link
Collaborator

zlepper commented Apr 19, 2024

I'm sorry, i'm not sure i follow the problem here? I'm not familiar with Datadogs UI, so maybe i'm missing something? Can you describe exactly what you are expecting vs what you are getting? It would be especially nice if you can include the actual headers you have on the messages that are not working as expected.

@prybski
Copy link
Author

prybski commented Apr 24, 2024

The issue is basically what I have described @zlepper 😄 For some reason when using NuGet package from this repository Activity with ActivityKind set to Client is working properly. Rest of them miss the message type name. I have included method which should be responsible for that, and that is GetMessageType. Maybe there is a better way of fetching type of message than from headers?

This issue forced us to write our custom Rebus instrumentation, because having message type name on all Activities related to Rebus is crucial to us.

@prybski
Copy link
Author

prybski commented Apr 24, 2024

I expect that Activities with any ActivityKind related to Rebus will contain message type name 😉 Right now it only works like that for Activities with ActivityKind set to Client.

@zlepper
Copy link
Collaborator

zlepper commented Apr 24, 2024

We are using Grafana where i work and it works fine without any modifications there:
image

What did you add the the Activity in your custom instrumentation?

@prybski
Copy link
Author

prybski commented Apr 24, 2024

We do not use DiagnosticSource like you do in this repository. Instead we make use of Rebus.Events 😉 And then we have possibility to create Activities with desired ActivityKind and message type name (it does not get lost at some point when we implement it like that).

@prybski
Copy link
Author

prybski commented Apr 24, 2024

Maybe something was off with Rebus configuration on our side. Can you share with me how does it look in you project? 🤔

@zlepper
Copy link
Collaborator

zlepper commented Apr 24, 2024

The DiagnosticSource is the key to making sure everything actually works. If the DiagnosticSource is not enabled, the Rebus does not populate the activity: https://github.com/rebus-org/Rebus.OpenTelemetry/blob/master/Rebus.Diagnostics/Diagnostics/Incoming/IncomingDiagnosticsStep.cs#L47 Though if you are actually getting the "receive" types and such, then this part probably isn't the problem.

Can you maybe setup a unit test in this repository that reproduces the issue? You can see an example here: https://github.com/rebus-org/Rebus.OpenTelemetry/blob/master/Rebus.Diagnostics.Tests/IntegrationTests.cs#L23

@prybski
Copy link
Author

prybski commented Apr 25, 2024

We have enabled DiagnosticSource, so for sure this is not the problem unfortunately 😕 I will try to setup the unit test soon 😉

@prybski
Copy link
Author

prybski commented Apr 29, 2024

Can you show me @zlepper how is Rebus configured in your project that works properly with this NuGet package? 🤔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants