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 Nowojski <pnowoj...@apache.org> wrote: > 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 different machines after a > job > failover. > > This has been discussed in the past in the FLIP-384 thread [1]. In > particular > please check this response from me [2]. > > [1] https://lists.apache.org/thread/7lql5f5q1np68fw1wc9trq3d9l2ox8f4 > [2] https://lists.apache.org/thread/cznt6rbncx1ydqcn13m52859qrggq1xg > > > 2. If at some point we come up with a way to address (1), then having a > > reference from child to parent would be more flexible? And probably not > in > > the form of object reference, but just as a (String) identifier? > > I'm not sure. Maybe it will be a string identifier, maybe something else > that is less prone to errors? Exposing a "String" identifier, pushes the > problem to users. Also AFAIR it's not clear how to convert a custom > string into Otel's `Context` class . But I might be wrong with this last > one. > > Best, > Piotrek > > > czw., 14 lis 2024 o 13:21 Roman Khachatryan <ro...@apache.org> napisał(a): > > > 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 > > > > 2. If at some point we come up with a way to address (1), then having a > > reference from child to parent would be more flexible? And probably not > in > > the form of object reference, but just as a (String) identifier? > > > > > > Regards, > > Roman > > > > > > On Thu, Nov 7, 2024 at 2:41 PM Piotr Nowojski <pnowoj...@apache.org> > > wrote: > > > > > 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 accurately > > report > > > checkpointing or recovery. Single top level span for checkpointing or > > > recovery is currently aggregating some metrics, like maximum and sum of > > how > > > long did the state download/upload take. However this hides some > details, > > > like how long each task and/or subtask was downloading the state. > > > > > > In this FLIP we want to introduce a general mechanism for reporting > > > children spans. > > > > > > For more information please look into the FLIP-483 [1]. > > > > > > I'm looking forward to your thoughts on this. > > > > > > Best, > > > Piotrek > > > > > > [1] https://cwiki.apache.org/confluence/x/4IyMEw > > > [2] https://cwiki.apache.org/confluence/x/TguZE > > > > > >
