Most monitoring systems we have support for are push based and some of them will prevent the context to start if an API token (or account id) is not configured.
Each of them have a .enabled property that can be used to disable that check (and the export of metrics for it. It would be nice if we had a monitoring agnostic way of doing this, while still allowing the metrics to be asserted in memory.
@AutoConfigureMetrics comes to mind. I don't know if that would be similar to @AutoConfigureCache but something that makes sure metrics are only exported in memory would be quite convenient, I suspect.
Comment From: onobc
@snicoll I have this next week available for OSS and am interested in this one. I want to make sure you have not already headed out on this.
Comment From: snicoll
Thanks for the offer @bono007. I am not assigned, so no.
I said I would write a summary of our discussion after the team meeting and I forgot. In the meantime, I might have forgot some of it.
What I do remember is that we want in memory metrics to be the default in tests and no monitoring system specific auto-configurations should apply. This isn't possible at the moment as our metrics auto-configuration can adapt multiple MeterRegistry beans (in case you'd want to publish metrics to multiple systems). So some changes is required there. The purpose of @AutoConfigureMetrics would be to override that behaviour.
Comment From: onobc
Thanks @snicoll for adding that detail - its helpful.
auto-configuration can adapt multiple MeterRegistry beans (in case you'd want to publish metrics to multiple systems).
I am very familiar w/ this as we do it at my current company.
I will start digging in and will ping back here any questions I have.
Comment From: snicoll
Closing in favour of PR #21658