Hi PoAn, Yes, the metrics are exposed for both brokers and controllers:
- Brokers: kafka.server:type=KafkaServer,name=<metric-name> - Controllers: kafka.server:type=ControllerServer,name=<metric-name> I have updated the KIP to explicitly mention both JMX paths. Thanks, Sahil On Mon, May 4, 2026 at 12:32 PM PoAn Yang <[email protected]> wrote: > 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 > >>>> > >>> > >> > >
