Tracing using Open Telemetry

[dgafka]

Description
In order to provide more visibility into the process of message flow, Ecotone will integrate with open-telemetry.
Even so that OpenTelemetry is still in development phase it's replacing OpenTracing. So at this moment of time, it's more valueable to integrate with the first one.
OpenTelemetry comes with big community support for rather not so widely known solution in PHP world.

How to approach

ecotone/ecotone

In Ecotone each Message Handler (Command/Event/Query) are at the end built as Consumers.
This goes even further as each Endpoint (which is lower abstraction than Command/Event Handlers, for example Service Activator) is actually Consumer.
Each Consumer is connected to single channel.
Depending on the channel type, event-driven or polling consumer will be build.

• Event driven consumers are ones that are executed instantly, for example executing synchronous Command Handler.
• Polling consumers are ones that runs as separate process. They poll messages from given channel and executes Endpoint. For example making Command Handler Asynchronous, creates Polling Consumer.

What does it mean is everything in Ecotone can easily switch from synchronous to asynchronous and vice versa.
The whole system is losely coupled to each other and is open for extensions and intercepting.

This opens great opportunity as it allows for tracing/logging whole message flow from the beginning till the end.
Everything will be visible and each part of Ecotone's components and Client's code will be able to be measured.

So the idea is to expose tracing capabilities in core of the framework.
So whenever we build consumers, we may decorate them with Tracing Handlers.

• For Event Driven it would need to decorate here.
• Polling Consumers are built only when demanded, so that's happening here.

So from End User perspective it could work by passing list of as module extensions channel names, which should be executed for tracing.

#[ServiceContext]
public function tracing()
{
    return Tracing::create("my_tracing_channel");
}

#[ServiceActivator("my_tracing_channel")]
public function tracing(Message $message)
{
    $this->tracer->spanBuilder($message->getHeaders()->get("endpointId"))->startSpan();
}

This would create totally decoupled solution, where configuration of the tracing lives in external packages, however execution in the core.

The trick is to enrich incoming message with inputChannelName, endpointId before sending it to the tracers, as those are not available in the Message.

Tracer channels can be executed using Message Gateway directly from Tracing Handler which would decorate consumer.