Hi Sahil, Thanks for the KIP.
The KIP mentioned “All metrics exposed under kafka.server:type=KafkaServer,name=<metric-name>”. This is for brokers. Should it also mention "kafka.server:type=ControllerServer” for controllers? Kind Regards, PoAn > On Apr 4, 2026, at 4:54 PM, Chia-Ping Tsai <[email protected]> wrote: > > I agree with separating the concerns. Filing a follow-on KIP for the > migration and deprecation plan is a pragmatic approach. Let's move forward > with KIP-1291 as an additive change first. > > On 2026/04/04 08:26:37 Sahil Devgon wrote: >> Hi CHia-Ping, >> >> Thank you for the review and joining the discussion. I agree that Kafka >> native metrics are the right long-term home for these and that the existing >> Yammer metrics for linux-disk-read-bytes and linux-disk-write-bytes should >> eventually be migrated. However, I'd like to propose separating these >> concerns: >> >> KIP-1291 <https://cwiki.apache.org/confluence/x/co48G> (this KIP): Remain >> purely additive - expose the 5 missing metrics under the existing >> kafka.server:type=KafkaServer,name=linux-disk-* convention. The KIP's >> stated guarantee is zero operational impact and no migration burden for >> existing deployments. >> >> Follow-on KIP: Once the 5 metrics are established, a separate KIP can >> migrate all 7 linux I/O metrics to a dedicated native metrics group (e.g., >> type=linux-io-metrics) and formally deprecate the Yammer equivalents with a >> clear timeline. >> >> My concern with combining them in KIP-1291 >> <https://cwiki.apache.org/confluence/x/co48G> is that deprecation , even of >> metrics that remain functional , is not a zero-impact change for operators >> running dashboards and alerts against the existing MBean. It also opens >> discussion on naming conventions, deprecation >> timelines, and coordination with broader Yammer migration work, all of >> which could delay shipping the 5 metrics that are the core of this KIP and >> that operators need today. >> >> I'm happy to file the follow-on KIP alongside this one so the community can >> see the full intended path. Would that be acceptable? >> >> Best, >> Sahil Devgon >> >> On Sat, Apr 4, 2026 at 1:22 PM Chia-Ping Tsai <[email protected]> wrote: >> >>> hi >>> >>> I am concerned about adding more Yammer metrics. Instead, we should create >>> a new metrics group (e.g., type=linux-io-metrics,cluster-id=aaa) for all >>> seven metrics using Kafka native metrics. This way, the seven parameters >>> can be grouped together as a single MBean. We can then deprecate the >>> original Yammer metrics for linux-disk-read-bytes and linux-disk-write-bytes >>> >>> Best, >>> CHia-Ping >>> >>> On 2026/02/25 14:50:44 Sahil Devgon wrote: >>>> Hi, >>>> >>>> I would like to start a discussion thread on KIP-1291. In this KIP, we >>> aim >>>> to expose all 7 Linux I/O metrics from /proc/self/io instead of just the >>>> current 2 (read_bytes and write_bytes). >>>> The 5 additional metrics (rchar, wchar, syscr, syscw, >>>> cancelled_write_bytes) enable operators to diagnose cache effectiveness, >>>> write amplification, and I/O pattern inefficiencies. >>>> >>>> https://cwiki.apache.org/confluence/x/co48G >>>> >>>> Please review the KIP and feel free to share your thoughts. >>>> >>>> Thanks, >>>> Sahil Devgon >>>> >>> >>
