Hi all, Thanks for all the comments about the metric type field for the minimum and maximum supported feature levels. I agree they are software version specific. Also, since they are shared across the broker and controller like the FinalizedLevel metric, having two separate metrics is redundant and confusing, so I think we should add another metric group to cover metrics that are "software version-specific" like José and PoAn mentioned. I think "NodeMetrics" is a good name for the new metric group.
I still think the FinalizedLevel metric should still reside in the MetadataLoader metrics, since we derive its value from feature records in the metadata log. PY_0: Okay, I will update the section with a link to KIP-1160. Thanks, Kevin On Tue, May 13, 2025 at 8:56 AM Kevin Wu <kevin.wu2...@gmail.com> wrote: > Hey Jun, > > Thanks for the comments: > 4. Maybe I'm missing something, but I think the MetadataLoader is used by > both the broker and controller, so having the one metric works for both > node types. The CurrentMetadataVersion metric is currently reported on both > the broker and controller. > 5. What is the best naming practice for additional metrics being added to > existing metrics groups? I'm following the naming convention that is > already in place for these existing metrics objects (MetadataLoaderMetrics > and BrokerServerMetrics), where the former is camel case and the latter is > kebab case. > > Best, > Kevin Wu > > On Mon, May 12, 2025 at 9:05 AM Kevin Wu <kevin.wu2...@gmail.com> wrote: > >> Hey Chia-Ping and Justine, >> >> Okay, that makes sense about the minimum version changing at some point. >> I'll add these metrics to this KIP. Thanks for the insightful discussion. >> >> Best, >> Kevin Wu >> >> On Fri, May 9, 2025 at 4:54 PM Kevin Wu <kevin.wu2...@gmail.com> wrote: >> >>> Hey Chia-Ping and Justine, >>> >>> Thanks for the explanation. I see where y'all are coming from, but I >>> want to make sure I understand how the value of this metric would change. >>> >>> It seems to me that the supported feature range is determined by the >>> software version, so this metric's value should only change when a software >>> upgrade/downgrade occurs. Otherwise, the range should not change. Is that >>> correct? >>> >>> Also, if we want to add this metric, we would just have one additional >>> metric per feature right, which would be the maximum feature level >>> supported, since the minimum is always 0? >>> >>> Thanks, >>> Kevin >>> >>> On Thu, May 8, 2025 at 6:06 PM Kevin Wu <kevin.wu2...@gmail.com> wrote: >>> >>>> Hey Chia-Ping, >>>> >>>> I hadn't considered adding the supported versions for each feature as a >>>> metric, but I'm not sure if it's helpful for monitoring the progress of an >>>> upgrade/downgrade of a feature. For example, if a node doesn't support a >>>> particular feature level we're upgrading to, we shouldn't even be allowed >>>> to run the upgrade right? I think that's the case for kraft.version (which >>>> might be a special case), but I'm not sure about the other features. The >>>> use case for exposing the finalized feature level is that monitoring it >>>> across all nodes tells the operator that an upgrade/downgrade of the >>>> feature was completed on every node. >>>> >>>> Best, >>>> Kevin Wu >>>> >>>> On Thu, May 8, 2025 at 9:04 AM Kevin Wu <kevin.wu2...@gmail.com> wrote: >>>> >>>>> Hey Jun, >>>>> >>>>> Thanks for the comments. >>>>> 1. I'll update the KIP. My trunk is a bit stale. >>>>> 2. Yeah, the metric should report the finalized feature level for the >>>>> feature. And if it is not set, the metric will report 0. >>>>> 3. I'll update the KIP with a timeline. >>>>> >>>>> Thanks, >>>>> Kevin >>>>> >>>>> On Wed, May 7, 2025 at 3:10 PM Kevin Wu <kevin.wu2...@gmail.com> >>>>> wrote: >>>>> >>>>>> Hey Jose, >>>>>> >>>>>> Thanks for the response. Yeah, the new metric should expose >>>>>> metadata.version as well. Let me update the KIP to reflect that. >>>>>> >>>>>> Thanks, >>>>>> Kevin Wu >>>>>> >>>>>> On Wed, May 7, 2025 at 2:54 PM Kevin Wu <kevin.wu2...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Hello all, >>>>>>> >>>>>>> I wrote a KIP to add a generic feature level metric. >>>>>>> Here's the link: >>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1180%3A+Add+a+generic+feature+level+metric >>>>>>> >>>>>>> Thanks, >>>>>>> Kevin Wu >>>>>>> >>>>>>> >>>>>>>
