Skip to content

Instantly share code, notes, and snippets.

@lmolkova
Last active April 16, 2024 01:29
Show Gist options
  • Save lmolkova/7406022d60572f65d86eea158f89c58b to your computer and use it in GitHub Desktop.
Save lmolkova/7406022d60572f65d86eea158f89c58b to your computer and use it in GitHub Desktop.
Micrometer question

What's Micrometer story for library owners

  • Which one to use Otel or Micrometer. Why?
  • Semantic conventions - how users can pick which ones they want? will libs need to provide all possible options?
  • What's the story in other languages/ecosystems? I need my python messaging consumer to be consistent with my java messaging producer.
  • Which libraries beyond Spring are all-in on Micrometer?
  • How do you prioritize features? What if something is missing? (E.g. structured events on spans, adding link after span creation, etc)
    • is Micrometer targeting feature-parity with OTel specification? Will micrometer introduce profling API?
  • How big is the community? Are there community calls? Who makes decisions?

What's Micrometer story for end users

  • What if user app needs some instrumentations from Micrometer and some from OTel - how context propagation works? How exemplars work?
  • Which API user should use - Micrometer or OTel?
    • Why add an extra layer (Micrometer -> OTel API -> OTel SDK -> exporter)? I still enable/configure OTel SDK - what benefit Micrometer API brings?
  • Resources, cloud environment support - are there resource detectors (service name, subscription, lambda names etc).

Hopes and wishes

  • Spring/Micrometer should use otel semantic conventions - HTTP is stable, JVM metrics are stable, messaging and DB are stabilizing by the end of 2024. Some resources are likely to be stabilized too. Even if OTel dissapears tomorrow, a specific set of string literals for attribute/metircs names could stay the same.
  • work together to introduce common context and propagate it properly and efficiently through async calls. Client libs work in all ecosystems and solution should not be specific to Spring.
  • Provide clear guidance for lib and app authors to use OTel API as a facade in new projects. OTel is backed by the whole industry and is vendor-neutral. There are a LOT of projects (e.g. within MS) that depend on it and we'd have to support them forever along with OTel.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment