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. > > Enrico > > > > > Link: https://github.com/apache/pulsar/pull/21635 > > > > Thanks, > > > > Asaf > > >
