Il giorno mer 29 nov 2023 alle ore 12:01 Asaf Mesika <asaf.mes...@gmail.com> ha scritto: > > On Wed, Nov 29, 2023 at 12:18 AM Enrico Olivelli <eolive...@gmail.com> > wrote: > > > Asaf, > > > > > > > > Il Mar 28 Nov 2023, 19:14 Asaf Mesika <asaf.mes...@gmail.com> ha scritto: > > > > > Hi, > > > > > > This is the first sub-PIP for parent PIP-264 > > > <https://github.com/apache/pulsar/pull/21080> ("Enhanced OTel-based > > metric > > > system"). > > > > > > This PIPs goal is to introduce OpenTelemetry into Apache Pulsar. When > > this > > > PIP is implemented, we will be able to start converting (not replacing) > > > existing metrics into OpenTelemetry. > > > > > > > I support the proposal. > > In the document it is explained that OTel is experimental, not GA and but > > default it is disabled. > > > Just to clarify: The sub-title in the PIP referring to that is "Why OTel > in Pulsar will be marked experimental and not GA". > Using OTel in Pulsar is experimental, not OTel itself, which is of course > stable and GA already. > > > > > > My understanding is that in case it is disabled the impact on the runtime > > is negligible, is this correct? > > > > I added the following paragraph to the PIP to better explain. > > With OTel disabled, the user remains with the existing metrics system. > OTel in a disabled state operates in a > no-op mode. This means, instruments do get built, but the instrument > builders return the same instance of a > no-op instrument, which does nothing on record-values method (e.g. > `add(number)`, `record(number)`). The no-op > `MeterProvider` has no registered `MetricReader` hence when no metric > collection will be made. The memory impact > is almost 0 and the same goes for CPU impact.
Perfect. +1 Thanks Enrico > > > > > > > > Enrico > > > > > > > > Link: https://github.com/apache/pulsar/pull/21635 > > > > > > Thanks, > > > > > > Asaf > > > > >
