Hi Mickael, At least at my company, we actually do collect a subset of metrics from our clients and brokers. And without a dual-write mode upgrades become a little risky; you don't get a safety net if there's a typo in your observability stack that causes, e.g., automated alerts to silently fail.
I'd find an argument against dual writes that centers on implementation/maintenance complexity convincing, but if the only concern is volume of metrics, isn't it enough to add a warning about this to the docs for the property? Cheers, Chris On Mon, Feb 16, 2026, 15:29 Mickael Maison <[email protected]> wrote: > Hi, > > Thanks Chris for the feedback. > When writing KIP-877 I already had this KIP in mind. I'm finally > getting to tackle it now, > > 1. I briefly considered it but wasn't sure if there is a need for it. > My main concern is the volume of metrics. In my experience users often > collect all metrics (or none but that's a different story) and this > would effectively double the number of series. As there are metric > series per partition and consumer group that can quickly escalate. > Also by having a boolean, I though it would kind of trigger people to > flip the switch and migrate, instead of just enabling both and running > like this till 5.0. > > 2. That's right. Only MirrorSourceConnector and > MirrorCheckpointConnector have metrics. > I've added that to the KIP. > > 3. That's a good suggestion. I've added it to the KIP. > > 4. You caught me red handed copy pasting from another KIP. I've > removed the "Update Mode" as it's not relevant for connector > configurations. > > Thanks, > Mickael > > On Sat, Feb 14, 2026 at 5:17 PM Chris Egerton <[email protected]> > wrote: > > > > Hi Mickael, > > > > Thanks for the KIP! While reviewing 877 I remember wondering if/when we'd > > see this follow-up. I think it's a good idea to align the MM2 metrics > with > > the 877 style and eat some of our own dogfood as well. Thoughts: > > > > 1. Can we support a dual-write mode to reduce risk during upgrades? Can > > elaborate more on the motivation here if necessary. > > > > 2. I take it the heartbeat connector and client utils don't report any > > custom metrics? If so, would be nice to see that called out, and if not, > > I'd expect to see them mentioned in either a rejected alternatives or > > future work section. > > > > 3. Guessing we'll want to log some kind of notice to users who are still > > using the legacy metrics? I don't care (at this point) whether it's at > info > > or warn level but it'd be nice to know that we plan to emit some kind of > > message. > > > > 4. (Nit) I think the "Update Mode" attribute for the new property may > have > > been left in accidentally? If not, would you mind explaining what it > means > > for a connector? > > > > Cheers, > > > > Chris > > > > On Fri, Feb 13, 2026, 11:19 Mickael Maison <[email protected]> > wrote: > > > > > Hi, > > > > > > I'd like to start a discussion about KIP-1280: > > > https://cwiki.apache.org/confluence/x/a4s8G > > > > > > This proposes updating the MirrorMaker connectors to use KIP-877 to > > > register their metrics. > > > > > > Let me know if you have any questions or feedback. > > > > > > Thanks, > > > Mickael > > > >
