Upgrade to Pro — share decks privately, control downloads, hide ads and more …

2024-05-31 Spring IO - Micrometer Mastery: Unle...

2024-05-31 Spring IO - Micrometer Mastery: Unleash Advanced Observability in your JVM Apps

Jonatan Ivanov

June 04, 2024
Tweet

More Decks by Jonatan Ivanov

Other Decks in Programming

Transcript

  1. Recap of observability basics • Purpose • Metrics • Tracing

    • Out-of-the-box instrumentation for common components • Spring Boot auto-configuration
  2. What is Observability? How well we can understand the internals

    of a system based on its outputs (Providing meaningful information about what happens inside) (Data about your app)
  3. Why do we need Observability? Today's systems are increasingly complex

    (cloud) (Death Star Architecture, Big Ball of Mud)
  4. Environments can be chaotic You turn a knob here a

    little and apps are going down there We need to deal with unknown unknowns We can’t know everything Things can be perceived differently by observers Everything is broken for the users but seems ok to you Why do we need Observability?
  5. Why do we need Observability? (business perspective) Reduce lost revenue

    from production incidents Lower mean time to recovery (MTTR) Require less specialized knowledge Shared method of investigating across system Quantify user experience Don't guess, measure!
  6. Examples Latency Logging (What?) Processing took 140ms Metrics (Context?) P99.999:

    140ms Max: 150ms Distributed Tracing (Why?) DB was slow (lot of data was requested) Error Logging (What?) Processing failed (stacktrace?) Metrics (Context?) The error rate is 0.001/sec 2 errors in the last 30 minutes Distributed Tracing (Why?) DB call failed (invalid input)
  7. SLF4J with Logback comes pre-configured SLF4J (Simple Logging Façade for

    Java) Simple API for logging libraries Logback Natively implements the SLF4J API If you want Log4j2 instead of Logback: - spring-boot-starter-logging + spring-boot-starter-log4j2 Logging with JVM/Spring: SLF4J + Logback
  8. Metrics with JVM/Spring: Micrometer Dimensional Metrics library on the JVM

    Like SLF4J, but for metrics API is independent of the configured metrics backend Supports many backends Comes with spring-boot-actuator Spring projects are instrumented using Micrometer Many third-party libraries use Micrometer
  9. Supported metrics backends/formats/protocols Ganglia Graphite Humio InfluxDB JMX KairosDB New

    Relic (/actuator/metrics) OpenTSDB OTLP Prometheus SignalFx Stackdriver (GCP) StatsD Wavefront (VMware) AppOptics Atlas Azure Monitor CloudWatch (AWS) Datadog Dynatrace Elastic
  10. Distributed Tracing with JVM/Spring Boot 2.x: Spring Cloud Sleuth Boot

    3.x: Micrometer Tracing (Sleuth w/o Spring dependencies) Provide an abstraction layer on top of tracing libraries - Brave (OpenZipkin), “default” - OpenTelemetry (CNCF), “experimental” Instrumentation for Spring Projects, 3rd party libraries, your app Support for various backends
  11. Cover w/ Image So we’re done…? • Out-of-the-box instrumentation is

    useful! • But what about: ◦ Custom components ◦ Customization of existing instrumentation ◦ Understanding how instrumentation works
  12. • Add logs (application logs) • Add metrics • Add

    Distributed Tracing You want to instrument your application…
  13. Introducing Observation API • New module in Micrometer 1.10 (micrometer-observation)

    - micrometer-core has a dependency on it • Higher level abstraction than metrics or tracing for timing an operation • Instrument once, configure handlers for multiple purposes (e.g.: metrics, tracing, logging) • Already used for most instrumentation shown
  14. Observation API basic usage example Observation observation = Observation.start("talk",registry); try

    { // TODO: scope doSomething(); // ← This is what we’re observing } catch (Exception exception) { observation.error(exception); throw exception; } finally { // TODO: attach tags (key-value) observation.stop(); }
  15. ObservationHandler with Spring Boot Spring Boot auto-configures handlers for meters

    and tracing. Boot will also register ObservationHandler beans to the ObservationRegistry that it auto-configures. @Bean ObservationHandler<MyContext> myHandler() { return new MyObservationHandler(); }
  16. Configuring an ObservationHandler (without Boot) ObservationRegistry registry = ObservationRegistry.create(); registry.observationConfig()

    .observationHandler(new MetricsHandler(...)) .observationHandler(new TracingHandler(...)) .observationHandler(new LoggingHandler(...)) .observationHandler(new AuditEventHandler(...));
  17. Observation Predicate and Filter ObservationPredicate • BiPredicate: (name, context) →

    Boolean • Whether an Observation is ignored (noop) ObservationFilter • Modify the Observation.Context • Right before ObservationHandler#onStop • e.g. common tags (KeyValues)
  18. Conventions for instrumentation • Instrumentation by default provides a convention

    ◦ Naming, tags (KeyValues) • You may want to customize the convention for an instrumentation without rewriting the instrumentation • Control the timing of changing conventions ◦ Convention changes are breaking changes
  19. Introducing ObservationConvention • Instrumentation can use a default ObservationConvention while

    allowing users to provide a custom implementation • Extend a default implementation or implement your own • See, for example, Spring Framework’s docs
  20. Observation.Context • Holds the state/data of an Observation ◦ e.g.

    request/response object • ObservationHandler / ObservationConvention will receive it • Mutable, you can add data to it ◦ Instrumentation time ◦ Pass data between handler methods
  21. Documenting instrumentation • Keeping documentation in sync with the implementation

    is difficult and error-prone. • Introducing Micrometer Docs Generator • Define an ObservationDocumentation enum for your Observation-based instrumentation and generate documentation based on it as part of the build • Integrate it with ObservationConvention