Hi, Thanks for sharing your experience. I can understand your point about making it safer to migrate.
I've updated to KIP to allow emitting metrics with both names at the same time. Thanks, Mickael On Tue, Feb 17, 2026 at 7:58 PM Chris Egerton <[email protected]> wrote: > > 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 > > > > > >
