hi Apoorv, Let's use the following example to explain my point.
in 4.0 *Topic Name: topic.a.b* - *Deprecated Metric Added:* A deprecated metric with the tag topic_a_b has been added. - *New Metric Added:* A new metric with the tag topic.a.b has been introduced. Users should monitor this new metric instead of the deprecated one. *Topic Name: topic_a_b* - *Metric Added:* A metric with the tag topic_a_b has been added. This metric is not deprecated and reflects the actual topic name. - *No Additional Metric:* No extra metric have been added, as the existing metric functions correctly. in 5.0 we remove the replacement policy totally. thanks, chia-ping Jun Rao <j...@confluent.io.invalid> 於 2024年12月10日 週二 上午8:11寫道： > Hi, Apoorv, > > I thought Chia's suggestion is to emit the metric under both the topic name > with and without dot replacement. > > Thanks, > > Jun > > On Wed, Nov 27, 2024 at 3:06 PM Apoorv Mittal <apoorvmitta...@gmail.com> > wrote: > > > Thanks Jun and Chia for review and feedback. > > > > Initially I thought this might be a breaking change for someone who has > > written a transformation over topic name and expects them to be "_" > > replaced, if dot exists. But the fix is actually a correction of the > topic > > name itself hence was wondering if we should just correct it without > > deprecating existing. Unlike KIP-773 where we required 'ns' per other > > metrics naming convention for data captured, here we are correcting a tag > > value. > > > > In case we want to deprecate then there could be 2 options I was thinking > > of: > > > > 1. As the metric names seem to be appropriate hence add another > > tag/label as "fetch-topic" which should contain the topic name without > any > > replacement. This approach will not change the existing "topic" tag data > > and in the subsequent releases we can drop this "topic" tag as well. > > 2. Deprecate old metrics and introduce new ones - I find the existing > > consumer metrics > > <https://kafka.apache.org/20/generated/consumer_metrics.html> named > > appropriately, hence finding it hard to come up with better names for new > > metrics, any suggestions if we go with this approach? > > > > Regards, > > Apoorv Mittal > > > > > > On Wed, Nov 20, 2024 at 5:57 PM Jun Rao <j...@confluent.io.invalid> > wrote: > > > > > Hi, Chia-Ping, > > > > > > We could deprecate those metrics too. Then, we probably want to do a > > formal > > > KIP on this. > > > > > > Thanks, > > > > > > Jun > > > > > > On Tue, Nov 19, 2024 at 3:11 AM Chia-Ping Tsai <chia7...@gmail.com> > > wrote: > > > > > > > hi Apoorv, > > > > > > > > Should we follow the deprecation cycle in this KIP? I mean, we should > > > keep > > > > both metrics for now and add a description to inform users that the > > > metrics > > > > are deprecated. > > > > > > > > hi Jun > > > > > > > > The incorrect topic metrics have existed for a while, so I believe it > > > would > > > > be better to follow a deprecation cycle, similar to KIP-773. ( > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-773%3A+Differentiate+consistently+metric+latency+measured+in+millis+and+nanos > > > > ) > > > > > > > > Best, > > > > Chia-Ping > > > > > > > > Jun Rao <j...@confluent.io.invalid> 於 2024年11月19日 週二 上午3:48寫道： > > > > > > > > > Hi, Apoorv, > > > > > > > > > > We did the dot replacement in Yammer metric scope to help with the > > > naming > > > > > schema used in Graphite and the java consumer code just copied it. > > > Since > > > > > this is an issue very specific to Graphite, it's better not to > change > > > the > > > > > name directly in Kafka metric. If needed, a Graphite specific > > reporter > > > > > could be written to address its specific issue. I agree that this > is > > > more > > > > > like a bug than a new feature. We could probably just fix the issue > > in > > > > the > > > > > java consumer without a KIP. > > > > > > > > > > Thanks, > > > > > > > > > > Jun > > > > > > > > > > On Fri, Nov 15, 2024 at 2:37 PM Apoorv Mittal < > > > apoorvmitta...@gmail.com> > > > > > wrote: > > > > > > > > > > > Moreover on a second thought, as this should be a correction in > > > emitted > > > > > > topic names then we should not require a KIP per say but just fix > > it > > > as > > > > > > part of jira itself. Please let me know your thoughts. > > > > > > > > > > > > Regards, > > > > > > Apoorv Mittal > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Nov 15, 2024 at 10:16 PM Apoorv Mittal < > > > > apoorvmitta...@gmail.com > > > > > > > > > > > > wrote: > > > > > > > > > > > > > Hi All, > > > > > > > I have added the Context section in the KIP as per the > discussion > > > on > > > > > the > > > > > > > jira <https://issues.apache.org/jira/browse/KAFKA-12469>. > Please > > > let > > > > > me > > > > > > > know if there is any feedback or I shall directly start the > > voting > > > > > > thread. > > > > > > > > > > > > > > Regards, > > > > > > > Apoorv Mittal > > > > > > > > > > > > > > > > > > > > > On Tue, Nov 12, 2024 at 12:49 PM Apoorv Mittal < > > > > > apoorvmitta...@gmail.com > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > >> Hi All, > > > > > > >> I would like to start a discussion on KIP-1109: > > > > > > >> > > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1109%3A+Unifying+Kafka+Consumer+Topic+Metrics > > > > > > >> > > > > > > >> This KIP streamlines topic and topic-partition metrics for > Kafka > > > > > > >> Consumer, emitting the user defined topic name (as like > > > > > kafka-producer). > > > > > > >> > > > > > > >> Regards, > > > > > > >> Apoorv Mittal > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
