@Matteo Merli
I've been playing around with where to put the atInfo() and event ID
and had the following thoughts.
Putting atInfo(Enum event) at the point of event creation is a
suggestion so that if that event is not enabled at that level, then a
dummy attribute accumulator will be returned and t
Inline
> // trimmed discussion about using annotations for documentation
>
> I was checking and it's not possible to have annotations on the enum
> values. We should still have an annotation for the Events enum types
> so that we can both:
> 1. Add context for that event group (eg: broker events,
Responses inline as well
On Fri, Aug 6, 2021 at 9:16 AM Ivan Kelly wrote:
> >For example, in the proposed scenario it's used "Events.LOOKUP".
> > There is a lot of context that would be missing there. Eg: is this an
> > HTTP or Protobuf lookup, did we log when the operation started or when
>
Thanks for the detailed feedback Matteo,
Responses inline.
> 1. I like the idea of using enum to identify an event, but I fear
> that the enum name itself will not be, in many cases, as expressive of
> the context as a complete phrase.
I'm not convinced by this. From just eyeballing one of our
Hi Ivan,
I am very in favor of this proposal, as we had occasion to discuss
this in the past, the structured logging would be one way to have a
better standardized way to attach context to the events, in a way that
is human and machine readable.
For me, it became evident after the experience usin
Il Gio 5 Ago 2021, 20:11 Ivan Kelly ha scritto:
> Seems like all the feedback is positive. What's the process for moving
> the PIP to approved? I don't see anything on the wiki. Nor in the
> bylaws (where are they? they're not linked on site menu).
>
This is currently an open point :(
Probably
Seems like all the feedback is positive. What's the process for moving
the PIP to approved? I don't see anything on the wiki. Nor in the
bylaws (where are they? they're not linked on site menu).
-Ivan
On Wed, Aug 4, 2021 at 5:11 PM Ivan Kelly wrote:
>
> > I wonder how we will be able to enforce
> I wonder how we will be able to enforce such way of logging once we are
> done with the switch.
No all logging needs to be done this way. This will coexist with
traditional slf4j logging.
However, hopefully this will prove useful enough that a string
interpolated log will
start to stick out like
The proposal looks very interesting and useful. Thanks for bringing this up.
I wonder how we will be able to enforce such way of logging once we are
done with the switch.
There will be some education for contributors and committers about how to
use the Logger.
Enrico
Il Mer 4 Ago 2021, 05:52 Sh
+1
This is be really helpful in debugging.
Regards,
Shiv
On Wed, 4 Aug 2021 at 6:32 AM, Jia Zhai wrote:
> +1. this will help a lot for debugging
>
> Best Regards.
>
>
> Jia Zhai
>
> Beijing, China
>
> Mobile: +86 15810491983
>
>
>
>
> On Wed, Aug 4, 2021 at 1:41 AM Jerry Peng
> wrote:
>
> > I
+1. this will help a lot for debugging
Best Regards.
Jia Zhai
Beijing, China
Mobile: +86 15810491983
On Wed, Aug 4, 2021 at 1:41 AM Jerry Peng
wrote:
> Ivan,
>
> Awesome proposal! Structured logging like this will definitely help Pulsar
> be easier to debug.
>
> Best,
>
> Jerry
>
> On T
Ivan,
Awesome proposal! Structured logging like this will definitely help Pulsar
be easier to debug.
Best,
Jerry
On Tue, Aug 3, 2021 at 4:33 AM Ivan Kelly wrote:
> Hi folks,
>
> I've just created a PIP in the wiki to add structured documented
> logging for Pulsar.
> More often than not, when
Hi folks,
I've just created a PIP in the wiki to add structured documented
logging for Pulsar.
More often than not, when debugging an incident in Pulsar we find that
information we need is not logged, at which point we have to resort to
digging into zookeeper directly or rely on gut feelings of pe
13 matches
Mail list logo
