Thanks José! For 1/2 above, just checking if we would record the
corresponding sensors only during broker bootstrap time, or whenever there
are new metadata records being committed by the controller quorum (since
there are always a short period of time, between when the records are
committed, to when the records get fetched by that broker)?

On Wed, May 18, 2022 at 7:53 PM Luke Chen <show...@gmail.com> wrote:

> Hi José,
>
> Thanks for the KIP!
> +1 (binding) from me.
>
> Luke
>
> On Thu, May 19, 2022 at 2:05 AM José Armando García Sancio
> <jsan...@confluent.io.invalid> wrote:
>
> > Hi Guozhang, thanks for the feedback.
> >
> >
> > Guozhang wrote:
> > > Could you elaborate a bit on what does "load-processing-time-us"
> > measure? I
> > > looked through the discussion thread and the KIP / JIRA but cannot find
> > its
> > > definitions.
> >
> > Yes. I updated the KIP. This is what I documented:
> > 1.
> >
> kafka.server:type=broker-metadata-metrics,name=load-processing-time-us-avg
> > Reports the average amount of time it took for the broker to process
> > all pending records when there are pending records in the cluster
> > metadata partition. The time unit for this metric is microseconds.
> > 2.
> >
> kafka.server:type=broker-metadata-metrics,name=load-processing-time-us-max
> > Reports the maximum amount of time it took for the broker to process
> > all pending records when there are pending records in the cluster
> > metadata partition. The time unit for this metric is microseconds.
> > 3.
> > kafka.server:type=broker-metadata-metrics,name=record-batch-size-byte-avg
> > Reports the average byte size of the record batches in the cluster
> > metadata partition.
> > 4.
> > kafka.server:type=broker-metadata-metrics,name=record-batch-size-byte-max
> > Reports the maximum byte size of the record batches in the cluster
> > metadata partition.
> >
> > -José
> >
>


-- 
-- Guozhang

Reply via email to