Spring/spring-integration
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

GH-9743: Add observation to the SourcePollingChannelAdapter

Browse Source 
Fixes: https://github.com/spring-projects/spring-integration/issues/9743

Spring Integration provides observation for the `MessageChannel`, `MessageHandler`
and `MessageProducerSupport`.
The `SourcePollingChannelAdapter` is missing, and it is that only special endpoint which
deals with `MessageSource` implementations via scheduled tasks in the poller.
Essentially, this endpoint is a start of the flow, but it still is a consumer of data from the source system.

* Add an `Observation` logic to the `SourcePollingChannelAdapter`.
* Divide it into two phases: start (and open scope) when message is received; stop (and close scope) when the whole polling task for a message is done.
We need this separation because of transaction scope for the polling task.
At the same time we don't want to emit an observation for a void polling task.
* Change `MessageReceiverContext` to accept a `handlerType`.
The `MessageHandler` contributes a `handler`.
The new support in the `SourcePollingChannelAdapter` - `message-source`.
And change `MessageProducerSupport` to contribute a `message-producer`
* Verify the single trace is supported for the whole flow (including transaction synchronization) starting from a `SourcePollingChannelAdapter` in a new `SourcePollingChannelAdapterObservationTests`
* Document this new feature
This commit is contained in:
Artem Bilan
2025-01-09 13:31:02 -05:00
parent 177bda58c5
commit 89c5dfa4d6
8 changed files with 295 additions and 39 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
src/reference/antora/modules/ROOT/pages/metrics.adoc
View File

@@ -164,14 +164,15 @@ The meters are not gathered in this case independently, but delegated to an appr
The following Spring Integration components are instrumented with observation logic each with a respective convention:
* `MessageProducerSupport`, being the inbound endpoint of the flow, is considered as a `CONSUMER` span type and uses the `IntegrationObservation.HANDLER` API;
* MessagingGatewaySupport` is an inbound request-reply endpoint, and is considered as a `SERVER` span type.
* `MessageProducerSupport`, being an inbound endpoint of the flow, is considered as a `CONSUMER` span type and uses the `IntegrationObservation.HANDLER` API;
* `MessagingGatewaySupport` is an inbound request-reply endpoint, and is considered as a `SERVER` span type.
It uses the `IntegrationObservation.GATEWAY` API;
* An `AbstractMessageChannel.send()` operation is the only Spring Integration API where it produces messages.
So, it is treated as a `PRODUCER` span type and uses the `IntegrationObservation.PRODCUER` API.
This makes more sense when a channel is a distributed implementation (e.g. `PublishSubscribeKafkaChannel` or `ZeroMqChannel`) and trace information has to be added to the message.
So, the `IntegrationObservation.PRODUCER` observation is based on a `MessageSenderContext` where Spring Integration supplies a `MutableMessage` to allow a subsequent tracing `Propagator` to add headers, so they are available to the consumer;
* An `AbstractMessageHandler` is a `CONSUMER` span type and uses the `IntegrationObservation.HANDLER` API.
* An `AbstractMessageHandler` is a `CONSUMER` span type and uses the `IntegrationObservation.HANDLER` API;
* The `SourcePollingChannelAdapter` (starting with version 6.5), being an inbound endpoint of the flow, is considered as a `CONSUMER` span type and uses the `IntegrationObservation.HANDLER` API.
An observation production on the `IntegrationManagement` components can be customized via `ObservationConvention` configuration.
For example an `AbstractMessageHandler` expects a `MessageReceiverObservationConvention` via its `setObservationConvention()` API.

9
src/reference/antora/modules/ROOT/pages/whats-new.adoc
View File

@@ -31,4 +31,11 @@ See xref:aggregator.adoc[Aggregator] for more information.
== The `LockRegistry` in the `MessageStore`
The `AbstractMessageGroupStore` now can be configured with a `LockRegistry` to perform series of persistent operation atomically.
See xref:message-store.adoc#use-lock-registry[Use LockRegistry] for more information.
See xref:message-store.adoc#use-lock-registry[Use LockRegistry] for more information.
[[x6.4-observation-changes]]
== Micrometer Observation Changes
The `SourcePollingChannelAdapter` endpoint now starts a `CONSUMER` kind observation for the received message.
The `MessageReceiverContext` now distinguishes between `handler`, `message-source` and `message-producer` values for the `spring.integration.type` low cardinality tag.
See xref:metrics.adoc#micrometer-observation[Micrometer Observation] for more information.