Yes, and again, we are not giving up. If/once we will have a well motivated
use case for the distributed tracing,
we can then try to figure out how to implement it.
Anyway, I will open the voting thread later today! Thanks for the comments.
Best,
Piotrek
śr., 4 gru 2024 o 23:36 Roman Khachatryan
Thanks for the pointers, I also took a look at the Otel API and also
couldn't find the way to "compose" a context instead of propagating it
(which IMO wouldn't be desirable in Flink).
So your proposal makes sense to me - as it keeps it simple.
Regards,
Roman
On Tue, Dec 3, 2024 at 12:30 PM Piotr
Hi Roman!
> 1. Why do we give up on the idea of reporting child spans independently
> from the parent? I couldn't find much details in the Rejected Alternatives
> section
We are not giving up on it. But the issue is how to connect related spans if
they are reported independently, potentially on d
Hi Piotr, thanks for the proposal,
I see the need for reporting child spans, however I have a couple of
questions about the proposed design:
1. Why do we give up on the idea of reporting child spans independently
from the parent? I couldn't find much details in the Rejected Alternatives
section
Hi all!
I would like to open up for discussion a new FLIP-483 [1].
Motivation
FLIP-384 [2] added trace/span reporting capability to Flink, which has been
used in a couple of places, like reporting checkpointing and recovery
processes.
With flat/childless structure of spans it is difficult to acc
