Thanks Mickael, LGTM! On Wed, Feb 18, 2026 at 10:23 AM Mickael Maison <[email protected]> wrote:
> 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 > > > > > > > > >
