Spring Boot Actuator 集成 Micrometer（官网文档解读）

概述

实现 Observation 可观测性

Observation 功能核心类

ObservationPredicate

GlobalObservationConvention

ObservationFilter

ObservationHandler

ObservationRegistryCustomizer

Observation 相关注解

多线程处理机制

配置上下文传播

常用标签配置

OpenTelemetry 支持

关闭可观测功能

自定义Micrometer 健康检查映射

Loggers

OpenTelemetry 支持

Metrics

监控系统支持

度量指标支持

JVM 指标

系统指标

应用程序启动指标

logging Metrics：

任务执行和调度指标

JMS Metrics

Spring MVC Metrics

Spring WebFlux Metrics

Jersey Server Metrics

HTTP Client Metrics

Tomcat Metrics

Cache Metrics

DataSource Metrics

Hibernate Metrics

Spring Data Repository Metrics

RabbitMQ Metrics

Spring Integration Metrics

Kafka Metrics

MongoDB Metrics

Jetty Metrics

Redis Metrics

注册自定义指标

自定义单个指标

Meterics Endpoint

Tracing

基于 OpenTelemetry 的追踪器

基于 OpenZipkin Brave 的追踪器

追踪器实现

OpenTelemetry 与 Zipkin

OpenTelemetry 与 Wavefront

使用 OTLP 的 OpenTelemetry

OpenZipkin Brave 与 Zipkin

OpenZipkin Brave 与 Wavefront

学习拓展

Micrometer 官网

Observability for JDBC

openTelemetry

参考文献

概述

Spring Boot Actuator 与 Micrometer 的集成使得开发者可以轻松地收集和监控应用程序的性能指标。Actuator 提供了众多端点（endpoints）来帮助开发者监控和管理应用程序，而 Micrometer 则作为度量数据收集和分发的库。通过将两者结合起来，你可以获得一个强大的工具集来监视生产环境中应用的健康状态。

实现 Observation 可观测性

可观测性是从外部观察正在运行的系统的内部状态的能力。它由三部分组成分别是：日志记录、指标和跟踪。
Spring Boot 使用 Micrometer Observation 实现指标和追踪。我们可以通过注入ObservationRegistry 来实现自己的监控逻辑。
示例代码：

@Component
public class MyCustomObservation {private final ObservationRegistry observationRegistry;public MyCustomObservation(ObservationRegistry observationRegistry) {this.observationRegistry = observationRegistry;}public void doSomething() {Observation.createNotStarted("doSomething", this.observationRegistry).lowCardinalityKeyValue("locale", "en-US").highCardinalityKeyValue("userId", "42").observe(() -> {// Execute business logic here});}}

Observation 功能核心类

ObservationPredicate

定义：ObservationPredicate是一个用于判断是否应该对某个操作或事件进行观测的谓词接口。它定义了一个test方法，接受一个与观测相关的上下文对象，返回一个布尔值，表示是否满足观测条件。

作用：通过实现ObservationPredicate接口，可以根据具体的业务逻辑或条件来决定是否对特定的操作进行观测。例如，可以根据请求的路径、方法名、用户角色等信息来判断是否需要记录观测数据，从而实现有选择性地进行观测，避免不必要的观测开销，也能更精准地获取关注的数据。

GlobalObservationConvention

定义：GlobalObservationConvention是用于定义全局观测约定的接口。它通常用于设置一些全局的观测规则和属性，这些规则和属性会应用到所有的观测操作中。
作用：可以利用GlobalObservationConvention来统一设置观测的标签、名称格式、上下文信息等。比如，为所有的观测添加一些固定的标签，用于标识应用的版本、环境等信息，或者规定观测名称的统一命名规范，使得观测数据在整个系统中具有一致性和规范性，便于后续的分析和处理。

ObservationFilter

定义：ObservationFilter是用于对观测数据进行过滤的接口。它提供了一种机制，在观测数据被记录或处理之前，对其进行筛选和判断。
作用：通过实现ObservationFilter，可以根据特定的条件来决定是否允许某个观测数据通过，或者对观测数据进行修改、补充等操作。例如，可以过滤掉一些敏感信息，或者根据某些业务规则对观测数据进行转换，以便更好地满足数据安全和分析的需求。

ObservationHandler

定义：ObservationHandler是观测处理的核心接口，用于处理观测到的事件和数据。它定义了一系列方法，用于在观测的不同阶段执行相应的操作。
作用
- 数据记录：负责将观测到的数据记录下来，可能是将数据发送到日志文件、数据库或其他数据存储介质中。
- 数据处理：可以对观测数据进行各种处理，如计算统计信息、转换数据格式等。
- 事件通知：在观测到特定事件时，可以通过ObservationHandler来触发一些通知机制，例如发送告警信息、通知其他系统进行相应的处理等。

ObservationRegistryCustomizer

定义：ObservationRegistryCustomizer是 Micrometer 中用于定制ObservationRegistry的工具类。通过实现该接口，可以在应用启动或初始化阶段，对ObservationRegistry进行个性化的设置和调整，以满足特定的监控和观测需求。
作用：
- 配置 ObservationRegistry：允许开发者对ObservationRegistry进行各种配置，比如设置全局的观测选项、添加自定义的ObservationHandler、ObservationFilter或GlobalObservationConvention等。通过这些配置，可以定制观测数据的收集、处理和存储方式，以及观测的行为和特性。
- 添加自定义逻辑：开发者能够在ObservationRegistryCustomizer的实现中添加自定义的逻辑。例如，可以根据应用的运行环境、配置参数或其他条件，动态地决定是否启用某些观测功能，或者调整观测的详细程度。还可以在观测数据记录之前或之后，插入自定义的处理逻辑，对数据进行额外的加工或转换。
- 整合外部系统：有助于将 Micrometer 的观测功能与其他外部系统或框架进行整合。比如，可以通过ObservationRegistryCustomizer将观测数据发送到特定的监控平台或日志系统，实现与现有监控体系的无缝对接，方便进行集中式的监控和管理。

Observation 相关注解

@Timed:@Timed注解用于方法或类上，主要用于测量被注解的方法或类中方法执行的时间。它会自动记录方法执行的耗时，并将其作为一个计时度量指标发布到 Micrometer 的度量系统中。
@Counted:@Counted注解用于统计方法的调用次数。当被注解的方法被调用时，Micrometer 会将对应的计数器加一，通过这种方式可以方便地跟踪方法的调用频率，了解某个方法在系统运行过程中被调用的次数情况。
@MeterTag:@MeterTag注解用于为度量指标添加标签。可以在方法或类上使用，通过它可以为相关的度量指标提供额外的维度信息，方便对度量数据进行分组、过滤和分析。
@NewSpan:@NewSpan注解用于创建一个新的跨度（Span），通常用于分布式追踪场景中。它可以标记一个方法或代码块作为分布式追踪中的一个独立跨度，记录该跨度内的操作和耗时等信息，有助于在分布式系统中跟踪请求的流转和处理过程，方便进行性能分析和故障排查。

使用这些注释的时候，需要确保Spring Boot 配置中设置:

management.observations.annotations.enabled=true

多线程处理机制

在多线程环境或响应式编程中，实现Micrometer 的观测功能依赖于上下文传播（Context Propagation），在管道中保持追踪信息和其他上下文数据的一致性。

配置上下文传播

Spring 框架提供了一个配置属性 spring.reactor.context-propagation 来控制上下文传播的行为。默认情况下，上下文传播是禁用的，因为这可能会对性能产生影响。你可以将此属性设置为 auto 来启用自动上下文传播，这样就能保证在响应式操作符之间自动传播当前的观察上下文。

spring:reactor:context-propagation: auto

一旦启用了自动上下文传播，那么在响应式链中的每个步骤都会继承上一步骤的上下文信息，从而确保追踪和监控数据的一致性和完整性。

常用标签配置

我们可以通过Spring Boot 配置给可观测性添加常用标签，常用标签通常用于对操作环境进行维度深入分析，例如主机、实例、区域、堆栈等。常用标签作为低基数标签可以应用于所有观察，并且可以进行配置。

配置示例：

management:observations:key-values:region: "us-east-1"stack: "prod"

OpenTelemetry 支持

Spring Boot 包含两种关于OpenTelemetry 的支持方式：

OpenTelemetry Java Agent：你可以使用由 OpenTelemetry 社区支持的 Java Agent 来自动仪器化你的应用程序。这个代理可以在不修改代码的情况下添加追踪和度量。
OpenTelemetry Spring Boot Starter：这是一个专门为 Spring Boot 应用设计的启动器，它提供了对 OpenTelemetry 的简单集成。通过添加这个依赖，可以轻松地将 OpenTelemetry 集成到基于 Spring 的项目中。

Spring Boot 的 actuator 模块则提供了对于OpenTelemetry的基础支持。

自动配置 OpenTelemetry Bean：
- 当你引入 OpenTelemetry 相关依赖后，Spring Boot 会自动配置一个 OpenTelemetry 类型的 bean。
- 如果应用上下文中存在 SdkTracerProvider、ContextPropagators、SdkLoggerProvider 或 SdkMeterProvider 类型的 beans，它们会被自动注册到 OpenTelemetry 中。
- 此外，还会提供一个 Resource 类型的 bean，其属性可以通过 management.opentelemetry.resource-attributes 属性进行配置。如果你自己定义了一个 Resource bean，则不会使用默认的自动配置。
自动配置限制
- Spring Boot 并不提供对 OpenTelemetry 的自动配置，我们需要手动设置这部分的功能。
- 只有当 OpenTelemetry 跟踪与 Micrometer Tracing 一起使用时，才会触发自动配置。这是因为 Micrometer Tracing 为追踪提供了额外的支持，如上下文传播等。

关闭可观测功能

我们可以使用management.observations.enable属性，关闭Spring Boot 的可观测性功能。

配置示例：

management:observations:enable:denied:prefix: falseanother:denied:prefix: false

`自定义`Micrometer `健康检查映射`

Spring Boot 健康指标返回一种Status类型来指示整个系统的健康状况。如果您想要监控或警告特定应用程序的健康水平，可以使用 Micrometer 将这些状态导出为指标。默认情况下，Spring Boot 使用状态代码“UP”、“DOWN”、“OUT_OF_SERVICE”和“UNKNOWN”。要导出这些，您需要将这些状态转换为一组数字，以便它们可以与 Micrometer 一起使用Gauge。

@Configuration(proxyBeanMethods = false)
public class MyHealthMetricsExportConfiguration {public MyHealthMetricsExportConfiguration(MeterRegistry registry, HealthEndpoint healthEndpoint) {// This example presumes common tags (such as the app) are applied elsewhereGauge.builder("health", healthEndpoint, this::getStatusCode).strongReference(true).register(registry);}private int getStatusCode(HealthEndpoint health) {Status status = health.health().getStatus();if (Status.UP.equals(status)) {return 3;}if (Status.OUT_OF_SERVICE.equals(status)) {return 2;}if (Status.DOWN.equals(status)) {return 1;}return 0;}}

Loggers

Spring Boot Actuator 包括在运行时查看和配置应用程序日志级别的功能。您可以查看整个列表或单个记录器的配置，该配置由显式配置的日志记录级别以及日志记录框架赋予的有效日志记录级别组成。这些级别可以是以下之一：

TRACE
DEBUG
INFO
WARN
ERROR
FATAL
OFF
null：null表示没有显式配置。

OpenTelemetry 支持

为了在项目中启用OpenTelemetry Logging的支持，我们需要手动配置Spring Boot的相关设置。配置示例:

management:otlp:logging:endpoint: "https://otlp.example.com:4318/v1/logs"

我们需要在logback-spring.xml或log4j2-spring.xml的配置文件中添加OpenTelemetry的相关配置项，以确保OpenTelemetry日志记录功能能够顺利运行。
为了确保Logback 或者 Log4j 可以被正常注册至OpenTelemetry,我们需要使用 OpenTelemetryAppender ，并在应用程序启动期间以编程方式设置此实例。

@Component
class OpenTelemetryAppenderInitializer implements InitializingBean {private final OpenTelemetry openTelemetry;OpenTelemetryAppenderInitializer(OpenTelemetry openTelemetry) {this.openTelemetry = openTelemetry;}@Overridepublic void afterPropertiesSet() {OpenTelemetryAppender.install(this.openTelemetry);}}

Metrics

监控系统支持

Spring Boot Actuator 为 Micrometer 提供依赖管理和自动配置。Spring Boot Metrics 以集成的可自动配置的监控系统包括：

AppOptics：是一种云原生的应用性能监控和可观测性平台，提供了对应用程序性能的深入洞察，包括指标、日志和追踪等功能。可帮助用户快速识别和解决应用中的性能问题，支持多种编程语言和框架，能与常见的云服务和容器平台集成。
Atlas：一般指 Apache Atlas，它主要用于数据治理，提供了数据目录、数据分类、数据血缘等功能，帮助组织管理和理解其数据资产，不是传统意义上的系统性能监控系统，但可辅助在数据层面进行监控和管理。
Datadog：是一款功能强大的云监控和分析平台，可收集和分析来自各种来源的指标、日志和追踪数据，支持大量的集成，包括服务器、容器、数据库、云服务等。提供实时监控、告警、可视化等功能，帮助用户全面了解应用和系统的运行状况。
Dynatrace：是一个全栈式的应用性能管理（APM）和数字化体验管理（DEM）平台，具有自动发现、深度监控和智能告警等功能。利用人工智能和机器学习技术，能够自动识别问题的根本原因，提供端到端的性能可视性，覆盖从基础设施到应用程序的各个层面。
Elastic：即 Elastic Stack（ELK Stack），包括 Elasticsearch、Logstash 和 Kibana 等组件。Elasticsearch 用于存储和搜索数据，Logstash 用于收集和处理日志数据，Kibana 用于可视化展示数据，广泛用于日志管理、监控和数据分析等场景，可实现对大量日志和指标数据的高效处理和可视化。
Ganglia：是一款用于集群监控的工具，主要用于监控大规模集群系统的性能指标，如 CPU、内存、网络等使用情况。具有良好的可扩展性和分布式架构，能实时收集和展示集群中各个节点的性能数据，帮助管理员了解集群的整体运行状态。
Graphite：是一个开源的时间序列数据存储和可视化系统，专注于存储和绘制指标数据的图表。它接收各种来源的指标数据，将其存储在数据库中，并提供简单但有效的可视化界面，用于查看指标的趋势和变化，常与其他监控工具结合使用，用于数据的可视化展示。
Humio：是一个基于云的日志管理和分析平台，专注于提供快速、高效的日志搜索和分析功能。具有强大的查询语言和实时分析能力，可帮助用户从大量日志数据中快速提取有价值的信息，支持与多种数据源集成，适用于各种规模的企业。
Influx：通常指 InfluxDB，是一个专门用于存储和处理时间序列数据的数据库，具有高性能、高可扩展性和易于使用的特点。常用于存储监控数据、传感器数据等时间序列数据，可与各种监控工具和可视化平台集成，为数据分析和可视化提供支持。
JMX（Java Management Extensions）：是 Java 平台的管理和监控规范，允许开发人员通过 Java API 来管理和监控 Java 应用程序、Java 虚拟机（JVM）以及相关的资源。它提供了一种标准的方式来暴露和访问 Java 应用中的各种指标和管理功能，如内存使用、线程状态等，可通过 JMX 客户端工具进行连接和查看。
KairosDB：是一个开源的时间序列数据库，专门用于存储和查询大规模的时间序列数据，如监控指标数据。具有高性能、可扩展性和容错性，支持多种数据存储后端，能与多种监控和数据采集工具集成，为监控系统提供数据存储和查询支持。
New Relic：是一款广泛使用的应用性能监控（APM）工具，可提供对 Web 应用程序、移动应用程序和基础设施的全面监控。它能自动收集各种性能指标，包括响应时间、吞吐量、错误率等，还提供代码级别的分析，帮助开发人员快速定位性能瓶颈和问题所在。
OTLP（OpenTelemetry Protocol）：不是一个完整的监控系统，而是 OpenTelemetry 项目中的数据传输协议，用于在不同的可观测性组件之间传输指标、日志和追踪数据，确保数据在收集、处理和存储过程中的一致性和兼容性，是实现可观测性数据标准化传输的重要基础。
Prometheus：是一个开源的系统监控和告警工具包，以时间序列数据为核心，采用拉取式的数据收集方式，具有强大的查询语言 PromQL，可方便地对监控数据进行查询和分析。它有丰富的生态系统，包括各种 exporter 用于收集不同来源的数据，以及多种可视化工具和告警管理器。
SignalFx：是一家提供云原生监控和可观测性解决方案的公司，其平台可收集和分析来自容器、微服务和云环境的各种指标、日志和追踪数据。利用人工智能和机器学习技术进行异常检测和问题诊断，提供智能告警和可视化功能，帮助用户更好地管理复杂的云原生应用。
Simple (in-memory)：一般指简单的内存监控方式或工具，通常是在应用程序内部使用简单的内存数据结构来临时存储和管理监控数据，适用于一些对监控功能要求不高、规模较小的应用场景，优点是简单易用、开销小，但功能相对有限，不适合处理大量数据和复杂的监控需求。
Stackdriver：是 Google Cloud Platform 提供的一套监控和诊断工具，可帮助用户监控和管理在 Google Cloud 上运行的应用程序和基础设施。提供了指标监控、日志管理、告警等功能，与 Google Cloud 的其他服务紧密集成，方便用户在 Google Cloud 环境中进行统一的监控和管理。
StatsD：是一个用于收集和汇总应用程序指标数据的工具，通常作为代理运行，接收来自应用程序的实时指标数据，如计数器、仪表盘、定时器等，并将其汇总后发送到后端的存储和分析系统，如 Graphite、InfluxDB 等，常用于分布式系统中的监控数据收集，能减轻应用程序的监控数据处理负担。
Wavefront：是一个专注于大规模指标数据监控和分析的平台，具有强大的可视化和告警功能，能处理大量的时间序列数据，提供对应用程序、基础设施和业务指标的深入洞察。支持多种数据来源和集成，可帮助用户快速发现和解决性能问题，优化系统性能。

度量指标支持

Spring Boot 自动配置支持度量指标的自动注册。在大多数情况下，默认提供合理的指标，可发布到任何受支持的监控系统。Spring Boot 支持的度量指标包括：

JVM 指标

各种内存和缓冲池详细信息
垃圾收集相关统计数据
线程利用率
已加载和卸载的类的数量
JVM 版本信息
JIT 编译时间

系统指标

CPU 指标
文件描述符指标
正常运行时间指标（应用程序运行的时间量和绝对启动时间的固定值）
可用磁盘空间

应用程序启动指标

application.started.time：启动应用程序所需的时间。
application.ready.time：应用程序准备好服务请求所需的时间。

logging Metrics：

自动配置可启用 Logback 和 Log4J2 的事件指标。详细信息以log4j2.events.或logback.events.计量表名称发布

任务执行和调度指标

自动配置可以检测所有可用的ThreadPoolTaskExecutor ThreadPoolTaskScheduler 的 beans，只要底层ThreadPoolExecutor可用。指标由执行器的名称标记，该名称源自 bean 名称。

JMS Metrics

自动配置可以对所有可用的JmsTemplate bean 和 @JmsListener注释方法进行检测。这将分别生成"jms.message.publish"和"jms.message.process"指标。

Spring MVC Metrics

自动配置：自动对 Spring MVC 控制器和函数式处理器处理的所有请求进行检测。
指标命名：默认指标名为 http.server.requests，可通过 management.observations.http.server.requests.name 属性自定义。
标签定制：通过提供继承自 DefaultServerRequestObservationConvention 的 @Bean 来添加默认标签；通过提供实现 ServerRequestObservationConvention 的 @Bean 来替换默认标签。
异常处理：默认情况下，Web 控制器中处理的异常不会记录为请求指标标签，应用可通过将处理的异常设置为请求属性来记录。
请求过滤：通过提供实现 FilterRegistrationBean<ServerHttpObservationFilter> 的 @Bean 来自定义请求过滤。

Spring WebFlux Metrics

自动配置：自动对 Spring WebFlux 控制器和函数式处理器处理的所有请求进行检测。
指标命名：默认指标名和定制方式同 Spring MVC，即默认 http.server.requests，可通过 management.observations.http.server.requests.name 自定义。
标签定制：在 org.springframework.http.server.reactive.observation 包中，通过继承 DefaultServerRequestObservationConvention 或实现 ServerRequestObservationConvention 来添加或替换默认标签。
异常处理：同 Spring MVC，控制器和处理函数中处理的异常默认不记录为请求指标标签，可通过设置请求属性记录。

Jersey Server Metrics

自动配置：自动对 Jersey JAX - RS 实现处理的所有请求进行检测。
指标命名：默认指标名及定制方式与前两者一致，即 http.server.requests，可通过 management.observations.http.server.requests.name 自定义。
默认标签：默认带有 exception（处理请求时抛出异常的简单类名）、method（请求方法）、outcome（基于响应状态码的请求结果）、status（响应的 HTTP 状态码）、uri（请求的 URI 模板）等标签。
标签定制：通过提供实现 JerseyObservationConvention 的 @Bean 来自定义标签。

HTTP Client Metrics

组件支持：Spring Boot Actuator 管理 RestTemplate、WebClient 和 RestClient 的检测。
实例创建：需注入自动配置的构建器创建实例，如 RestTemplateBuilder 用于 RestTemplate，WebClient.Builder 用于 WebClient，RestClient.Builder 用于 RestClient，也可手动应用 ObservationRestTemplateCustomizer 等定制器。
指标命名：默认指标名为 http.client.requests，可通过 management.observations.http.client.requests.name 属性自定义。
标签定制：对于 RestTemplate 或 RestClient，提供实现 org.springframework.http.client.observation 包中 ClientRequestObservationConvention 的 @Bean 来定制标签；对于 WebClient，提供实现 org.springframework.web.reactive.function.client 包中 ClientRequestObservationConvention 的 @Bean 来定制。

Tomcat Metrics

自动配置：仅在启用 MBean 注册表时自动对 Tomcat 进行检测，默认 MBean 注册表禁用，可通过设置 server.tomcat.mbeanregistry.enabled=true 启用。
指标命名：Tomcat 指标以 tomcat. 为前缀发布。

Cache Metrics

自动配置：启动时自动对所有可用的缓存实例进行检测，指标前缀为 cache。
支持库：支持 Cache2k、Caffeine、Hazelcast、任何符合 JCache（JSR - 107）的实现以及 Redis。
标签设置：指标按缓存名称和从 Bean 名称派生的 CacheManager 名称进行标记。

DataSource Metrics

jdbc.connections 相关指标：对所有可用的 DataSource 对象进行检测，生成表示连接池当前活动、空闲、允许的最大和最小连接数的指标。
hikaricp 前缀指标：针对 Hikari 数据源，会以 hikaricp 为前缀暴露特定指标，每个指标通过连接池名称标记。
标记方式：指标通过基于 bean 名称计算出的 DataSource 名称进行标记。

Hibernate Metrics

指标条件：当org.hibernate.orm:hibernate - micrometer在类路径中，且启用了统计功能（hibernate.generate_statistics=true）时，对所有可用的 Hibernate EntityManagerFactory 实例进行检测。
指标名称：指标名称为hibernate，并通过从 bean 名称派生的 EntityManagerFactory 名称进行标记。

Spring Data Repository Metrics

指标名称：默认指标名称为spring.data.repository.invocations，可通过management.metrics.data.repository.metric - name属性自定义。
标记信息
- repository：源 Repository 的简单类名。
- method：被调用的 Repository 方法名称。
- state：结果状态，包括 SUCCESS、ERROR、CANCELED 或 RUNNING。
- exception：调用抛出的异常的简单类名。

RabbitMQ Metrics

对所有可用的 RabbitMQ 连接工厂进行检测，指标名称为rabbitmq。

Spring Integration Metrics

只要MeterRegistry bean 可用，Spring Integration 就会自动提供 Micrometer 支持，指标发布在spring.integration下。

Kafka Metrics

自动配置分别为消费者工厂和生产者工厂注册MicrometerConsumerListener和MicrometerProducerListener，还为StreamsBuilderFactoryBean注册KafkaStreamsMicrometerListener。

MongoDB Metrics

MongoDB Command Metrics：为发送到底层 MongoDB 驱动程序的每个命令创建名为mongodb.driver.commands的定时器指标。
标记信息
- command：发出的命令名称。
- cluster.id：命令发送到的集群的标识符。
- server.address：命令发送到的服务器地址。
- status：命令的结果，SUCCESS 或 FAILED。
MongoDB Connection Pool Metrics
指标内容
- mongodb.driver.pool.size：报告连接池的当前大小，包括空闲和正在使用的连接。
- mongodb.driver.pool.checkedout：报告当前正在使用的连接数。
- mongodb.driver.pool.waitqueuesize：报告连接池等待队列的当前大小。
标记信息
- cluster.id：连接池对应的集群的标识符。
- server.address：连接池对应的服务器地址。

Jetty Metrics

Jetty’s ThreadPool 指标：通过 Micrometer’s JettyServerThreadPoolMetrics 绑定。
Jetty’s Connector instances 指标：通过 Micrometer’s JettyConnectionMetrics 绑定，当server.ssl.enabled=true时，还会通过 Micrometer’s JettySslHandshakeMetrics 绑定。

Redis Metrics

为自动配置的LettuceConnectionFactory注册MicrometerCommandLatencyRecorder。

注册自定义指标

要注册自定义指标，请注入MeterRegistry到您的组件中：

@Component
public class MyBean {private final Dictionary dictionary;public MyBean(MeterRegistry registry) {this.dictionary = Dictionary.load();registry.gauge("dictionary.size", Tags.empty(), this.dictionary.getWords().size());}}

如果您的指标依赖于其他 bean，我们建议您使用MeterBinder来注册它们：

public class MyMeterBinderConfiguration {@Beanpublic MeterBinder queueSize(Queue queue) {return (registry) -> Gauge.builder("queueSize", queue::size).register(registry);}}

使用MeterBinder确保设置了正确的依赖关系，并且在检索度量值时bean可用。如果您发现在组件或应用程序之间重复检测一组度量，则MeterBinder实现也可能很有用。
默认情况下，所有MeterBinder bean 的指标都会自动绑定到 Spring 管理的MeterRegistry

自定义单个指标

我们可以使用MeterFilter去重新定义某个指标，例如：

@Configuration(proxyBeanMethods = false)
public class MyMetricsFilterConfiguration {@Beanpublic MeterFilter renameRegionTagMeterFilter() {return MeterFilter.renameTag("com.example", "mytag.region", "mytag.area");}}

Meterics Endpoint

Spring Boot 提供了一个指标端点，可用于诊断检查应用程序收集的指标，但该端点默认不可用，必须进行配置。
查看可用指标列表：访问/actuator/metrics可以显示可用的指标名称列表。
查看特定指标信息：可以通过提供指标名称作为选择器来深入查看特定指标的信息，例如/actuator/metrics/jvm.memory.max。这里使用的名称应该与代码中使用的名称匹配，而不是为了适应监控系统命名约定而规范化后的名称。比如在 Prometheus 中jvm.memory.max可能会按照蛇形命名法显示为jvm_memory_max，但在指标端点中检查指标时，仍应使用jvm.memory.max作为选择器。
通过标签进一步筛选指标：还可以在 URL 末尾添加任意数量的tag=KEY:VALUE查询参数来按维度深入查看某个指标，例如/actuator/metrics/jvm.memory.max?tag=area:nonheap。报告的测量结果是所有与指标名称和已应用的任何标签匹配的指标统计信息的总和。
- 如上述示例中，返回的 “Value” 统计信息是堆的 “Code Cache”“Compressed Class Space” 和 “Metaspace” 区域的最大内存占用之和。
- 如果只想查看 “Metaspace” 的最大大小，可以添加额外的tag=id:Metaspace，即/actuator/metrics/jvm.memory.max?tag=area:nonheap&tag=id:Metaspace。

Tracing

Spring Boot 为以下两种追踪器工具提供自动配置：

基于 OpenTelemetry 的追踪器

Spring Boot 能够对基于 OpenTelemetry 的追踪器进行自动配置，并且这些追踪器可以与 Zipkin、Wavefront 或者 OTLP（OpenTelemetry Protocol）集成。

Zipkin：是一个开源的分布式追踪系统，可帮助收集和分析微服务架构中请求的追踪数据，了解请求在各个服务间的调用链路和性能情况。
Wavefront：是一个专注于大规模指标数据监控和分析的平台，支持对追踪数据的处理和可视化，能帮助用户深入洞察分布式系统的性能。
OTLP：是 OpenTelemetry 项目中的数据传输协议，确保追踪数据在不同组件间高效、可靠地传输。

基于 OpenZipkin Brave 的追踪器

Spring Boot 也支持对基于 OpenZipkin Brave 的追踪器进行自动配置，这些追踪器可以与 Zipkin 或 Wavefront 集成。OpenZipkin Brave 是一个轻量级的分布式追踪库，用于在应用程序中实现追踪功能，与上述的 Zipkin 和 Wavefront 集成后，可将追踪数据发送到相应的平台进行分析和展示。

追踪器实现

由于 Micrometer Tracer 支持多种跟踪器实现，因此 Spring Boot 可以实现多种依赖项组合。

所有跟踪器实现都需要org.springframework.boot:spring-boot-starter-actuator依赖。

OpenTelemetry 与 Zipkin

使用 OpenTelemetry 进行跟踪并向 Zipkin 报告需要以下依赖项：

io.micrometer:micrometer-tracing-bridge-otel- 将 Micrometer Observation API 连接至 OpenTelemetry。
io.opentelemetry:opentelemetry-exporter-zipkin- 向 Zipkin 报告跟踪。

使用management.zipkin.tracing.*配置属性来配置向 Zipkin 的报告。

OpenTelemetry 与 Wavefront

使用 OpenTelemetry 进行跟踪并向 Wavefront 报告需要以下依赖项：

io.micrometer:micrometer-tracing-bridge-otel- 将 Micrometer Observation API 连接至 OpenTelemetry。
io.micrometer:micrometer-tracing-reporter-wavefront- 向 Wavefront 报告跟踪。

使用management.wavefront.*配置属性来配置向 Wavefront 的报告。

使用 OTLP 的 OpenTelemetry

使用 OpenTelemetry 进行跟踪并使用 OTLP 进行报告需要以下依赖项：

io.micrometer:micrometer-tracing-bridge-otel- 将 Micrometer Observation API 连接至 OpenTelemetry。
io.opentelemetry:opentelemetry-exporter-otlp- 将跟踪报告给可以接受 OTLP 的收集器。

使用management.otlp.tracing.*配置属性来使用 OTLP 配置报告。

OpenZipkin Brave 与 Zipkin

使用 OpenZipkin Brave 进行跟踪并向 Zipkin 报告需要以下依赖项：

io.micrometer:micrometer-tracing-bridge-brave- 将 Micrometer Observation API 连接至 Brave。
io.zipkin.reporter2:zipkin-reporter-brave- 向 Zipkin 报告跟踪。

使用management.zipkin.tracing.*配置属性来配置向 Zipkin 的报告。

OpenZipkin Brave 与 Wavefront

使用 OpenZipkin Brave 进行跟踪并向 Wavefront 报告需要以下依赖项：

io.micrometer:micrometer-tracing-bridge-brave- 将 Micrometer Observation API 连接至 Brave。
io.micrometer:micrometer-tracing-reporter-wavefront- 向 Wavefront 报告跟踪。

使用management.wavefront.*配置属性来配置向 Wavefront 的报告。