[Design] Tracing story for LRO #10969
Labels
Azure.Core
azure-core
Client
This issue points to a problem in the data-plane of the library.
design-discussion
An area of design currently under discussion and open to team and community feedback.
OpenTelemetry
OpenTelemetry instrumentation
This work item is to explore various options for LRO tracing.
The LRO abstraction quick intro:
The client-side LRO abstraction PollerFlux is one type that composes almost 4 service calls:
Problem:
We need to decide on how we want to report telemetry for these service calls from a single PollerFlux.
--> One option is to put all these logically associated API calls under one group.
Examples:
The following examples show a couple of usage of PollerFlux and how telemetry looks like with grouping option.
Example1:
Start LRO and do the polls
Example2:
Start LRO, do the polls and fetch result.
Example3:
Start LRO, do the polls then cancel.
Example4:
Use the first subscription to Start LRO, do 2 polls
do subscription on the same poller flux instance for polling
Note one instance of PollerFlux makes an only single call to start LRO, so other subscription simply result in polling.
One way to show the telemetry is like below by grouping two subscription under the same parent span, if we decide this path then we could user parent PollerContext.
To discuss:
Is the above-outlined grouping option make sense for LRO, what are the other alternatives.
\cc @alzimmermsft @JonathanGiles @srnagar @samvaity
The text was updated successfully, but these errors were encountered: