search

micrometer-metrics / micrometer

An application observability facade for the most popular observability tools. Think SLF4J, but for observability.
https://micrometer.io
Apache License 2.0
4.46k stars 990 forks source link

provide micrometer API #5600

Open FlorianEgel opened 3 days ago

FlorianEgel commented 3 days ago

If I'm not mistaken I currently have to add a dependency to micrometer-core to every module using metrics, which is a huge jar that contains almost the entire framework. I suggest you splitting this module to micrometer-core containing the functionality and micrometer-api containing only the annotations and instrument classes.

Rationale Frameworks like slf4j, log4j2, the entire jakarta ee family etc. all provide a separate api module that is very small in size, that only contains annotations and the classes necessary for the code to compile, without the functionality.

Sticking to the example of slf4j, all I need to create and use loggers is adding the dependency to slf4j-api to my project, which is only a few KB in size. If my module is used in an app that doesn't provide an implementation the code still works with no issues, I just don't get logging obviously. That way I can support (logging/monitoring) in my module and still decide for myself if I want to use it or not in the actual app without having to change any code in the modules. If I don't want to use it all it adds is a tiny api jar of a few kb to my bill of materials.

shakuzen commented 3 days ago

Thanks for opening the issue with the idea. Separating just API out to its own module or otherwise reducing the size of micrometer-core has been discussed several times in the past. If we were starting from scratch again, probably we would try to take such an approach. However, given the current state, the question is how would we get to such a state without breaking backward compatibility and without introducing split packages? We would consider proposals that avoid those issues. Let us know if you have a concrete idea on how the changes would look.

We did work on an attempt to move our out-of-the-box provided instrumentation from micrometer-core to a separate module micrometer-binders in a 2.0 version we were working on, but we ended up halting work on that because backward compatibility was of greater concern to users than a smaller micrometer-core JAR.

While I understand in general having a smaller JAR would be preferable, is the 850 KB jar really an issue over an 80 KB jar for some particular reason?

That way I can support (logging/monitoring) in my module and still decide for myself if I want to use it or not in the actual app without having to change any code in the modules.

The intention is that that is how things already work with micrometer-core. The module with the instrumentation does not need to care whether the application will publish metrics or not - such modules interact with MeterRegistry and the various meter interfaces such as Timer and Counter. Any or all metrics could all be disabled or enabled, shipped to any metrics backend (or multiple backends) with a MeterRegistry implementation or only kept locally in memory (e.g. with SimpleMeterRegistry). That is all runtime configuration.

Let us know if we're missing something in terms of functionality here. Maybe we could do a better job documenting this. Any help identifying the lacking parts of the documentation or proposals to improve it would be welcome.