I know we don't have to plus-one a lazy consensus, but maybe I can provide a little context since I did the bulk of the work on the OTel metrics and creating that particular mess.
FWIW, I've definitely had people ask if it's possible to ad custom metrics in their Dags. If you had asked me ten minutes ago if the process to do it was in our official docs, I'd have said yes... but I just looked and couldn't find it. So I guess I lean toward saying it isn't documented, therefore it isn't public interface. I would support this with the caveat that it's still possible for the user to add custom metrics to their Dags should they choose to do so. ________________________________ From: Daniel Standish via dev <[email protected]> Sent: Wednesday, March 18, 2026 7:05 AM To: [email protected] <[email protected]> Cc: Daniel Standish <[email protected]> Subject: RE: [EXT] [LAZY CONSENSUS] Remove the airflow.metrics and airflow.stats modules CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le contenu ne présente aucun risque. To try to emphasize some points: * airflow.stats and airflow.metrics have been in there since 2.7 * as of now they are removed in main, and these removals will be reflected in 3.2 * this is ok if we agree that these were not user-public interface (i.e. people are not using them in their dags) * a (silent) vote of +1 in this lazy consensus means, yes we can remove (do nothing) * a vote of -1 means, we can't just remove we have to keep the interfaces around where they were, so we have to add backcompat shims This is the same vote we had for traces (added 3.0), but now for airflow.stats and airflow.metrics added (2.7) On Wed, Mar 18, 2026 at 3:23 AM Christos Bisias <[email protected]> wrote: > Hello everyone, > > For accessing metrics and traces, there were metaclass interfaces, called > `Stats` and `Trace` respectively. Each interface was reading the config > and then initializing the instance of the appropriate implementation. Each > metaclass was acting like a singleton cache and in all consecutive calls > after the first one, it would always access the same existing instance. > > Daniel Standish has been leading an effort to simplify the OTel traces > code. He was able to remove the `Trace` interface and add a single > configuration when initializing all the airflow settings in core. > > Traces were simpler because they have a single supported implementation > while metrics have multiple. But after discussions, we think that we can > follow a similar approach and remove the stats interface. The reason is > that there is too much complexity that increases with every new addition or > refactoring. It's going to be easier to maintain if simplified. > > The question is whether `airflow.metrics` and `airflow.stats` are public > interfaces. They have been around since airflow 2.7 but as far as I know, > no one from the community has talked about adding user-defined metrics from > under dags. Additionally, there are no docs saying how users can do it. The > only public info is for enabling the project's internal metrics. > > I'm considering these modules as private and I'm assuming that users aren't > aware of them or using them. I think they are safe to remove. > > I would like to call for a lazy consensus vote which will run for 72 hours. > If no one votes -1 during the voting period, the vote will be considered > passed. > > Thank you! > > Regards, > Christos >
