Thanks for updating the FLIP and clarifying. > That might have been a good idea, however this is consistent with the ? already pre-existing traces/`SpanBuilder`. > I'm not sure what you would propose in this context? Make those two places > inconsistent?
Good point, I think consistency is more important. Regards, Roman On Tue, Dec 3, 2024 at 12:07 PM Piotr Nowojski <piotr.nowoj...@gmail.com> wrote: > Hi Roman! > > > 1. Should it list the events that would be emitted in the first version? > > If not as part of the proposed change, then maybe as examples > > I've added a brief list of events that will be added in the first version. > > > 2. Interface Event - Scope > > It's scope is explicitly tied to a Class which limits flexibility. I can > > imagine alternative usages of scope, for example scope="job-lifecycle" or > > scope="task-manager". > > It also adds a barrier to rename or move classes. > > So I'd remove the mention of Class. > > That might have been a good idea, however this is consistent with the > already pre-existing traces/`SpanBuilder`. > I'm not sure what you would propose in this context? Make those two places > inconsistent? > > > 3. Interface Event - Body > > Can you explain the purpose of this property? > > In my opinion, most information about an event can be stored in its > attributes, > > except for when it's used by Flink itself; or is very common. > > This introduced to fill in Otel's Body field > `io.opentelemetry.api.logs.LogRecordBuilder#setBody` > > Best, > Piotrek > > czw., 14 lis 2024 o 11:03 Roman Khachatryan <ro...@apache.org> napisał(a): > > > Hi Piotr, thanks for the proposal! > > > > I think this would be a very valuable addition to Flink as it would > > simplify operations a lot > > (disclaimer: we already use it in our internal Flink version) > > > > I have a couple of remarks regarding the FLIP: > > > > 1. Should it list the events that would be emitted in the first version? > > If not as part of the proposed change, then maybe as examples > > > > 2. Interface Event - Scope > > It's scope is explicitly tied to a Class which limits flexibility. I can > > imagine alternative usages of scope, for example scope="job-lifecycle" or > > scope="task-manager". > > It also adds a barrier to rename or move classes. > > So I'd remove the mention of Class. > > > > 3. Interface Event - Body > > Can you explain the purpose of this property? > > In my opinion, most information about an event can be stored in its > > attributes, > > except for when it's used by Flink itself; or is very common. > > > > Regards, > > Roman > > > > > > On Thu, Nov 7, 2024 at 2:35 PM Piotr Nowojski <piotr.nowoj...@gmail.com> > > wrote: > > > > > Hi all! > > > > > > I would like to open up for the discussion a new FLIP [1] > > > > > > Motivation > > > > > > Currently, Flink observability has support for Metrics and Traces. We > > > suggest enhancing the observability capabilities by adding support for > > > Events. This can be used to track the most important events that happen > > in > > > Flink, e.g. completed checkpoints or changes to the job’s state. > Storing > > > such information, e.g. in an event log or a database, would allow us to > > > create a history of those events which can be used for audit purposes > or > > to > > > derive important information like, for example, job uptime/downtime or > > > violations of required checkpoint completion times. > > > > > > For more information please look into the FLIP [1]. > > > > > > I'm looking forward to your thoughts on this. > > > > > > Best, > > > Piotrek > > > > > > [1] https://cwiki.apache.org/confluence/x/3IyMEw > > > > > >
