Observing Multiple services inside one application

[Bourhjoul]

This is not an issue but more of discussion if that's okay.

We have the following scenario, where we have one service containing multiple workers (a worker is just a rabbitmq consumer of a certain queue), the issue is we want to observe and trace the worker instead of tracing the service, so we can have a better understanding of our system and in our case the service itself doesn't do anything except booting up the workers.

My question is:

• is there is a way to acheive this with otel?

if I'm asking in the wrong, apologies and would apperciate a little help and guidance.

thank you

[LarryHu0217]

Yes, but I would model this differently depending on whether each worker is independently deployed.

If all RabbitMQ consumers run in the same Node.js process, keep one stable service.name for that process. An OpenTelemetry Resource is immutable and attached to the TracerProvider, so every span from that provider has the same Resource; changing service.name per message handler is not the supported model.

Instead, create a CONSUMER/process span around each handler and distinguish workers with low-cardinality attributes such as messaging.destination.name, messaging.operation.name, messaging.operation.type, and, if necessary, a custom worker.type. Extract the producer context from each message so the processing trace connects end-to-end. For batch consumption, link the processing span to each message context because a span can have only one parent.

If each worker must appear as a separate node in the backend’s service map, run it as a separate process/container and give that SDK instance its own service.name, such as orders-worker or billing-worker. Use service.instance.id for replicas of the same worker service.

So the practical rule is: one deployment means one service with worker-level consumer spans; independently operated workers should use separate processes and service names. Multiple global Node SDKs in one process are usually brittle because auto-instrumentation uses the global provider and context manager.

References: Resource SDK, messaging span conventions, and Tracing API. The current messaging conventions remain under development, so older instrumentation may emit earlier attribute names.