8

I'm new to metrics in general and especially Micrometer, so this might be a dumb question:

Micrometer describes itself on the home page as a "facade" "without vendor lock-in", "think SLF4J, but for metrics". With "built-in support for [...] Netflix Atlas". The docs say it's included in Spring Boot 2.

So what I'd expect is the ability to configure the monitoring system on start-up - just as I would with SLF4J. So this doc describes a setting management.metrics.export.atlas.enabled (among others) for Spring Boot. But even with this setting auto-wiring a MeterRegistry registry fails as follows:

Parameter 4 of constructor in [snip] required a bean of type 'io.micrometer.core.instrument.MeterRegistry' that could not be found.

Action:

Consider defining a bean of type 'io.micrometer.core.instrument.MeterRegistry' in your configuration.

Google led me to Baeldung where I read about some micrometer-registry-atlas dependency plus providing a MeterRegistrybean of type AtlasMeterRegistry. This works, but it's not what I call a "facade without vendor lock-in", but I guess I'm just doing it wrong?

How can I provide the monitoring system during runtime, switching between Atlas and any other without re-compiling?

crusy
  • 1,424
  • 2
  • 25
  • 54
  • Have you checked https://github.com/bclozel/issues-dashboard/issues/3 – Mandar Dharurkar Jan 15 '20 at 10:48
  • Yes, I saw that. It's about a project called "issues-dashboard", so it's nothing directly related... still I'd be interested in the fix mentioned by the project's owner on Jul 5, 2018 – there's just no corresponding commit I could check. The commits are from 2017 only – crusy Jan 15 '20 at 11:19
  • You can switch at runtime with property you mentioned, you merely need to include all the registry dependencies (atlas o/andr Prometheus, etc) you want to switch among. Then just switch the property, non need to recompile. – checketts Jan 16 '20 at 03:47
  • Not sure if I understand: Apparently I need to provide a bean of type `AtlasMeterRegistry`, how would I achieve this without providing the deps at compile time? The only compromise I can think of would be to include _all_ deps I want to support during compile time and make the according beans/configurations `@ConditionalOnProperty`.. – crusy Jan 16 '20 at 07:02
  • EDIT: Of course one could configure beans using Spring XML configuration. Do you mean that? I'm coming from Spring Boot (see question), so this isn't something I usually think of ;-) – crusy Jan 16 '20 at 07:13

2 Answers2

9

@crusy you are actually right, but the feature is part of the Actuator module. This is not well documented and I was lucky to find the answer in the Spring Boot Gitter channnel https://gitter.im/spring-projects/spring-boot/archives/2019/01/24?at=5c4980b00721b912a5cdc02f.

You will notice that the Metrics section in the Spring Boot documentation is under Actuator: https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#production-ready-metrics.

This means that in order for Micrometer to work out of the box, you need to include Actuator in your build. E.g for Gradle:

implementation ('org.springframework.boot:spring-boot-starter-actuator')

The MeterRegistry bean will be there now.

Martín Coll
  • 3,368
  • 3
  • 37
  • 52
0

One of the definitions I found on Wikipedia says that vendor lock-in:

makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs.

Micrometer helps to unify interfaces to collect metrics (timers, gauges, counters, etc.), but there is no standard on how these metrics are shipped to backends (Atlas, Prometheus, etc.). That is the main reason why you need to define a specific library (micrometer-registry-atlas), properties, and sometimes also additional configuration.

Micrometer doesn't bring costs needed to switch to another backend to zero, but at least they are kept to minimum.

Sergii Zhevzhyk
  • 4,074
  • 22
  • 28
  • Fair enough. Still: I'd like to use Atlas during development (it's in-memory!), ELK during (long-term) testing, and nothing in production - just as it's possible with logging, which they explicitly mention. With described behavior it's not even possible to run the application without running Atlas (separately!) as well – crusy Jan 15 '20 at 11:14
  • See comments above: I guess one could use Spring XML config, so I guess external configuration actually is possible. I'll mark this answer as accepted in a minute, thanks. It's not the Spring *Boot* way, but I guess it does the job – crusy Jan 16 '20 at 07:15