Spring Boot 包含许多附加功能，可帮助您在将应用程序推送到生产环境时对其进行监控和管理。您可以选择使用 HTTP 端点或 JMX 来管理和监视您的应用程序。审计、健康和指标收集也可以自动应用于您的应用程序。

1. 启用生产就绪功能

该spring-boot-actuator模块提供了 Spring Boot 的所有生产就绪功能。​​spring-boot-starter-actuator​​启用这些功能的推荐方法是添加对“Starter”的依赖。

执行器的定义

致动器是一个制造术语，指的是用于移动或控制某物的机械装置。执行器可以通过微小的变化产生大量的运动。

要将执行器添加到基于 Maven 的项目中，请添加以下“Starter”依赖项：

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>
</dependencies>

对于 Gradle，使用以下声明：

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-actuator'
}

2. 端点

执行器端点使您可以监视应用程序并与之交互。Spring Boot 包含许多内置端点，并允许您添加自己的端点。例如，​​health​​端点提供基本的应用程序健康信息。

您可以启用或禁用每个单独的端点并通过 HTTP 或 JMX 公开它们（使它们可以远程访问）。当端点被启用和公开时，它被认为是可用的。内置端点仅在可用时才会自动配置。大多数应用程序选择通过 HTTP 公开，其中端点的 ID 和前缀​​/actuator​​映射到 URL。例如，默认情况下，​​health​​端点映射到​​/actuator/health​​.

以下与技术无关的端点可用：

如果您的应用程序是 Web 应用程序（Spring MVC、Spring WebFlux 或 Jersey），您可以使用以下附加端点：

2.1启用端点

默认情况下，除了​​shutdown​​启用之外的所有端点。要配置端点的启用，请使用其​​management.endpoint.<id>.enabled​​属性。以下示例启用​​shutdown​​端点：

特性

management.endpoint.shutdown.enabled=true

如果您希望端点启用是选择加入而不是选择退出，请将​​management.endpoints.enabled-by-default​​属性设置为​​false​​并使用单个端点​​enabled​​属性来选择重新加入。以下示例启用​​info​​端点并禁用所有其他端点：

特性

management.endpoints.enabled-by-default=false
management.endpoint.info.enabled=true

2.2. 暴露端点

由于端点可能包含敏感信息，您应该仔细考虑何时公开它们。下表显示了内置端点的默认曝光：

要更改公开的端点，请使用以下技术特定​​include​​和​​exclude​​属性：

该​​include​​属性列出了公开的端点的 ID。该​​exclude​​属性列出不应公开的端点的 ID。​​exclude​​财产优先于财产​​include​​。您可以使用端点 ID 列表来配置​​include​​和​​exclude​​属性。

例如，要停止通过 JMX 公开所有端点并仅公开​​health​​和​​info​​端点，请使用以下属性：

特性

management.endpoints.jmx.exposure.include=health,info

​​*​​可用于选择所有端点。例如，要通过 HTTP 公开除​​env​​和​​beans​​端点之外的所有内容，请使用以下属性：

特性

management.endpoints.web.exposure.include=*
management.endpoints.web.exposure.exclude=env,beans

2.3. 安全

出于安全目的，​​/health​​​默认情况下只有端点通过 HTTP 公开。您可以使用该​​management.endpoints.web.exposure.include​​属性来配置公开的端点。

如果 Spring Security 在类路径上并且不存在其他​​WebSecurityConfigurerAdapter​​​或​​SecurityFilterChain​​​bean，则除​​/health​​​Spring Boot 自动配置之外的所有执行器都受保护。如果您定义了自定义​​WebSecurityConfigurerAdapter​​​或​​SecurityFilterChain​​bean，Spring Boot 自动配置会退出并让您完全控制执行器访问规则。

如果您希望为 HTTP 端点配置自定义安全性（例如，只允许具有特定角色的用户访问它们），Spring Boot 提供了一些方便​​RequestMatcher​​的对象，您可以将它们与 Spring Security 结合使用。

典型的 Spring Security 配置可能类似于以下示例：

@Configuration(proxyBeanMethods = false)
public class MySecurityConfiguration {

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http.requestMatcher(EndpointRequest.toAnyEndpoint());
        http.authorizeRequests((requests) -> requests.anyRequest().hasRole("ENDPOINT_ADMIN"));
        http.httpBasic(withDefaults());
        return http.build();
    }

}

前面的示例用于​​EndpointRequest.toAnyEndpoint()​​将请求匹配到任何端点，然后确保所有端点都具有​​ENDPOINT_ADMIN​​角色。其他几种匹配器方法也可以在​​EndpointRequest​​. 有关详细信息，请参阅 API 文档（HTML或PDF）。

如果您在防火墙后面部署应用程序，您可能希望无需身份验证即可访问所有执行器端点。您可以通过更改属性来做到这一点​​management.endpoints.web.exposure.include​​，如下所示：

特性

management.endpoints.web.exposure.include=*

此外，如果存在 Spring Security，您将需要添加自定义安全配置，以允许未经身份验证的访问端点，如以下示例所示：

@Configuration(proxyBeanMethods = false)
public class MySecurityConfiguration {

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http.requestMatcher(EndpointRequest.toAnyEndpoint());
        http.authorizeRequests((requests) -> requests.anyRequest().permitAll());
        return http.build();
    }

}

2.3.1跨站点请求伪造保护

由于 Spring Boot 依赖于 Spring Security 的默认设置，因此默认开启 CSRF 保护。这意味着在使用默认安全配置时，需要​​POST​​（关闭和记录器端点）、a​​PUT​​或 a的执行器端点​​DELETE​​会收到 403（禁止）错误。

您可以在Spring Security Reference Guide中找到有关 CSRF 保护的更多信息。

2.4. 配置端点

端点会自动缓存对不带任何参数的读取操作的响应。要配置端点缓存响应的时间量，请使用其​​cache.time-to-live​​属性。以下示例将​​beans​​端点缓存的生存时间设置为 10 秒：

特性

management.endpoint.beans.cache.time-to-live=10s

2.5. Actuator Web 端点的超媒体

添加了一个“发现页面”，其中包含指向所有端点的链接。默认情况下，“发现页面”可用​​/actuator​​。

要禁用“发现页面”，请将以下属性添加到您的应用程序属性中：

特性

management.endpoints.web.discovery.enabled=false

配置自定义管理上下文路径后，“发现页面”会自动从​​/actuator​​管理上下文的根目录移动。例如，如果管理上下文路径是​​/management​​，则发现页面可从​​/management​​。当管理上下文路径设置为​​/​​时，发现页面被禁用以防止与其他映射发生冲突的可能性。

2.6. CORS 支持

跨域资源共享(CORS) 是一种W3C 规范，可让您以灵活的方式指定授权哪种跨域请求。如果您使用 Spring MVC 或 Spring WebFlux，则可以配置 Actuator 的 Web 端点以支持此类场景。

CORS 支持默认禁用，只有在您设置了​​management.endpoints.web.cors.allowed-origins​​属性后才会启用。以下配置允许​​GET​​和来自域​​POST​​的调用：​​example.com​​

特性

management.endpoints.web.cors.allowed-origins=https://example.com
management.endpoints.web.cors.allowed-methods=GET,POST

2.7. 实施自定义端点

如果您添加带有​​@Bean​​注释的​​@Endpoint​​任何方法，那么任何带有​​@ReadOperation​​、​​@WriteOperation​​或注释的方法都会​​@DeleteOperation​​自动通过 JMX 公开，并且在 Web 应用程序中，也会通过 HTTP 公开。可以使用 Jersey、Spring MVC 或 Spring WebFlux 通过 HTTP 公开端点。如果 Jersey 和 Spring MVC 都可用，则使用 Spring MVC。

以下示例公开了一个返回自定义对象的读取操作：

@ReadOperation
public CustomData getData() {
    return new CustomData("test", 5);
}

​​@JmxEndpoint​​您还可以使用或编写特定于技术的端点​​@WebEndpoint​​。这些端点仅限于各自的技术。例如，​​@WebEndpoint​​仅通过 HTTP 而不是通过 JMX 公开。

​​@EndpointWebExtension​​您可以使用和编写特定于技术的扩展​​@EndpointJmxExtension​​。这些注释让您可以提供特定于技术的操作来扩充现有端点。

最后，如果您需要访问特定于 web 框架的功能，您可以实现 servlet 或 Spring​​@Controller​​和​​@RestController​​端点，但代价是它们无法通过 JMX 或使用不同的 web 框架。

2.7.1接收输入

端点上的操作通过其参数接收输入。当通过 Web 公开时，这些参数的值取自 URL 的查询参数和 JSON 请求正文。通过 JMX 公开时，参数将映射到 MBean 操作的参数。默认情况下需要参数。​​@javax.annotation.Nullable​​可以通过使用或注释它们来使它们成为可选的​​@org.springframework.lang.Nullable​​。

您可以将 JSON 请求正文中的每个根属性映射到端点的参数。考虑以下 JSON 请求正文：

{
    "name": "test",
    "counter": 42
}

您可以使用它来调用接受​​String name​​和​​int counter​​参数的写入操作，如以下示例所示：

@WriteOperation
public void updateData(String name, int counter) {
    // injects "test" and 42
}

2.7. 实施自定义端点

如果您添加带有​​@Bean​​注释的​​@Endpoint​​任何方法，那么任何带有​​@ReadOperation​​、​​@WriteOperation​​或注释的方法都会​​@DeleteOperation​​自动通过 JMX 公开，并且在 Web 应用程序中，也会通过 HTTP 公开。可以使用 Jersey、Spring MVC 或 Spring WebFlux 通过 HTTP 公开端点。如果 Jersey 和 Spring MVC 都可用，则使用 Spring MVC。

以下示例公开了一个返回自定义对象的读取操作：

@ReadOperation
public CustomData getData() {
    return new CustomData("test", 5);
}

​​@JmxEndpoint​​您还可以使用或编写特定于技术的端点​​@WebEndpoint​​。这些端点仅限于各自的技术。例如，​​@WebEndpoint​​仅通过 HTTP 而不是通过 JMX 公开。

​​@EndpointWebExtension​​您可以使用和编写特定于技术的扩展​​@EndpointJmxExtension​​。这些注释让您可以提供特定于技术的操作来扩充现有端点。

最后，如果您需要访问特定于 web 框架的功能，您可以实现 servlet 或 Spring​​@Controller​​和​​@RestController​​端点，但代价是它们无法通过 JMX 或使用不同的 web 框架。

2.7.1接收输入

端点上的操作通过其参数接收输入。当通过 Web 公开时，这些参数的值取自 URL 的查询参数和 JSON 请求正文。通过 JMX 公开时，参数将映射到 MBean 操作的参数。默认情况下需要参数。​​@javax.annotation.Nullable​​可以通过使用或注释它们来使它们成为可选的​​@org.springframework.lang.Nullable​​。

您可以将 JSON 请求正文中的每个根属性映射到端点的参数。考虑以下 JSON 请求正文：

{
    "name": "test",
    "counter": 42
}

您可以使用它来调用接受​​String name​​和​​int counter​​参数的写入操作，如以下示例所示：

@WriteOperation
public void updateData(String name, int counter) {
    // injects "test" and 42
}

网络端点安全

Web 端点或特定于 Web 的端点扩展上的操作可以接收当前参数​​java.security.Principal​​或​​org.springframework.boot.actuate.endpoint.SecurityContext​​方法参数。前者通常与 结合使用，为经过​​@Nullable​​身份验证和未经身份验证的用户提供不同的行为。后者通常用于通过使用其​​isUserInRole(String)​​方法执行授权检查。

2.7.3. Servlet 端点

servlet 可以通过实现一个带有注释的类来公开为端点，该类​​@ServletEndpoint​​也实现了​​Supplier<EndpointServlet>​​. Servlet 端点提供与 servlet 容器的更深层次的集成，但以牺牲可移植性为代价。它们旨在用于将现有 servlet 公开为端点。对于新端点，应尽可能首选​​@Endpoint​​和注释。​​@WebEndpoint​​

2.7.4. 控制器端点

您可以使用​​@ControllerEndpoint​​和​​@RestControllerEndpoint​​实现仅由 Spring MVC 或 Spring WebFlux 公开的端点。通过使用 Spring MVC 和 Spring WebFlux 的标准注释来映射方法，例如​​@RequestMapping​​和​​@GetMapping​​，端点的 ID 用作路径的前缀。控制器端点提供与 Spring 的 Web 框架的更深层次的集成，但以牺牲可移植性为代价。应尽可能首选​​@Endpoint​​and注释。​​@WebEndpoint​​

2.8. 健康信息

您可以使用健康信息来检查正在运行的应用程序的状态。当生产系统出现故障时，监控软件经常使用它来提醒某人。端点公开的信息​​health​​取决于​​management.endpoint.health.show-details​​和​​management.endpoint.health.show-components​​属性，可以使用以下值之一进行配置：

默认值为​​never​​。当用户处于一个或多个端点角色时，他们被认为是被授权的。如果端点没有配置角色（默认），则所有经过身份验证的用户都被认为是授权的。您可以使用该​​management.endpoint.health.roles​​属性来配置角色。

健康信息是从 a 的内容中收集的HealthContributorRegistry​（默认情况下，HealthContributor​您的 中定义的所有实例​​ApplicationContext​​​）。Spring Boot 包含了一些自动配置的​​HealthContributors​​，你也可以自己编写。

A​​HealthContributor​​可以是 a​​HealthIndicator​​或 a ​​CompositeHealthContributor​​。A​​HealthIndicator​​提供实际的健康信息，包括​​Status​​. A​​CompositeHealthContributor​​提供了 other 的组合​​HealthContributors​​。总之，贡献者形成了一个树结构来表示整个系统的健康状况。

默认情况下，最终系统运行状况由 a 派生，它根据状态的有序列表对​​StatusAggregator​​每个状态进行排序。​​HealthIndicator​​排序列表中的第一个状态用作整体健康状态。如果 no​​HealthIndicator​​返回 已知​​StatusAggregator​​的​​UNKNOWN​​状态，则使用状态。

2.8.1. 自动配置的健康指标

在适当的时候，Spring Boot 会自动配置​​HealthIndicators​​下表中列出的内容。您也可以通过配置启用或禁用选定的指标​​management.health.key.enabled​​，​​key​​如下表所示：

其他​​HealthIndicators​​可用但默认情况下未启用：

2.8.2. 编写自定义健康指标

要提供自定义健康信息，您可以注册实现该HealthIndicator接口的 Spring bean。您需要提供该​​health()​​方法的实现并返回​​Health​​响应。​​Health​​响应应包含状态，并且可以选择包含要显示的其他详细信息。以下代码显示了一个示例​​HealthIndicator​​实现：

@Component
public class MyHealthIndicator implements HealthIndicator {

    @Override
    public Health health() {
        int errorCode = check();
        if (errorCode != 0) {
            return Health.down().withDetail("Error Code", errorCode).build();
        }
        return Health.up().build();
    }

    private int check() {
        // perform some specific health check
        return ...
    }

}

除了 Spring Boot 的预定义Status​类型之外，​​Health​​​还可以返回一个​​Status​​​表示新系统状态的自定义。在这种情况下，您还需要提供StatusAggregator​接口的自定义实现，或者您必须使用​​management.endpoint.health.status.order​​配置属性配置默认实现。

例如，假设在您的一个实现中使用​​Status​​了代码为的 new 。要配置严重性顺序，请将以下属性添加到您的应用程序属性中：​​FATAL​​​​HealthIndicator​​

特性

management.endpoint.health.status.order=fatal,down,out-of-service,unknown,up

响应中的 HTTP 状态代码反映了整体健康状况。默认情况下，​​OUT_OF_SERVICE​​映射​​DOWN​​到 503。任何未映射的健康状态，包括​​UP​​，都映射到 200。如果您通过 HTTP 访问健康端点，您可能还需要注册自定义状态映射。配置自定义映射会禁用 和 的默认​​DOWN​​映射​​OUT_OF_SERVICE​​。如果要保留默认映射，则必须显式配置它们以及任何自定义映射。例如，以下属性映射​​FATAL​​到 503（服务不可用）并保留 和 的默认​​DOWN​​映射​​OUT_OF_SERVICE​​：

特性

management.endpoint.health.status.http-mapping.down=503
management.endpoint.health.status.http-mapping.fatal=503
management.endpoint.health.status.http-mapping.out-of-service=503

下表显示了内置状态的默认状态映射：

2.8.3. 反应性健康指标

对于响应式应用程序，例如使用 Spring WebFlux 的应用程序，​​ReactiveHealthContributor​​提供了一个非阻塞契约来获取应用程序健康。与传统的 类似​​HealthContributor​​，健康信息是从 a 的内容中收集的ReactiveHealthContributorRegistry（默认情况下， allHealthContributor和ReactiveHealthContributor您的 中定义的实例​​ApplicationContext​​）。​​HealthContributors​​不检查响应式 API 的常规在弹性调度程序上执行。

要从反应式 API 提供自定义健康信息，您可以注册实现该ReactiveHealthIndicator​接口的 Spring bean。以下代码显示了一个示例​​ReactiveHealthIndicator​​实现：

@Component
public class MyReactiveHealthIndicator implements ReactiveHealthIndicator {

    @Override
    public Mono<Health> health() {
        return doHealthCheck().onErrorResume((exception) ->
            Mono.just(new Health.Builder().down(exception).build()));
    }

    private Mono<Health> doHealthCheck() {
        // perform some specific health check
        return ...
    }

}

2.8.4自动配置的 ReactiveHealthIndicators

在适当的时候，Spring Boot 会自动配置以下内容​​ReactiveHealthIndicators​​：

2.8.5健康团体

有时将健康指标组织成可用于不同目的的组很有用。

要创建运行状况指标组，您可以使用该​​management.endpoint.health.group.<name>​​属性并将运行状况指标 ID 列表指定为​​include​​或​​exclude​​。例如，要创建仅包含数据库指标的组，您可以定义以下内容：

特性

management.endpoint.health.group.custom.include=db

然后，您可以通过点击 来检查结果​​localhost:8080/actuator/health/custom​​。

同样，要创建一个从组中排除数据库指标并包含所有其他指标的组，您可以定义以下内容：

特性

management.endpoint.health.group.custom.exclude=db

默认情况下，组继承与系统运行状况相同​​StatusAggregator​​的​​HttpCodeStatusMapper​​设置。但是，您也可以在每个组的基础上定义这些。如果需要，您还可以覆盖​​show-details​​and​​roles​​属性：

特性

management.endpoint.health.group.custom.show-details=when-authorized
management.endpoint.health.group.custom.roles=admin
management.endpoint.health.group.custom.status.order=fatal,up
management.endpoint.health.group.custom.status.http-mapping.fatal=500
management.endpoint.health.group.custom.status.http-mapping.out-of-service=500

健康组还可以包括/排除​​CompositeHealthContributor​​​. 您还可以仅包含/排除​​CompositeHealthContributor​​. 这可以使用组件的完全限定名称来完成，如下所示：

management.endpoint.health.group.custom.include="test/primary"
management.endpoint.health.group.custom.exclude="test/primary/b"

在上面的示例中，​​custom​​组将包含​​HealthContributor​​名称​​primary​​为组合的组件​​test​​。在这里，​​primary​​它本身是一个组合，​​HealthContributor​​具有该名称的​​b​​将被排除在​​custom​​组之外。

可以在主端口或管理端口上的附加路径上提供运行状况组。这在 Kubernetes 等云环境中很有用，在这些环境中，出于安全目的，为执行器端点使用单独的管理端口是很常见的。拥有一个单独的端口可能会导致不可靠的健康检查，因为即使健康检查成功，主应用程序也可能无法正常工作。可以为健康组配置额外的路径，如下所示：

management.endpoint.health.group.live.additional-path="server:/healthz"

这将使​​live​​健康组在主服务器端口上可用​​/healthz​​。前缀是强制性的，必须是​​server:​​（表示主服务器端口）或​​management:​​（表示管理端口，如果已配置）。路径必须是单个路径段。

2.8.6数据源运行状况

​​DataSource​​运行状况指示器显示标准数据源和路由数据源 bean 的运行状况。路由数据源的健康状况包括其每个目标数据源的健康状况。在健康端点的响应中，每个路由数据源的目标都使用其路由键命名。如果您不想在指标的输出中包含路由数据源，请设置​​management.health.db.ignore-routing-data-sources​​为​​true​​。

2.9Kubernetes 探针

部署在 Kubernetes 上的应用程序可以通过Container Probes提供有关其内部状态的信息。根据您的 Kubernetes 配置，kubelet 会调用这些探测器并对结果做出反应。

默认情况下，Spring Boot 管理您的应用程序可用性状态。如果部署在 Kubernetes 环境中，actuator 从​​ApplicationAvailability​​接口收集“Liveness”和“Readiness”信息，并在专用的健康指标中使用该信息：​​LivenessStateHealthIndicator​​和​​ReadinessStateHealthIndicator​​。这些指标显示在全球健康端点 ( ​​"/actuator/health"​​) 上。它们还通过使用健康组:​​"/actuator/health/liveness"​​和​​"/actuator/health/readiness"​​.

然后，您可以使用以下端点信息配置 Kubernetes 基础架构：

livenessProbe:
  httpGet:
    path: "/actuator/health/liveness"
    port: <actuator-port>
  failureThreshold: ...
  periodSeconds: ...

readinessProbe:
  httpGet:
    path: "/actuator/health/readiness"
    port: <actuator-port>
  failureThreshold: ...
  periodSeconds: ...

只有当应用程序在 Kubernetes 环境中运行时，这些健康组才会自动启用。您可以使用​​management.endpoint.health.probes.enabled​​配置属性在任何环境中启用它们。

如果您的 Actuator 端点部署在单独的管理上下文中，则端点不会使用与主应用程序相同的 Web 基础设施（端口、连接池、框架组件）。在这种情况下，即使主应用程序无法正常工作（例如，它不能接受新连接），探测检查也可能会成功。出于这个原因，让主服务器端口上的​​liveness​​​和健康组可用是一个好主意。​​readiness​​这可以通过设置以下属性来完成：

management.endpoint.health.probes.add-additional-paths=true

这将在主服务器端口上可用​​liveness​​。​​/livez​​​​readiness​​​​readyz​​

2.9.1使用 Kubernetes 探针检查外部状态

Actuator 将“liveness”和“readiness”探针配置为 Health Groups。这意味着他们可以使用所有健康组功能。例如，您可以配置其他运行状况指标：

特性

management.endpoint.health.group.readiness.include=readinessState,customCheck

默认情况下，Spring Boot 不会向这些组添加其他健康指标。

“活跃度”探测不应依赖于外部系统的健康检查。如果应用程序的活跃状态被破坏，Kubernetes 会尝试通过重新启动应用程序实例来解决该问题。这意味着如果外部系统（例如数据库、Web API 或外部缓存）发生故障，Kubernetes 可能会重新启动所有应用程序实例并产生级联故障。

至于“就绪”探测，应用程序开发人员必须仔细选择检查外部系统。出于这个原因，Spring Boot 在就绪探测中不包括任何额外的健康检查。如果应用程序实例的就绪状态未准备好，Kubernetes 不会将流量路由到该实例。某些外部系统可能不被应用程序实例共享，在这种情况下，它们可以包含在就绪探测中。其他外部系统可能对应用程序不是必需的（应用程序可能有断路器和回退），在这种情况下，它们绝对不应该包括在内。不幸的是，所有应用程序实例共享的外部系统是常见的，您必须做出判断：将其包含在就绪探针中，并期望在外部服务关闭时应用程序停止服务或将其排除在外并处理堆栈更高的故障，也许通过在调用者中使用断路器。

此外，如果应用程序使用 Kubernetes自动缩放，它可能会对从负载均衡器中取出的应用程序做出不同的反应，具体取决于其自动缩放器配置。

2.9.2. 应用程序生命周期和探测状态

Kubernetes Probes 支持的一个重要方面是它与应用程序生命周期的一致性。​​AvailabilityState​​（这是应用程序的内存中的内部状态）和实际的探针（暴露该状态）之间存在显着差异。根据应用程序生命周期的阶段，探针可能不可用。

Spring Boot在启动和关闭期间发布应用程序事件，探针可以监听此类事件并公开​​AvailabilityState​​信息。

下表显示了​​AvailabilityState​​HTTP 连接器在不同阶段的状态。

当 Spring Boot 应用程序启动时：

当 Spring Boot 应用程序关闭时：

2.10应用信息

InfoContributor应用程序信息公开了从您定义的所有 bean收集的各种信息​​ApplicationContext​​。Spring Boot 包含许多自动配置的​​InfoContributor​​bean，您可以编写自己的。

2.10.1自动配置的 InfoContributors

在适当的时候，Spring 会自动配置以下​​InfoContributor​​bean：

是否启用单个贡献者由其​​management.info.<id>.enabled​​属性控制。不同的贡献者对此属性有不同的默认值，这取决于他们的先决条件和他们公开的信息的性质。

没有先决条件表明它们应该被启用，默认情况下禁用​​env​​、​​java​​和贡献者。​​os​​每个都可以通过将其​​management.info.<id>.enabled​​属性设置为 来启用​​true​​。

和​​build​​info​​git​​贡献者默认启用。每个都可以通过将其​​management.info.<id>.enabled​​属性设置为 来禁用​​false​​。或者，要禁用通常默认启用的每个贡献者，请将​​management.info.defaults.enabled​​属性设置为​​false​​.

2.10.2自定义应用程序信息

启用贡献者后​​env​​，您可以通过设置Spring 属性来自定义​​info​​端点公开的数据。​​info.*​​键下的所有​​Environment​​属性都会​​info​​自动公开。例如，您可以将以下设置添加到​​application.properties​​文件中：

特性

info.app.encoding=UTF-8
info.app.java.source=11
info.app.java.target=11

2.10.3Git 提交信息

端点的另一个有用特性是它能够在项目构建时​​info​​​发布有关源代码存储库状态的信息。​​git​​​如果​​GitProperties​​​bean 可用，您可以使用​​info​​端点来公开这些属性。

默认情况下，端点公开​​git.branch​​​、​​git.commit.id​​​和​​git.commit.time​​​属性（如果存在）。如果您不希望端点响应中有任何这些属性，则需要将它们从​​git.properties​​​文件中排除。如果要显示完整的 git 信息（即 的完整内容​​git.properties​​​），使用​​management.info.git.mode​​属性，如下：

特性

management.info.git.mode=full

​​info​​要完全禁用来自端点的 git 提交信息，请将​​management.info.git.enabled​​属性设置为​​false​​，如下所示：

特性

management.info.git.enabled=false

2.10.4构建信息

如果​​BuildProperties​​bean 可用，​​info​​端点还可以发布有关您的构建的信息。如果​​META-INF/build-info.properties​​类路径中有文件可用，则会发生这种情况。

2.10.5Java 信息

​​info​​端点发布有关您的 Java 运行时环境的信息，请参阅了解JavaInfo更多详细信息。

2.10.6操作系统信息

​​info​​端点发布有关您的操作系统的信息，有关更多详细信息，请参阅OsInfo。

2.10.7编写自定义信息贡献者

要提供自定义应用程序信息，您可以注册实现该InfoContributor接口的 Spring bean。

以下示例提供​​example​​具有单个值的条目：

@Component
public class MyInfoContributor implements InfoContributor {

    @Override
    public void contribute(Info.Builder builder) {
        builder.withDetail("example", Collections.singletonMap("key", "value"));
    }

}

如果您到达​​info​​端点，您应该会看到包含以下附加条目的响应：

{
    "example": {
        "key" : "value"
    }
}

3. 通过 HTTP 进行监控和管理

如果您正在开发 Web 应用程序，Spring Boot Actuator 会自动配置所有启用的端点以通过 HTTP 公开。默认约定是使用​​id​​带有前缀的端点的​​/actuator​​作为 URL 路径。例如，​​health​​公开为​​/actuator/health​​.

3.1自定义管理端点路径

有时，自定义管理端点的前缀很有用。例如，您的应用程序可能已经​​/actuator​​用于其他目的。您可以使用该​​management.endpoints.web.base-path​​属性更改管理端点的前缀，如以下示例所示：

特性

management.endpoints.web.base-path=/manage

前面的​​application.properties​​示例将端点从更改​​/actuator/{id}​​为​​/manage/{id}​​（例如，​​/manage/info​​）。

如果要将端点映射到不同的路径，可以使用该​​management.endpoints.web.path-mapping​​属性。

以下示例重新映射​​/actuator/health​​到​​/healthcheck​​：

特性

management.endpoints.web.base-path=/
management.endpoints.web.path-mapping.health=healthcheck

3.2. 自定义管理服务器端口

使用默认 HTTP 端口公开管理端点是基于云的部署的明智选择。但是，如果您的应用程序在您自己的数据中心内运行，您可能更愿意使用不同的 HTTP 端口来公开端点。

您可以设置该​​management.server.port​​属性以更改 HTTP 端口，如以下示例所示：

特性

management.server.port=8081

3.3. 配置特定于管理的 SSL

​​management.server.ssl.*​​当配置为使用自定义端口时，您还可以使用各种属性为管理服务器配置自己的 SSL 。例如，这样做可以让管理服务器在主应用程序使用 HTTPS 时通过 HTTP 可用，如以下属性设置所示：

特性

server.port=8443
server.ssl.enabled=true
server.ssl.key-store=classpath:store.jks
server.ssl.key-password=secret
management.server.port=8080
management.server.ssl.enabled=false

或者，主服务器和管理服务器都可以使用 SSL，但使用不同的密钥存储，如下所示：

特性

server.port=8443
server.ssl.enabled=true
server.ssl.key-store=classpath:main.jks
server.ssl.key-password=secret
management.server.port=8080
management.server.ssl.enabled=true
management.server.ssl.key-store=classpath:management.jks
management.server.ssl.key-password=secret

3.4. 自定义管理服务器地址

​​management.server.address​​您可以通过设置属性来自定义管理端点可用的地址。如果您只想在内部或面向操作的网络上侦听或仅侦听来自​​localhost​​.

以下示例​​application.properties​​不允许远程管理连接：

特性

yaml

management.server.port=8081
management.server.address=127.0.0.1

3.5. 禁用 HTTP 端点

如果您不想通过 HTTP 公开端点，可以将管理端口设置为​​-1​​，如以下示例所示：

特性

yaml

management.server.port=-1

您也可以通过使用该​​management.endpoints.web.exposure.exclude​​属性来实现此目的，如以下示例所示：

特性

yaml

management.endpoints.web.exposure.exclude=*

4. JMX上的监控和管理

Java 管理扩展 (JMX) 提供了一种标准机制来监视和管理应用程序。默认情况下，此功能未启用。​​spring.jmx.enabled​​您可以通过将配置属性设置为 来打开它​​true​​。Spring Boot 公开了最适合​​MBeanServer​​的 bean，ID 为​​mbeanServer​​. 使用 Spring JMX 注释（、、或）注释的任何 bean 都会​​@ManagedResource​​暴露​​@ManagedAttribute​​给​​@ManagedOperation​​它。

如果您的平台提供了标准，Spring Boot 会使用该标准并在必要时​​MBeanServer​​默认使用 VM 。​​MBeanServer​​如果这一切都失败了，​​MBeanServer​​则会创建一个新的。

有关更多详细信息，请参阅JmxAutoConfiguration课程。

默认情况下，Spring Boot 还将管理端点公开为​​org.springframework.boot​​域下的 JMX MBean。要完全控制 JMX 域中的端点注册，请考虑注册您自己的​​EndpointObjectNameFactory​​实现。

4.1自定义 MBean 名称

MBean 的名称通常是从​​id​​端点生成的。例如，​​health​​端点公开为​​org.springframework.boot:type=Endpoint,name=Health​​.

如果您的应用程序包含多个 Spring ​​ApplicationContext​​，您可能会发现名称冲突。要解决此问题，您可以将​​spring.jmx.unique-names​​属性设置为，​​true​​以便 MBean 名称始终是唯一的。

您还可以自定义在其下公开端点的 JMX 域。以下设置显示了这样做的示例​​application.properties​​：

特性

spring.jmx.unique-names=true
management.endpoints.jmx.domain=com.example.myapp

4.2. 禁用 JMX 端点

如果您不想通过 JMX 公开端点，可以将​​management.endpoints.jmx.exposure.exclude​​属性设置为​​*​​，如以下示例所示：

特性

management.endpoints.jmx.exposure.exclude=*

4.3. 将 Jolokia 用于基于 HTTP 的 JMX

Jolokia 是一个 JMX-HTTP 桥，它提供了另一种访问 JMX bean 的方法。要使用 Jolokia，请包含对​​org.jolokia:jolokia-core​​. 例如，使用 Maven，您将添加以下依赖项：

<dependency>
    <groupId>org.jolokia</groupId>
    <artifactId>jolokia-core</artifactId>
</dependency>

然后，您可以通过向属性添加​​jolokia​​或​​*​​来公开 Jolokia 端点。然后，您可以在管理 HTTP 服务器上​​management.endpoints.web.exposure.include​​使用它来访问它。​​/actuator/jolokia​​

4.3.1。自定义 Jolokia

Jolokia 有许多设置，您通常可以通过设置 servlet 参数来配置这些设置。使用 Spring Boot，您可以使用您的​​application.properties​​文件。为此，请在参数前加上​​management.endpoint.jolokia.config.​​，如以下示例所示：

特性

management.endpoint.jolokia.config.debug=true

4.3.2. 禁用 Jolokia

如果您使用 Jolokia 但不想让 Spring Boot 配置它，请将​​management.endpoint.jolokia.enabled​​属性设置为​​false​​，如下所示：

特性

management.endpoint.jolokia.enabled=false

5. 记录器

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

• ​​TRACE​​
• ​​DEBUG​​
• ​​INFO​​
• ​​WARN​​
• ​​ERROR​​
• ​​FATAL​​
• ​​OFF​​
• ​​null​​

​​null​​表示没有显式配置。

5.1配置记录器

要配置给定的记录器，​​POST​​即资源 URI 的部分实体，如以下示例所示：

{
    "configuredLevel": "DEBUG"
}

6. 指标

Spring Boot Actuator 为Micrometer提供依赖管理和自动配置，这是一个支持众多监控系统的应用程序指标外观，包括：

• 应用光学
• 阿特拉斯
• 数据狗
• 动态追踪
• 松紧带
• 神经节
• 石墨
• 胡米奥
• 涌入
• JMX
• 凯罗斯数据库
• 新遗物
• 普罗米修斯
• 信号效果
• 简单（内存中）
• 堆栈驱动程序
• 统计数据
• 波前

6.1入门

Spring Boot 自动配置一个组合​​MeterRegistry​​并为它在类路径上找到的每个受支持的实现添加一个注册表到组合中。在你的运行时类路径中有一个依赖就​​micrometer-registry-{system}​​足以让 Spring Boot 配置注册表。

大多数注册中心都有共同的特征。例如，即使 Micrometer 注册表实现在类路径上，您也可以禁用特定注册表。以下示例禁用 Datadog：

特性

management.metrics.export.datadog.enabled=false

除非特定于注册表的属性另有说明，否则您还可以禁用所有注册表，如以下示例所示：

特性

management.metrics.export.defaults.enabled=false

Spring Boot 还将任何自动配置的注册表添加到​​Metrics​​类上的全局静态复合注册表中，除非您明确告诉它不要：

特性

management.metrics.use-global-registry=false

您可以注册任意数量的​​MeterRegistryCustomizer​​bean 以进一步配置注册表，例如应用通用标签，然后再向注册表注册任何计量器：

@Configuration(proxyBeanMethods = false)
public class MyMeterRegistryConfiguration {

    @Bean
    public MeterRegistryCustomizer<MeterRegistry> metricsCommonTags() {
        return (registry) -> registry.config().commonTags("region", "us-east-1");
    }

}

您可以通过更具体地了解泛型类型来将自定义应用于特定的注册表实现：​

Spring Boot 还配置了您可以通过配置或专用注释标记控制的内置检测。

6.2. 支持的监控系统

本节简要介绍了每个受支持的监控系统。

6.2.1. 应用光学

默认情况下，AppOptics 注册表会定期将指标推送到​​api.appoptics.com/v1/measurements​​. 要将指标导出到 SaaS AppOptics，必须提供您的 API 令牌：

特性

management.metrics.export.appoptics.api-token=YOUR_TOKEN

6.2.2. 阿特拉斯

默认情况下，指标会导出到在本地计算机上运行的Atlas 。您可以提供Atlas 服务器的位置：

特性

management.metrics.export.atlas.uri=https://atlas.example.com:7101/api/v1/publish

6.2.3. 数据狗

Datadog 注册表会定期将指标推送到datadoghq。要将指标导出到Datadog，您必须提供您的 API 密钥：

特性

management.metrics.export.datadog.api-key=YOUR_KEY

如果您另外提供应用程序密钥（可选），则还将导出计量描述、类型和基本单位等元数据：

特性

management.metrics.export.datadog.api-key=YOUR_API_KEY
management.metrics.export.datadog.application-key=YOUR_APPLICATION_KEY

默认情况下，指标会发送到 Datadog 美国站点( ​​api.datadoghq.com​​)。如果您的 Datadog 项目托管在其他站点之一上，或者您需要通过代理发送指标，请相应地配置 URI：

特性

management.metrics.export.datadog.uri=https://api.datadoghq.eu

您还可以更改将指标发送到 Datadog 的时间间隔：

特性

management.metrics.export.datadog.step=30s

6.2.4. 动态追踪

Dynatrace 提供了两个指标摄取 API，这两个 API 都是为Micrometer实现的。您可以在此处找到有关 Micrometer 指标摄取的 Dynatrace 文档。命名空间中的配置属性​​v1​​仅在导出到Timeseries v1 API时适用。命名空间中的配置属性​​v2​​仅在导出到Metrics v2 API时适用。请注意，此集成一次只能导出到API 的一个​​v1​​或版本，这是首选。如果在命名空间中设置了（v1 需要但在 v2 中未使用） ，则会将指标导出到端点。否则，假定。​​v2​​​​v2​​​​device-id​​​​v1​​​​v1​​​​v2​​

v2 API

您可以通过两种方式使用 v2 API。

自动配置

Dynatrace 自动配置可用于由 OneAgent 或 Dynatrace Operator for Kubernetes 监控的主机。

本地 OneAgent：如果 OneAgent 在主机上运行，​​指标会自动导出到本地 OneAgent 摄取端点。摄取端点将指标转发到 Dynatrace 后端。

Dynatrace Kubernetes Operator：在安装了 Dynatrace Operator 的 Kubernetes 中运行时，注册表将自动从 Operator 获取您的端点 URI 和 API 令牌。

这是默认行为，除了依赖于​​io.micrometer:micrometer-registry-dynatrace​​.

手动配置

如果没有可用的自动配置，则需要Metrics v2 API的端点和 API 令牌。API 令牌必须具有“摄取指标”( )​​metrics.ingest​​权限集。我们建议将令牌的范围限制为这一权限。您必须确保端点 URI 包含路径（例如，​​/api/v2/metrics/ingest​​）：

Metrics API v2 摄取端点的 URL 根据您的部署选项而有所不同：

• 软件即服务：https://{your-environment-id}.live.dynatrace.com/api/v2/metrics/ingest
• 托管部署：https://{your-domain}/e/{your-environment-id}/api/v2/metrics/ingest

下面的示例使用​​example​​环境 id 配置指标导出：

特性

management.metrics.export.dynatrace.uri=https://example.live.dynatrace.com/api/v2/metrics/ingest
management.metrics.export.dynatrace.api-token=YOUR_TOKEN

使用 Dynatrace v2 API 时，可以使用以下可选功能（更多详细信息可以在Dynatrace 文档中找到）：

• 指标键前缀：设置一个前缀，添加到所有导出的指标键。
• 使用 Dynatrace 元数据丰富：如果 OneAgent 或 Dynatrace 操作员正在运行，请使用其他元数据（例如，关于主机、进程或 pod）来丰富指标。
• 默认维度：指定添加到所有导出指标的键值对。如果使用 Micrometer 指定具有相同键的标签，它们会覆盖默认尺寸。
• 使用 Dynatrace 汇总工具：在某些情况下，Micrometer Dynatrace 注册表创建的指标被拒绝。在 Micrometer 1.9.x 中，通过引入 Dynatrace 特定的汇总仪器解决了这个问题。将此切换设置为false强制千分尺回退到 1.9.x 之前的默认行为。只有在从 Micrometer 1.8.x 迁移到 1.9.x 时遇到问题时才应使用它。

可以不指定 URI 和 API 令牌，如下例所示。在这种情况下，使用自动配置的端点：

特性

management.metrics.export.dynatrace.v2.metric-key-prefix=your.key.prefix
management.metrics.export.dynatrace.v2.enrich-with-dynatrace-metadata=true
management.metrics.export.dynatrace.v2.default-dimensions.key1=value1
management.metrics.export.dynatrace.v2.default-dimensions.key2=value2
management.metrics.export.dynatrace.v2.use-dynatrace-summary-instruments=true

v1 API（旧版）

Dynatrace v1 API 指标注册表使用Timeseries v1 API定期将指标推送到配置的 URI 。为了与现有设置向后兼容，设置了 when ​​device-id​​（v1 需要，但在 v2 中不使用），指标将导出到 Timeseries v1 端点。要将指标导出到Dynatrace，必须提供您的 API 令牌、设备 ID 和 URI：

特性

management.metrics.export.dynatrace.uri=https://{your-environment-id}.live.dynatrace.com
management.metrics.export.dynatrace.api-token=YOUR_TOKEN
management.metrics.export.dynatrace.v1.device-id=YOUR_DEVICE_ID

对于 v1 API，您必须指定不带路径的基本环境 URI，因为 v1 端点路径是自动添加的。

与版本无关的设置

除了 API 端点和令牌之外，您还可以更改将指标发送到 Dynatrace 的时间间隔。默认导出间隔为​​60s​​. 以下示例将导出间隔设置为 30 秒：

特性

management.metrics.export.dynatrace.step=30s

您可以在Micrometer 文档和Dynatrace 文档中找到有关如何为 Micrometer 设置 Dynatrace 导出器的更多信息。

6.2.5松紧带

默认情况下，指标会导出到本地机器上运行的Elastic 。您可以使用以下属性提供要使用的 Elastic 服务器的位置：

特性

management.metrics.export.elastic.host=https://elastic.example.com:8086

6.2.6神经节

默认情况下，指标会导出到本地机器上运行的Ganglia 。您可以提供Ganglia 服务器主机和端口，如以下示例所示：

特性

management.metrics.export.ganglia.host=ganglia.example.com
management.metrics.export.ganglia.port=9649

6.2.7. 石墨

默认情况下，指标会导出到本地计算机上运行的Graphite 。您可以提供Graphite 服务器主机和端口，如以下示例所示：

特性

management.metrics.export.graphite.host=graphite.example.com
management.metrics.export.graphite.port=9004

Micrometer 提供了一个默认值​​HierarchicalNameMapper​​，用于控制维度计量器 ID 如何映射到平面分层名称。

6.2.8胡米奥

默认情况下，Humio 注册表会定期将指标推送到cloud.humio.com。要将指标导出到 SaaS Humio，您必须提供您的 API 令牌：

特性

management.metrics.export.humio.api-token=YOUR_TOKEN

您还应该配置一个或多个标签来识别指标推送到的数据源：

特性

management.metrics.export.humio.tags.alpha=a
management.metrics.export.humio.tags.bravo=b

6.2.9涌入

默认情况下，指标会导出到使用默认配置在本地计算机上运行的Influx v1 实例。要将指标导出到 InfluxDB v2，请配置​​org​​、​​bucket​​和 身份验证​​token​​以写入指标。您可以使用以下命令提供要使用的Influx 服务器的位置：

特性

management.metrics.export.influx.uri=https://influx.example.com:8086

6.2.10JMX

Micrometer 提供到JMX的分层映射，主要是作为一种在本地查看指标的廉价且可移植的方式。默认情况下，指标会导出到​​metrics​​JMX 域。您可以使用以下方式提供要使用的域：

特性

management.metrics.export.jmx.domain=com.example.app.metrics

Micrometer 提供了一个默认值​​HierarchicalNameMapper​​，用于控制维度计量器 ID 如何映射到平面分层名称。

6.2.11凯罗斯数据库

默认情况下，指标会导出到本地计算机上运行的KairosDB。您可以使用以下方法提供KairosDB 服务器的位置以使用：

特性

management.metrics.export.kairos.uri=https://kairosdb.example.com:8080/api/v1/datapoints

6.2.12新遗物

New Relic 注册表会定期将指标推送到New Relic。要将指标导出到New Relic，您必须提供您的 API 密钥和帐户 ID：

特性

management.metrics.export.newrelic.api-key=YOUR_KEY
management.metrics.export.newrelic.account-id=YOUR_ACCOUNT_ID

您还可以更改将指标发送到 New Relic 的时间间隔：

特性

management.metrics.export.newrelic.step=30s

默认情况下，指标是通过 REST 调用发布的，但如果您在类路径中有 Java 代理 API，您也可以使用它：

特性

management.metrics.export.newrelic.client-provider-type=insights-agent

最后，您可以通过定义自己的​​NewRelicClientProvider​​bean 来完全控制。

6.2.13普罗米修斯

Prometheus希望抓取或轮询单个应用程序实例的指标。Spring Boot 提供了一个执行器端点，以适当的格式​​/actuator/prometheus​​呈现Prometheus 抓取。

以下示例​​scrape_config​​​添加到​​prometheus.yml​​：

scrape_configs:
  - job_name: "spring"
    metrics_path: "/actuator/prometheus"
    static_configs:
      - targets: ["HOST:PORT"]

还支持Prometheus 示例。要启用此功能，​​SpanContextSupplier​​应提供一个 bean。如果您使用Spring Cloud Sleuth，它将为您自动配置，但您可以随时创建自己的。
请查看Prometheus 文档，因为此功能需要在 Prometheus 端明确启用，并且仅支持使用OpenMetrics格式。

对于可能存在时间不够长而无法被抓取的临时或批处理作业，您可以使用Prometheus Pushgateway支持将指标公开给 Prometheus。要启用 Prometheus Pushgateway 支持，请将以下依赖项添加到您的项目中：

<dependency>
    <groupId>io.prometheus</groupId>
    <artifactId>simpleclient_pushgateway</artifactId>
</dependency>

当类路径上存在 Prometheus Pushgateway 依赖项并且​​management.metrics.export.prometheus.pushgateway.enabled​​属性设置为 时​​true​​，​​PrometheusPushGatewayManager​​会自动配置 bean。这管理将指标推送到 Prometheus Pushgateway。

您可以​​PrometheusPushGatewayManager​​使用​​management.metrics.export.prometheus.pushgateway​​. 对于高级配置，您还可以提供自己的​​PrometheusPushGatewayManager​​bean。

6.2.14信号效果

SignalFx 注册表会定期将指标推送到SignalFx。要将指标导出到SignalFx，您必须提供访问令牌：

特性

management.metrics.export.signalfx.access-token=YOUR_ACCESS_TOKEN

您还可以更改将指标发送到 SignalFx 的时间间隔：

特性

management.metrics.export.signalfx.step=30s

6.2.15简单的

Micrometer 附带一个简单的内存后端，如果没有配置其他注册表，它会自动用作备用。这使您可以查看在metrics 端点中收集了哪些指标。

只要您使用任何其他可用的后端，内存中的后端就会自行禁用。您也可以显式禁用它：

特性

management.metrics.export.simple.enabled=false

6.2.16堆栈驱动程序

Stackdriver 注册表会定期将指标推送到Stackdriver。要将指标导出到 SaaS Stackdriver，您必须提供您的 Google Cloud 项目 ID：

特性

management.metrics.export.stackdriver.project-id=my-project

您还可以更改将指标发送到 Stackdriver 的时间间隔：

特性

management.metrics.export.stackdriver.step=30s

6.2.17统计数据

StatsD 注册表通过 UDP 急切地将指标推送到 StatsD 代理。默认情况下，指标会导出到本地计算机上运行的StatsD代理。您可以通过以下方式提供要使用的 StatsD 代理主机、端口和协议：

特性

management.metrics.export.statsd.host=statsd.example.com
management.metrics.export.statsd.port=9125
management.metrics.export.statsd.protocol=udp

您还可以更改要使用的 StatsD 线路协议（默认为 Datadog）：

特性

management.metrics.export.statsd.flavor=etsy

6.2.18波前

Wavefront 注册表会定期将指标推送到Wavefront。如果您将指标直接导出到Wavefront，则必须提供您的 API 令牌：

特性

management.metrics.export.wavefront.api-token=YOUR_API_TOKEN

或者，您可以在您的环境中使用 Wavefront sidecar 或内部代理将指标数据转发到 Wavefront API 主机：

特性

management.metrics.export.wavefront.uri=proxy://localhost:2878

您还可以更改将指标发送到 Wavefront 的时间间隔：

特性

management.metrics.export.wavefront.step=30s

6.3. 支持的指标和仪表

Spring Boot 为多种技术提供自动仪表注册。在大多数情况下，默认值提供了可以发布到任何受支持的监控系统的合理指标。

6.3.1. JVM 指标

自动配置通过使用核心 Micrometer 类启用 JVM Metrics。JVM 指标以​​jvm.​​计量名称发布。

提供了以下 JVM 指标：

• 各种内存和缓冲池细节
• 垃圾回收相关统计
• 线程利用率
• 加载和卸载的类数

6.3.2. 系统指标

自动配置通过使用核心 Micrometer 类启用系统指标。系统指标以​​system.​​、​​process.​​和​​disk.​​计量名称发布。

提供了以下系统指标：

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

6.3.3. 应用程序启动指标

自动配置公开应用程序启动时间指标：

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

指标由应用程序类的完全限定名称标记。

6.3.4. 记录器指标

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

6.3.5任务执行和调度指标

只要底层可用，自动配置就可以检测所有可用的bean​​ThreadPoolTaskExecutor​​和bean 。指标由执行者的名称标记，该名称派生自 bean 名称。​​ThreadPoolTaskScheduler​​​​ThreadPoolExecutor​​

6.3.6Spring MVC 指标

自动配置启用对 Spring MVC 控制器和功能处理程序处理的所有请求的检测。默认情况下，生成的指标名称为​​http.server.requests​​. 您可以通过设置​​management.metrics.web.server.request.metric-name​​属性来自定义名称。

​​@Timed​​​​@Controller​​类和​​@RequestMapping​​方法支持注释（有关详细信息，请参阅@Timed Annotation Support）。如果您不想记录所有 Spring MVC 请求的指标，则可以设置​​management.metrics.web.server.request.autotime.enabled​​并​​false​​专门使用​​@Timed​​注释。

默认情况下，与 Spring MVC 相关的指标标记有以下信息：

要添加到默认标签，请提供一个或多个​​@Bean​​实现​​WebMvcTagsContributor​​. 要替换默认标签，请提供一个​​@Bean​​实现​​WebMvcTagsProvider​​.

默认情况下，处理所有请求。要自定义过滤器，请提供一个​​@Bean​​​实现​​FilterRegistrationBean<WebMvcMetricsFilter>​​.

6.3.7. Spring WebFlux 指标

自动配置支持对 Spring WebFlux 控制器和功能处理程序处理的所有请求进行检测。默认情况下，生成的指标名称为​​http.server.requests​​. 您可以通过设置​​management.metrics.web.server.request.metric-name​​属性来自定义名称。

​​@Timed​​​​@Controller​​类和​​@RequestMapping​​方法支持注释（有关详细信息，请参阅@Timed Annotation Support）。如果您不想记录所有 Spring WebFlux 请求的指标，则可以设置​​management.metrics.web.server.request.autotime.enabled​​并​​false​​专门使用​​@Timed​​注释。

默认情况下，WebFlux 相关指标标记有以下信息：

要添加到默认标签，请提供一个或多个实现​​WebFluxTagsContributor​​. 要替换默认标签，请提供一个实现​​WebFluxTagsProvider​​.

6.3.8. 泽西服务器指标

自动配置支持检测由 Jersey JAX-RS 实现处理的所有请求。默认情况下，生成的指标名称为​​http.server.requests​​. 您可以通过设置​​management.metrics.web.server.request.metric-name​​属性来自定义名称。

​​@Timed​​请求处理类和方法支持注释（有关详细信息，请参阅@Timed Annotation 支持）。如果您不想记录所有 Jersey 请求的指标，则可以设置​​management.metrics.web.server.request.autotime.enabled​​并​​false​​专门使用​​@Timed​​注释。

默认情况下，Jersey 服务器指标标记有以下信息：

要自定义标签，请提供一个​​@Bean​​实现​​JerseyTagsProvider​​.

6.3.9HTTP 客户端指标

Spring Boot Actuator 管理​​RestTemplate​​和​​WebClient​​. 为此，您必须注入自动配置的构建器并使用它来创建实例：

• ​​RestTemplateBuilder​​为了RestTemplate
• ​​WebClient.Builder​​为了WebClient

您还可以手动应用负责此检测的定制器，即​​MetricsRestTemplateCustomizer​​和​​MetricsWebClientCustomizer​​。

默认情况下，生成的指标名称为​​http.client.requests​​. 您可以通过设置​​management.metrics.web.client.request.metric-name​​属性来自定义名称。

默认情况下，由检测客户端生成的指标带有以下信息标记：

要自定义标签，并且根据您选择的客户端，您可以提供一个​​@Bean​​that implements​​RestTemplateExchangeTagsProvider​​或​​WebClientExchangeTagsProvider​​. ​​RestTemplateExchangeTags​​和中有方便的静态函数​​WebClientExchangeTags​​。

如果您不想记录所有​​RestTemplate​​和​​WebClient​​请求的指标，请设置​​management.metrics.web.client.request.autotime.enabled​​为​​false​​。

6.3.10Tomcat 指标

自动配置仅在启用时​​MBeanRegistry​​启用 Tomcat 的检测。默认情况下，​​MBeanRegistry​​禁用，但您可以通过设置启用​​server.tomcat.mbeanregistry.enabled​​它​​true​​。

Tomcat 指标以​​tomcat.​​计量名称发布。

6.3.11缓存指标

自动配置​​Cache​​在启动时启用所有可用实例的检测，指标以​​cache​​. 缓存检测针对一组基本指标进行了标准化。此外，还提供了特定于缓存的指标。

支持以下缓存库：

• Cache2k
• 咖啡因
• 缓存 2
• 榛树
• 任何兼容的 JCache (JSR-107) 实现
• 雷迪斯

指标由缓存的名称和​​CacheManager​​从 bean 名称派生的名称标记。

6.3.12Spring GraphQL 指标

自动配置为任何支持的传输启用 GraphQL 查询的检测。

Spring Boot 记录一个​​graphql.request​​计时器：

单个 GraphQL 查询可能涉及许多​​DataFetcher​​调用，因此有一个专用​​graphql.datafetcher​​计时器：

​​graphql.request.datafetch.count​​​ 分发摘要​​DataFetcher​​​计算每个请求进行的重要调用的数量。该指标对于检测“N+1”数据获取问题和考虑批量加载很有用；它提供了对记录的请求​​"TOTAL"​​​进行的数据获取器调用的数量​​"COUNT"​​​，以及​​"MAX"​​​在所考虑的时间段内为单个请求进行的调用。更多选项可用于使用应用程序属性配置分发。

单个响应可以包含许多 GraphQL 错误，由​​graphql.error​​计数器计数：

6.3.13数据源指标

自动配置可以​​DataSource​​使用前缀为​​jdbc.connections​​. 数据源检测会生成表示池中当前活动、空闲、允许的最大连接数和允许的最小连接数的仪表。

指标也由​​DataSource​​基于 bean 名称计算的名称标记。

此外，Hikari 特定的指标以​​hikaricp​​​前缀公开。每个指标都由池的名称标记（您可以使用 控制它​​spring.datasource.name​​）。

6.3.14休眠指标

如果​​org.hibernate:hibernate-micrometer​​位于类路径上，则所有​​EntityManagerFactory​​启用了统计信息的可用 Hibernate 实例都使用名为​​hibernate​​.

度量标准也由 bean 的名称来标记，该名称​​EntityManagerFactory​​派生自 bean 名称。

要启用统计信息，标准 JPA 属性​​hibernate.generate_statistics​​必须设置为​​true​​. 您可以在自动配置上启用它​​EntityManagerFactory​​：

特性

spring.jpa.properties[hibernate.generate_statistics]=true

6.3.15Spring 数据存储库指标

自动配置启用所有 Spring Data​​Repository​​方法调用的检测。默认情况下，生成的指标名称为​​spring.data.repository.invocations​​. 您可以通过设置​​management.metrics.data.repository.metric-name​​属性来自定义名称。

​​@Timed​​​​Repository​​类和方法支持注释（有关详细信息，请参阅@Timed Annotation Support）。如果您不想记录所有​​Repository​​调用的指标，则可以设置​​management.metrics.data.repository.autotime.enabled​​并​​false​​专门使用​​@Timed​​注释。

默认情况下，与存储库调用相关的指标标记有以下信息：

要替换默认标签，请提供一个​​@Bean​​实现​​RepositoryTagsProvider​​.

6.3.16RabbitMQ 指标

自动配置可以使用名为​​rabbitmq​​.

6.3.17Spring 集成指标

只要bean 可用，Spring Integration 就会自动提供Micrometer 支持。​​MeterRegistry​​指标以​​spring.integration.​​计量名称发布。

6.3.18卡夫卡指标

自动配置分别为自动配置的消费者工厂和生产者工厂注册 a​​MicrometerConsumerListener​​和。​​MicrometerProducerListener​​它还注册了一个​​KafkaStreamsMicrometerListener​​for ​​StreamsBuilderFactoryBean​​。有关更多详细信息，请参阅 Spring Kafka 文档的Micrometer Native Metrics部分。

6.3.19MongoDB 指标

本节简要介绍 MongoDB 的可用指标。

MongoDB 命令指标

自动配置将 a 注册​​MongoMetricsCommandListener​​到自动配置的​​MongoClient​​.

​​mongodb.driver.commands​​为发布到底层 MongoDB 驱动程序的每个命令创建一个名为的计时器度量。默认情况下，每个指标都标记有以下信息：

要替换默认度量标记，请定义一个​​MongoCommandTagsProvider​​bean，如以下示例所示：

@Configuration(proxyBeanMethods = false)
public class MyCommandTagsProviderConfiguration {

    @Bean
    public MongoCommandTagsProvider customCommandTagsProvider() {
        return new CustomCommandTagsProvider();
    }

}

要禁用自动配置的命令指标，请设置以下属性：

特性

management.metrics.mongo.command.enabled=false

MongoDB 连接池指标

自动配置将 a 注册​​MongoMetricsConnectionPoolListener​​到自动配置的​​MongoClient​​.

为连接池创建了以下计量指标：

• ​​mongodb.driver.pool.size​​报告连接池的当前大小，包括空闲和正在使用的成员。
• ​​mongodb.driver.pool.checkedout​​报告当前正在使用的连接数。
• ​​mongodb.driver.pool.waitqueuesize​​报告来自池的连接的等待队列的当前大小。

默认情况下，每个指标都标记有以下信息：

要替换默认的度量标签，定义一个​​MongoConnectionPoolTagsProvider​​bean：

@Configuration(proxyBeanMethods = false)
public class MyConnectionPoolTagsProviderConfiguration {

    @Bean
    public MongoConnectionPoolTagsProvider customConnectionPoolTagsProvider() {
        return new CustomConnectionPoolTagsProvider();
    }

}

要禁用自动配置的连接池指标，请设置以下属性：

特性

management.metrics.mongo.connectionpool.enabled=false

6.3.20码头指标

​​ThreadPool​​自动配置使用 Micrometer绑定 Jetty 的指标​​JettyServerThreadPoolMetrics​​。Jetty​​Connector​​实例的指标使用 Micrometer 绑定​​JettyConnectionMetrics​​，当​​server.ssl.enabled​​设置为时​​true​​，Micrometer绑定​​JettySslHandshakeMetrics​​。

6.3.21@Timed 注释支持

您可以​​@Timed​​将包中的注释​​io.micrometer.core.annotation​​与前面描述的几种受支持的技术一起使用。如果支持，您可以在类级别或方法级别使用注释。

例如，以下代码显示了如何使用注解来检测 a 中的所有请求映射​​@RestController​​：

@RestController
@Timed
public class MyController {

    @GetMapping("/api/addresses")
    public List<Address> listAddress() {
        return ...
    }

    @GetMapping("/api/people")
    public List<Person> listPeople() {
        return ...
    }

}

如果您只想检测单个映射，则可以在方法上使用注释而不是类：

@RestController
public class MyController {

    @GetMapping("/api/addresses")
    public List<Address> listAddress() {
        return ...
    }

    @GetMapping("/api/people")
    @Timed
    public List<Person> listPeople() {
        return ...
    }

}

如果要更改特定方法的计时详细信息，还可以组合类级别和方法级别的注释：

@RestController
@Timed
public class MyController {

    @GetMapping("/api/addresses")
    public List<Address> listAddress() {
        return ...
    }

    @GetMapping("/api/people")
    @Timed(extraTags = { "region", "us-east-1" })
    @Timed(value = "all.people", longTask = true)
    public List<Person> listPeople() {
        return ...
    }

}

6.3.22。Redis 指标

自动配置​​MicrometerCommandLatencyRecorder​​为自动配置的​​LettuceConnectionFactory​​. 有关更多详细信息，请参阅 Lettuce 文档的Micrometer Metrics 部分。

6.4. 注册自定义指标

要注册自定义指标，请注入​​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，我们建议您使用 a​​MeterBinder​​来注册它们：

public class MyMeterBinderConfiguration {

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

}

使用 a​​MeterBinder​​可确保设置正确的依赖关系，并且在检索度量值时 bean 可用。如果​​MeterBinder​​您发现您反复检测跨组件或应用程序的一组指标，则实施也可能很有用。

6.5自定义单个指标

如果您需要对特定​​Meter​​实例应用自定义，您可以使用该​​io.micrometer.core.instrument.config.MeterFilter​​界面。

例如，如果要将​​mytag.region​​标记重命名​​mytag.area​​为所有以 开头的仪表 ID ​​com.example​​，则可以执行以下操作：

@Configuration(proxyBeanMethods = false)
public class MyMetricsFilterConfiguration {

    @Bean
    public MeterFilter renameRegionTagMeterFilter() {
        return MeterFilter.renameTag("com.example", "mytag.region", "mytag.area");
    }

}

6.5.1. 常用标签

常用标签通常用于对操作环境进行维度下钻，例如主机、实例、区域、堆栈等。Commons 标签适用于所有仪表并且可以配置，如以下示例所示：

特性

management.metrics.tags.region=us-east-1
management.metrics.tags.stack=prod

前面的示例分别为所有具有 和 值的仪表添加​​region​​和标记。​​stack​​​​us-east-1​​​​prod​​

6.5.2. 每米属性

除了​​MeterFilter​​bean 之外，您还可以使用属性在每米的基础上应用一组有限的自定义。使用 Spring Boot 将每米自定义应用​​PropertiesMeterFilter​​到以给定名称开头的任何仪表 ID。以下示例过滤掉任何 ID 以 开头的仪表​​example.remote​​。

特性

management.metrics.enable.example.remote=false

以下属性允许按米自定义：

表 1. 每米自定义

有关 、 和 背后概念的更多详细信息​​percentiles-histogram​​，​​percentiles​​请​​slo​​参阅 Micrometer 文档的“直方图和百分位数”部分。

6.6. 指标端点

Spring Boot 提供了一个​​metrics​​端点，您可以使用该端点诊断性地检查应用程序收集的指标。端点默认不可用，必须公开。有关更多详细信息，请参阅公开端点。

导航以​​/actuator/metrics​​显示可用仪表名称的列表。您可以通过提供特定仪表的名称作为选择器来深入查看有关特定仪表的信息 - 例如，​​/actuator/metrics/jvm.memory.max​​。

您还可以将任意数量的​tag=KEY:VALUE​​查询参数添加到 URL 的末尾，以在维度上向下钻取仪表 - 例如，​​/actuator/metrics/jvm.memory.max?tag=area:nonheap​​.

7. 审计

一旦 Spring Security 发挥作用，Spring Boot Actuator 就会有一个灵活的审计框架来发布事件（默认情况下，“身份验证成功”、“失败”和“访问被拒绝”异常）。此功能对于报告和实施基于身份验证失败的锁定策略非常有用。

​​AuditEventRepository​​您可以通过在应用程序的配置中提供类型的 bean 来启用审计。为方便起见，Spring Boot 提供了一个​​InMemoryAuditEventRepository​​. ​​InMemoryAuditEventRepository​​功能有限，我们建议仅将其用于开发环境。对于生产环境，请考虑创建您自己的替代​​AuditEventRepository​​实现。

7.1自定义审计

要自定义已发布的安全事件，您可以提供自己的​​AbstractAuthenticationAuditListener​​和实现​​AbstractAuthorizationAuditListener​​。

您还可以将审计服务用于您自己的业务活动。为此，要么将​​AuditEventRepository​​bean 注入到您自己的组件中并直接使用它，要么使用​​AuditApplicationEvent​​Spring发布​​ApplicationEventPublisher​​（通过实现​​ApplicationEventPublisherAware​​）。

8. HTTP 跟踪

​​HttpTraceRepository​​您可以通过在应用程序的配置中提供类型的 bean 来启用 HTTP 跟踪。为方便起见，Spring Boot 提供​​InMemoryHttpTraceRepository​​了 存储最近 100 次（默认）请求-响应交换的跟踪信息。 ​​InMemoryHttpTraceRepository​​与其他跟踪解决方案相比，它是有限的，我们建议仅将其用于开发环境。对于生产环境，我们建议使用生产就绪的跟踪或可观察性解决方案，例如 Zipkin 或 Spring Cloud Sleuth。或者，您可以创建自己的​​HttpTraceRepository​​.

您可以使用​​httptrace​​端点获取有关存储在​​HttpTraceRepository​​.

8.1自定义 HTTP 跟踪

要自定义每个跟踪中包含的项目，请使用​​management.trace.http.include​​配置属性。对于高级定制，请考虑注册您自己的​​HttpExchangeTracer​​实现。

9. 过程监控

在​​spring-boot​​模块中，您可以找到两个类来创建通常对进程监控有用的文件：

• ​​ApplicationPidFileWriter​​创建一个包含应用程序 PID 的文件（默认情况下，在应用程序目录中，文件名为application.pid）。
• ​​WebServerPortFileWriter​​创建一个文件（或多个文件），其中包含正在运行的 Web 服务器的端口（默认情况下，在应用程序目录中，文件名为application.port）。

默认情况下，这些编写器未激活，但您可以启用它们：

• 通过扩展配置
• 以编程方式启用过程监控

9.1扩展配置

在该​​META-INF/spring.factories​​文件中，您可以激活写入 PID 文件的侦听器（或多个侦听器）：

org.springframework.context.ApplicationListener=\ 
org.springframework.boot.context.ApplicationPidFileWriter,\ 
org.springframework.boot.web.context.WebServerPortFileWriter

9.2. 以编程方式启用过程监控

您还可以通过调用​​SpringApplication.addListeners(…)​​方法并传递适当的​​Writer​​对象来激活侦听器。此方法还允许您在构造函数中自定义文件名和路径​​Writer​​。

10. Cloud Foundry 支持

Spring Boot 的执行器模块包括在您部署到兼容的 Cloud Foundry 实例时激活的额外支持。该​​/cloudfoundryapplication​​路径为所有​​@Endpoint​​bean 提供了一个替代的安全路径。

扩展支持允许 Cloud Foundry 管理 UI（例如可用于查看已部署应用程序的 Web 应用程序）增加 Spring Boot 执行器信息。例如，应用程序状态页面可以包含完整的健康信息，而不是典型的“运行”或“停止”状态。

10.1。禁用扩展的 Cloud Foundry 执行器支持

如果要完全禁用​​/cloudfoundryapplication​​端点，可以将以下设置添加到​​application.properties​​文件中：

特性

management.cloudfoundry.enabled=false

10.2. Cloud Foundry 自签名证书

默认情况下，​​/cloudfoundryapplication​​端点的安全验证会对各种 Cloud Foundry 服务进行 SSL 调用。如果您的 Cloud Foundry UAA 或 Cloud Controller 服务使用自签名证书，您需要设置以下属性：

特性

management.cloudfoundry.skip-ssl-validation=true

10.3. 自定义上下文路径

如果服务器的上下文路径已配置为 以外的任何内容​​/​​，则 Cloud Foundry 端点在应用程序的根目录中不可用。例如，如果​​server.servlet.context-path=/app​​，Cloud Foundry 端点在 可用​​/app/cloudfoundryapplication/*​​。

如果您希望 Cloud Foundry 端点始终可用​​/cloudfoundryapplication/*​​，则无论服务器的上下文路径如何，您都需要在应用程序中显式配置它。配置会有所不同，具体取决于所使用的 Web 服务器。对于 Tomcat，您可以添加以下配置：

@Configuration(proxyBeanMethods = false)
public class MyCloudFoundryConfiguration {

    @Bean
    public TomcatServletWebServerFactory servletWebServerFactory() {
        return new TomcatServletWebServerFactory() {

            @Override
            protected void prepareContext(Host host, ServletContextInitializer[] initializers) {
                super.prepareContext(host, initializers);
                StandardContext child = new StandardContext();
                child.addLifecycleListener(new Tomcat.FixContextListener());
                child.setPath("/cloudfoundryapplication");
                ServletContainerInitializer initializer = getServletContextInitializer(getContextPath());
                child.addServletContainerInitializer(initializer, Collections.emptySet());
                child.setCrossContext(true);
                host.addChild(child);
            }

        };
    }

    private ServletContainerInitializer getServletContextInitializer(String contextPath) {
        return (classes, context) -> {
            Servlet servlet = new GenericServlet() {

                @Override
                public void service(ServletRequest req, ServletResponse res) throws ServletException, IOException {
                    ServletContext context = req.getServletContext().getContext(contextPath);
                    context.getRequestDispatcher("/cloudfoundryapplication").forward(req, res);
                }

            };
            context.addServlet("cloudfoundry", servlet).addMapping("/*");
        };
    }

}