Where does Micrometer fit in OpenTelemetry project

Question

With OpenTelemetry trying to become the de-facto standard for Observability of applications/services, where does Micrometer fit in? Micrometer website claims that it is SLF4J for metrics, but does it not contradict OpenTelemetry's Metrics APIs? I wonder if OpenTelemetry's Metric APIs should represent SLF4J and Micrometer should represent an implementation like Log4J.

Appreciate if someone can help me clarify this.

Auricula

Answer 1

I would say the answer by @checketts is now quite out of date. Metrics are now very prominent within OpenTelemetry, with them being declared stable.

OpenTelemetry and Micrometer share some similarities in the sense that they both have metric APIs. They both have the ability to export a variety of different formats. However Micrometer is Java-specific, while OpenTelemetry has implementations in many languages. The two projects have different goals.

You can use OpenTelemetry with the Micrometer API, by using the OpenTelemetry Meter Registry for Micrometer. This will forward Micrometer's captured metrics into an OpenTelemetry meter.

Outflow

Answer 2

OpenTelemetry is focused on tracing (see zipkin and Jaeger) more than metrics. There is an overlap with Micrometer metrics, but the approach is quite different.

Micrometer is still similar to slf4j since it is the metrics facade for coding to recording metrics. The actual implementation (as you think about log4j) for metrics is Prometheus, Statsd, Datadog, etc.

So OpenTelemetry and Micrometer could both be considered metric abstractions, but since there are different types of metrics (tracing and performance aggregations), they track different things.

Another way to think about this is OpenTelemtry would be useful to measure across many microservices as they hand off requests and you need to trace behavior, while Micrometer would be more useful for tracking a single application's performance and health.

Venola

I am little confused. 1) What is the differences between metrics supported by OpenTelemetry vs Micrometer? 2) Isn't OpenTelemetry touting to become standard for exporting traces, METRICS and logs? 3) Do I need to enable OpenTelemetrics metrics as well as micrometer for observability? – Chiou

Answer 3

OpenTelemetry Architecture specifies these key components

1. OpenTelemetry Client (helps application/framework code to do instrumentation, helps collect these metrics, helps expose the metrics to the Collector)
2. OpenTelemetry Collector (has push-based/pull-based receivers to collect the metrics from the clients, process, and then export to Backends/Databases )
3. OpenTelemetry Backends/Databases.

Micrometer fits in as part of the Telemetry Client. provides vendor-neutral API to instrument/collect metrics. Micrometer library is Spring's way of doing things. Micrometer along with Spring's actuators form the Telemetry/OpenTelemetry client.

Said

Answer 4

Disclaimer: I’m a maintainer of the Micrometer and Spring Cloud Sleuth projects.

I would be cautious about statements such as “de facto standard” (especially following the history of OpenTracing - e.g. Couchbase went all in on OT and now they created their own facade) or claims that it’s Micrometer that should fit in the said project, since Micrometer has been in the industry for longer.

Micrometer (since 2016) and its distributed tracing predecessor Spring Cloud Sleuth (since 2014) have been Generally Available (GA) for almost a decade. We haven’t been breaking compatibility with each release, we’re not releasing alpha versions, we’re releasing GA versions. We’re giving our users options to migrate to new versions gradually since we’re releasing a minor release every 6 months. Micrometer projects are widely used throughout the word by the developers and library maintainers.

Micrometer instruments projects either in the Micrometer codebase or directly in the projects’ codebases. Regardless, we update the code whenever the instrumented projects change over time. You don’t have to install any agents, it doesn’t rely on reflections so you won’t get any compatibility problems. It also works well with native images! In case instrumentation is difficult or impossible to be done, we work with the instrumented project to learn how the project could get instrumented properly and help the projects add additional hook points.

Micrometer Observation API allows you to instrument your code once and have multiple benefits out of it. Today you can have traces, metrics and logs but in the future you can plug in new signals. That won’t require your instrumentation code to change at all. New signals become a configuration problem. Same relates to naming conventions and tagging - you can configure these separately. If you have separate APIs for different signals you need to write the same code multiple times to do the instrumentation.

Micrometer, Micrometer Observation and Micrometer Tracing APIs provide facades that can be trusted, to our users. Micrometer is not going anywhere, it’s actively maintained! History taught us that even the de facto standards (like Netflix Hystrix) can become obsolete one day. So, even if today you’re using a tool that our API delegates to, you’ll be able to migrate away from that tool if it ever gets dropped. You’re safe with us! Also, you can use Micrometer Observation without Micrometer Tracing, in fact, as far as distributed tracing is concerned, you can even configure Micrometer to use your favorite tracing tool directly!

Micrometer Docs Generator contains very interesting features such as it can have your code scanned and produce documentation out of it. Example for Spring Cloud Task.

To sum it up: as you can see the Micrometer portfolio is stable, mature, is being developed actively, has a healthy community and has a broad feature set. It can work with various signals such as metrics, traces coming from different libraries including OpenTelemetry or Brave. Micrometer is vendor-neutral and supports various protocols (e.g. W3C, B3, OTLP, Prometheus etc.).

Recurrent