kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allen Wang <allenxw...@gmail.com>
Subject Re: [DISCUSS] KIP-272: Add API version tag to broker's RequestsPerSec metric
Date Mon, 26 Mar 2018 16:04:18 GMT

I would like to bring this to vote in the next day or two. Let me know if
you have further comments.


On Thu, Mar 22, 2018 at 11:37 AM, Xavier Léauté <xavier@confluent.io> wrote:

> >
> > This kind of change will be problematic to us as the total RequestsPerSec
> > will be double counted in our metric system as we do automatic
> aggregation.
> > It has been a headache for us as we always have to do some special
> handling
> > when querying such metrics.
> >
> I agree with Allen, most of the metrics are already setup to be aggregated
> across the various tags dimensions. We do the same on with our metrics, and
> any respectable metrics system would allow you to do the same.
> It sounds like backwards compatibility in this case is more subjective,
> since it depends largely on how you consume / aggregate those metrics, but
> in my opinion, aggregation should be the way to go.
> There is precedent with topic based metrics such as BytesInPerSec, which
> are currently duplicated, once at the broker level (no topic tag), and once
> at the topic level (tagged with the topic name) and it's easy to miss that
> fact. Without looking the source code it's very hard to notice those
> subtleties.
> As a result it can be very error-prone to filter out the right metrics for
> aggregation, so I would argue we should not repeat the same mistake unless
> we had some good reasons to do so in the first place.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message