zlepper
commented
5 months ago I'm assuming you are using Rebus to still publish the "continuations" here.
Basically you need to "resume" the trace before you send the message over with Rebus (Or any other thing for example http). Basically something like this https://github.com/rebus-org/Rebus.OpenTelemetry/blob/master/Rebus.Diagnostics/Diagnostics/Incoming/IncomingDiagnosticsStep.cs#L63-L72 .
Before you save your messages in your database you need to grab the trace/baggage header so you can use them when resuming the trace: https://github.com/rebus-org/Rebus.OpenTelemetry/blob/master/Rebus.Diagnostics/Diagnostics/Outgoing/OutgoingDiagnosticsStep.cs#L85-L100
You generally shouldn't be dealing with headers directly here unless you are working directly with the underlying transport and skipping Rebus entirely.
Side note: Consider having a look at Rebus sagas, they exists for the usecase you describe https://github.com/rebus-org/Rebus/wiki/Coordinating-stuff-that-happens-over-time :)
AYss
Hi.
We have a following situation. A service is waiting for several types of messages and storing them in a DB. First it was checking after processing each message if we have eventhing we need for further processing and if so, publishing subsequent messages. Since the service may process like 100 msg/s, that put heavy load on the DB, so we had to tune it up. Now there is a background service that periodically checks if all required messages arrived and publishes messages. However we lost trace/activity info so the subsequent logs are not bound by trace.id in Kibana.
I have tried keeping original messages rbs-ot-* headers and putting them into messages published by the background service, but it does not seem to work. Any ideas how to keep traces in such scenario?
We are using Rebus.OpenTelemetry package and it might related more to that, than Rebus itself, so move the issue there if you think it better suits there.