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 > > >
