Creating new metric and deprecating existing one seems better from compatibility point of view. -------- Original message --------From: James Cheng <wushuja...@gmail.com> Date: 3/21/18 1:39 AM (GMT-08:00) To: dev@kafka.apache.org Subject: Re: [DISCUSS] KIP-272: Add API version tag to broker's RequestsPerSec metric Manikumar brings up a good point. This is a breaking change to the existing metric. Do we want to break compatibility, or do we want to add a new metric and (optionally) deprecate the existing metric?
For reference, in KIP-153 [1], we changed an existing metric without doing proper deprecation. However, in KIP-225, we noticed that that we maybe shouldn't have done that. For KIP-225 [2], we instead decided to create a new metric, and deprecate (but not remove) the old one. -James [1] https://cwiki.apache.org/confluence/display/KAFKA/KIP-153%3A+Include+only+client+traffic+in+BytesOutPerSec+metric [2] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74686649 > On Mar 21, 2018, at 12:14 AM, Manikumar <manikumar.re...@gmail.com> wrote: > > Can we retain total RequestsPerSec metric and add new version tag metric? > When monitoring with simple jconsole/jmx based tools, It is useful to have > total metric > to monitor request rate. > > > Thanks, > > On Wed, Mar 21, 2018 at 11:01 AM, Gwen Shapira <g...@confluent.io> wrote: > >> I love this. Not much to add - it is an elegant solution, clean >> implementation and it addresses a real need, especially during upgrades. >> >> On Tue, Mar 20, 2018 at 2:49 PM, Ted Yu <yuzhih...@gmail.com> wrote: >> >>> Thanks for the response. >>> >>> Assuming number of client versions is limited in a cluster, memory >>> consumption is not a concern. >>> >>> Cheers >>> >>> On Tue, Mar 20, 2018 at 10:47 AM, Allen Wang <allenxw...@gmail.com> >> wrote: >>> >>>> Hi Ted, >>>> >>>> The additional hash map is very small, possibly a few KB. Each request >>> type >>>> ("produce", "fetch", etc.) will have such a map which have a few >> entries >>>> depending on the client API versions the broker will encounter. So if >>>> broker encounters two client versions for "produce", there will be two >>>> entries in the map for "produce" requests mapping from version to >> meter. >>> Of >>>> course, hash map always have additional memory overhead. >>>> >>>> Thanks, >>>> Allen >>>> >>>> >>>> On Mon, Mar 19, 2018 at 3:49 PM, Ted Yu <yuzhih...@gmail.com> wrote: >>>> >>>>> bq. *additional hash lookup is needed when updating the metric to >>> locate >>>>> the metric * >>>>> >>>>> *Do you have estimate how much memory is needed for maintaining the >>> hash >>>>> map ?* >>>>> >>>>> *Thanks* >>>>> >>>>> On Mon, Mar 19, 2018 at 3:19 PM, Allen Wang <allenxw...@gmail.com> >>>> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> I have created KIP-272: Add API version tag to broker's >>> RequestsPerSec >>>>>> metric. >>>>>> >>>>>> Here is the link to the KIP: >>>>>> >>>>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP- >>>>>> 272%3A+Add+API+version+tag+to+broker%27s+RequestsPerSec+metric >>>>>> >>>>>> Looking forward to the discussion. >>>>>> >>>>>> Thanks, >>>>>> Allen >>>>>> >>>>> >>>> >>> >> >> >> >> -- >> *Gwen Shapira* >> Product Manager | Confluent >> 650.450.2760 | @gwenshap >> Follow us: Twitter <https://twitter.com/ConfluentInc> | blog >> <http://www.confluent.io/blog> >>
