Spring Boot 包含许多其他功能,可帮助你在将应用程序推送到生产环境时监控和管理应用程序. 你可以选择使用 HTTP 端点或 JMX 来管理和监控应用程序. 审计、健康和指标收集也可以自动应用于你的应用程序.
1. 启用生产就绪功能
spring-boot-actuator 模块提供了 Spring Boot 的所有生产就绪功能. 启用这些功能的推荐的方法是添加 spring-boot-starter-actuator “Starter” 到依赖中.
要将 actuator 添加到基于 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. Endpoints（端点）
通过 Actuator 端点,你可以监控应用程序并与之交互. Spring Boot 包含许多内置端点,也允许你添加自己的端点. 例如,health 端点提供基本的应用程序健康信息.
可以 启用或禁用 每个端点. 它可以控制当其 bean 存在于应用程序上下文中是否创建端点.
当端点同时启用和公开时,它被视为可用.
内置端点只有在可用时才会被自动配置.
要进行远程访问,必须通过 JMX 或 HTTP 暴露端点. 大多数应用程序选择 HTTP 方式,通过端点的 ID 以及 /actuator 的前缀映射一个 URL. 例如,默认情况下,health 端点映射到 /actuator/health.
可以使用以下与技术无关的端点:
| ID | 描述 |
|---|---|
|
暴露当前应用程序的审计事件信息. 需要一个 |
|
显示应用程序中所有 Spring bean 的完整列表. |
|
暴露可用的缓存. |
|
显示在配置和自动配置类上评估的条件以及它们匹配或不匹配的原因. |
|
显示所有 |
|
暴露 Spring |
|
显示已应用的 Flyway 数据库迁移,需要一个或多个 |
|
显示应用程序健康信息. |
|
显示 HTTP 追踪信息 (默认情况下,最后 100 个 HTTP 请求/响应交换) . 需要一个 |
|
显示应用程序信息. |
|
显示 Spring Integration 图. 需要依赖 |
|
显示和修改应用程序中日志记录器的配置. |
|
显示已应用的 Liquibase 数据库迁移. 需要一个或多个 |
|
显示当前应用程序的 “metrics” 信息 |
|
显示所有 |
|
显示有关 Quartz Scheduler jobs 信息. |
|
显示应用程序中的调度任务. |
|
允许从 Spring Session 支持的会话存储中检索和删除用户会话. 使用 Spring Session 时要求是基于 Servlet 的 web 应用程序 |
|
正常关闭应用程序. 默认禁用 |
|
显示由 |
|
执行线程 dump. |
如果你的应用程序是 Web 应用程序 (Spring MVC、Spring WebFlux 或 Jersey) ,则可以使用以下附加端点:
| ID | 描述 |
|---|---|
|
返回 heap dump 文件. 在 HotSpot JVM ，返回一个 |
|
通过 HTTP 暴露 JMX bean (当 Jolokia 在 classpath 上时,不适用于 WebFlux) . 需要依赖 |
|
返回日志文件的内容 (如果已设置 |
|
以可以由 Prometheus 服务器抓取的格式暴露指标. 需要依赖 |
2.1. 启用端点
默认情况下,Actuator 启用除 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
endpoint:
info:
enabled: true
已完全从应用程序上下文中删除已禁用的端点. 如果只想更改端点所暴露的技术,请改用 include 和 exclude 属性.
|
2.2. 暴露端点
由于端点可能包含敏感信息,因此应仔细考虑何时暴露它们. 下表显示了内置端点和默认暴露情况:
| ID | JMX | Web |
|---|---|---|
|
Yes |
No |
|
Yes |
No |
|
Yes |
No |
|
Yes |
No |
|
Yes |
No |
|
Yes |
No |
|
Yes |
No |
|
Yes |
Yes |
|
N/A |
No |
|
Yes |
No |
|
Yes |
Yes |
|
Yes |
No |
|
N/A |
No |
|
N/A |
No |
|
Yes |
No |
|
Yes |
No |
|
Yes |
No |
|
Yes |
No |
|
N/A |
No |
|
Yes |
No |
|
Yes |
No |
|
Yes |
No |
|
Yes |
No |
|
Yes |
No |
要更改暴露的端点,请使用以下特定的 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: "*"
exclude: "env,beans"
* 在 YAML 中有特殊含义， 所以如果你想包括 (或排除) 所有端点， 请务必加引号.
|
| 如果你的应用程序是暴露的,我们强烈建议你也 保护你的端点. |
如果要在暴露端点时实现自己的策略,可以注册一个 EndpointFilter bean.
|
2.3. 安全
出于安全考虑，默认情况下，只有 /health 端点通过 HTTP 公开。
您可以使用 management.endpoints.web.exposure.include 属性来配置暴露的端点。
在设置 management.endpoints.web.exposure.include 之前，确保暴露的执行器不包含敏感信息，通过将它们放置在防火墙后面来保护它们，或者通过 Spring Security 之类的东西来保护它们。
|
如果你希望为 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).
如果应用程序部署在有防火墙的环境,你可能希望无需身份验证即可访问所有 Actuator 端点. 你可以通过更改 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();
}
}
在上面的两个示例中， 配置只适用于 actuator 端点. 由于 Spring Boot 的安全配置在存在任何 SecurityFilterChain bean 时完全退出， 因此您将需要配置一个附加的 SecurityFilterChain bean， 其中包含应用于应用程序其余部分的规则.
|
2.3.1. 跨站点请求伪造保护
由于 Spring Boot 依赖于 Spring Security 的默认设置，因此默认开启 CSRF 保护。
这意味着当使用默认安全配置时，需要 POST（关闭和记录器端点）、PUT 或 DELETE 的执行器端点会收到 403（禁止）错误。
| 我们建议仅在您创建非浏览器客户端使用的服务时完全禁用 CSRF 保护。 |
您可以在 Spring Security Reference Guide 中找到有关 CSRF 保护的更多信息。
2.4. 配置端点
端点对不带参数读取操作的响应自动缓存. 要配置端点缓存响应的时间长度,请使用其 cache.time-to-live 属性. 以下示例将 beans 端点缓存的生存时间设置为 10 秒:
management:
endpoint:
beans:
cache:
time-to-live: "10s"
前缀 management.endpoint.<name> 用于唯一标识配置的端点.
|
2.5. Actuator Web 端点超媒体
添加 “discovery page”,其包含指向所有端点的链接. 默认情况下,discovery page 在 /actuator 上可访问.
要禁用 “discovery page”，请将以下属性添加到您的应用程序属性中:
management:
endpoints:
web:
discovery:
enabled: false配置一个自定义管理上下文 (management context) 路径时,discovery page 会自动从 /actuator 移动到管理上下文的根目录.
例如,如果管理上下文路径是 /management,则可以从 /management 获取 discovery page. 当管理上下文路径设置为 / 时,将禁用发现页面以防止与其他映射冲突.
2.6. CORS 支持
Cross-origin resource sharing (CORS) 是一个 W3C 规范允许你以灵活的方式指定授权的跨域请求类型. 如果你使用 Spring MVC 或 Spring WebFlux,则可以配置 Actuator 的 Web 端点以支持此类方案.
默认情况下 CORS 支持被禁用,仅在设置了 management.endpoints.web.cors.allowed-origins 属性后才启用 CORS 支持. 以下配置允许来自 example.com 域的 GET 和 POST 调用:
management:
endpoints:
web:
cors:
allowed-origins: "https://example.com"
allowed-methods: "GET,POST"| 有关选项的完整列表,请参阅 CorsEndpointProperties |
2.7. 实现自定义端点
如果你添加一个使用了 @Endpoint 注解的 @Bean,则使用 @ReadOperation, @WriteOperation, 或 @DeleteOperation 注解的所有方法都将通过 JMX 自动暴露,并且在 Web 应用程序中也将通过 HTTP 暴露. 可以使用 Jersey、Spring MVC 或 Spring WebFlux 通过 HTTP 暴露端点.
以下示例暴露了一个 read 操作,该操作返回一个自定义对象:
@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
}
由于端点与技术无关,因此只能在方法签名中指定简单类型. 特别是不支持使用定义一个 name 和 counter 属性的 CustomData 类型声明单个参数.
|
要允许将输入映射到操作方法的参数,应使用 -parameters 编译实现端点的 Java 代码,并且应使用 -java-parameters 编译实现端点的 Kotlin 代码. 如果你使用的是 Spring Boot 的 Gradle 插件,或者是 Maven 和 spring-boot-starter-parent,则它们会自动执行此操作.
|
2.7.2. 自定义 Web 端点
@Endpoint、@WebEndpoint 或 @EndpointWebExtension 上的操作将使用 Jersey、Spring MVC 或 Spring WebFlux 通过 HTTP 自动暴露.
使用 Jersey、Spring MVC 或 Spring WebFlux 通过 HTTP 自动暴露对 @Endpoint、@WebEndpoint 或 @EndpointWebExtension 的操作。
如果 Jersey 和 Spring MVC 都可用，则使用 Spring MVC。
Path
断言的路径由端点的 ID 和 Web 暴露的端点的基础路径确定. 默认路径是 /actuator. 例如,有 ID 为 sessions 的端点将使用 /actuator/sessions 作为其在断言中的路径.
通过使用 @Selector 注解操作方法的一个或多个参数,可以进一步自定义路径. 这样的参数作为路径变量添加到路径断言中. 调用端点操作时,变量的值将传递给操作方法.
如果要捕获所有剩余的路径元素,可以将 @Selector(Match=ALL_REMAINING) 添加到最后一个参数,并将其设置为与 String [] 转换兼容的类型.
HTTP 方法
断言的 HTTP 方法由操作类型决定,如下表所示:
| Operation | HTTP 方法 |
|---|---|
|
|
|
|
|
|
Consumes
对于使用请求体的 @WriteOperation (HTTP POST) ,断言的 consume 子句是 application/vnd.spring-boot.actuator.v2+json, application/json. 对于所有其他操作, consumes 子句为空.
Produces
断言的 produces 子句可以由 @DeleteOperation、@ReadOperation 和 @WriteOperation 注解的 produces 属性确定. 该属性是可选的. 如果未使用,则自动确定 produces 子句.
如果操作方法返回 void 或 Void,则 produces 子句为空. 如果操作方法返回 org.springframework.core.io.Resource,则 produces 子句为 application/octet-stream. 对于所有其他操作,produces 子句是 application/vnd.spring-boot.actuator.v2+json, application/json.
Web 端点响应状态
端点操作的默认响应状态取决于操作类型 (读取、写入或删除) 以及操作返回的内容 (如果有) .
@ReadOperation 返回一个值,响应状态为 200 (OK) . 如果它未返回值,则响应状态将为 404 (未找到) .
如果 @WriteOperation 或 @DeleteOperation 返回值,则响应状态将为 200 (OK) . 如果它没有返回值,则响应状态将为 204 (无内容) .
如果在没有必需参数的情况下调用操作,或者使用无法转换为所需类型的参数,则不会调用操作方法,并且响应状态将为 400 (错误请求) .
2.8. 健康信息
你可以使用健康信息来检查正在运行的应用程序的状态. 监控软件经常在生产系统出现故障时使用它提醒某人. health 端点暴露的信息取决于 management.endpoint.health.show-details 和 management.endpoint.health.show-components 属性,可以使用以下值之一配置属性:
| Name | Description |
|---|---|
|
永远不会显示细节. |
|
详细信息仅向授权用户显示. 可以使用 |
|
向所有用户显示详细信息. |
默认值为 never. 当用户处于一个或多个端点的角色时,将被视为已获得授权. 如果端点没有配置角色 (默认值) ,则认为所有经过身份验证的用户都已获得授权. 可以使用 management.endpoint.health.roles 属性配置角色.
如果你已保护应用程序并希望使用 always,则安全配置必须允许经过身份验证和未经身份验证的用户对健康端点的访问.
|
健康信息是从 HealthContributorRegistry 的内容中收集的 (默认情况下,ApplicationContext 中定义的所有 HealthContributor 实例) . Spring Boot 包含许多自动配置的 HealthContributors,你也可以自己编写.
HealthContributor 可以是 HealthIndicator,也可以是 CompositeHealthContributor.
HealthIndicator 提供实际的健康信息,包括 Status.
CompositeHealthContributor 提供其他 HealthContributors 的组合.
总之,contributors 形成了一个表示整个系统健康状况的树结构.
默认情况下,最终系统状态由 StatusAggregator 扩展,根据状态的有序列表对每个 HealthIndicator 的状态进行排序. 排序列表中的第一个状态作为整体健康状态. 如果没有 HealthIndicator 返回一个 StatusAggregator 已知的状态,则使用 UNKNOWN 状态.
HealthContributorRegistry 可用于在运行时注册和注销健康指示器.
|
2.8.1. 自动配置的 HealthIndicators
Spring Boot 会自动配置以下 HealthIndicators.您也可以通过配置 management.health.key.enabled 并使用下表中列出的 key 来启用/禁用指定的指标.
| Key | Name | Description |
|---|---|---|
|
Checks that a Cassandra database is up. |
|
|
Checks that a Couchbase cluster is up. |
|
|
Checks that a connection to |
|
|
Checks for low disk space. |
|
|
Checks that an Elasticsearch cluster is up. |
|
|
Checks that a Hazelcast server is up. |
|
|
Checks that an InfluxDB server is up. |
|
|
Checks that a JMS broker is up. |
|
|
Checks that an LDAP server is up. |
|
|
Checks that a mail server is up. |
|
|
Checks that a Mongo database is up. |
|
|
Checks that a Neo4j database is up. |
|
|
Always responds with |
|
|
Checks that a Rabbit server is up. |
|
|
Checks that a Redis server is up. |
|
|
Checks that a Solr server is up. |
你可以通过设置 management.health.defaults.enabled 属性来禁用它们.
|
其他 HealthIndicators 可用,但默认情况下未启用:
| Key | Name | Description |
|---|---|---|
|
Exposes the “Liveness” application availability state. |
|
|
Exposes the “Readiness” application availability state. |
2.8.2. 编写自定义 HealthIndicators
要提供自定义健康信息,可以注册实现 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 ...
}
}
给定 HealthIndicator 的标识符是没有 HealthIndicator 后缀的 bean 的名称 (如果存在) . 在前面的示例中,健康信息在名为 my 的条目中可用.
|
健康指标通常通过 HTTP 调用，并且在连接超时之前做出响应。任何响应时间超过 10s 的健康指标都会发出一条报警信息。如果要配置此阈值，可以使用 management.endpoint.health.logging.slow-indicator-threshold 属性。
|
除了 Spring Boot 的预定义 Status 类型之外,Health 还可以返回一个表示新系统状态的自定义 Status. 在这种情况下,还需要提供 StatusAggregator 接口的自定义实现,或者必须使用 management.endpoint.health.status.order 配置属性配置默认实现.
例如,假设在你的一个 HealthIndicator 实现中使用了代码为 FATAL 的新 Status. 需要配置严重性顺序,请将以下属性添加到应用程序属性:
management:
endpoint:
health:
status:
order: "fatal,down,out-of-service,unknown,up"响应中的 HTTP 状态码反映了整体运行状况 (例如,UP 映射到 200,而 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
fatal: 503
out-of-service: 503
如果需要控制更多,可以定义自己的 HttpCodeStatusMapper bean.
|
下表展示了内置状态的默认状态映射:
| 状态 | 映射 |
|---|---|
|
|
|
|
|
No mapping by default, so HTTP status is |
|
No mapping by default, so HTTP status is |
2.8.3. 响应式健康指示器
对于响应式应用程序,例如使用 Spring WebFlux 的应用程序,ReactiveHealthContributor 提供了一个非阻塞的接口来获取应用程序健康信息. 与传统的 HealthContributor 类似,
健康信息从 ReactiveHealthContributorRegistry 的内容中收集 (默认情况下,
ApplicationContext 中定义的所有 HealthContributor 和 ReactiveHealthContributor 实例) . 不检查响应式 API 的常规 HealthContributors 在弹性调度程序上执行.
在响应式应用程序中,ReactiveHealthContributorRegistry 可用于在运行时注册和取消注册健康指示器. 如果需要注册常规的 HealthContributor,则应使用 ReactiveHealthContributor#adapt 对其进行包装.
|
要从响应式 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 ...
}
}
要自动处理错误，请考虑从 AbstractReactiveHealthIndicator 扩展。
|
2.8.4. 自动配置的 ReactiveHealthIndicators
适当时,Spring Boot会自动配置以下 ReactiveHealthIndicators:
| Key | Name | 描述 |
|---|---|---|
|
检查 Cassandra 数据库是否已启动。 |
|
|
检查 Couchbase 集群是否已启动。 |
|
|
检查 Elasticsearch 集群是否已启动。 |
|
|
检查 Mongo 数据库是否已启动。 |
|
|
检查 Neo4j 数据库是否已启动。 |
|
|
检查 Redis 服务器是否已启动。 |
如有必要，响应式指标会取代常规指标。 此外,任何未明确处理的 HealthIndicator 都会自动包装.
|
2.8.5. Health 组
有时候,将健康指标分为不同的组很有用. 例如,如果将应用程序部署到Kubernetes,则可能需要一组不同的运行状况指示器来进行 active 和 "就绪" 探针.
要创建运行状况指示器组,可以使用 management.endpoint.health.group.<name> 属性,并使用 include 或 exclude 指定需要展示运行状况指示器ID的列表. 例如,创建仅包含数据库指示符的组,可以定义以下内容:
management:
endpoint:
health:
group:
custom:
include: "db"然后，您可以通过点击 localhost:8080/actuator/health/custom 来检查结果。
同样， 要创建一个组， 可从组中排除数据库指标， 并包含所有其他指标， 您可以定义以下内容:
management:
endpoint:
health:
group:
custom:
exclude: "db"默认情况下,组将继承与系统运行状况相同的 StatusAggregator 和 HttpCodeStatusMapper 设置,但是,这些设置也可以基于每个组进行定义. 如果需要,也可以覆盖 show-details 和 roles 属性:
management:
endpoint:
health:
group:
custom:
show-details: "when-authorized"
roles: "admin"
status:
order: "fatal,up"
http-mapping:
fatal: 500
out-of-service: 500
如果需要注册自定义 StatusAggregator 或 HttpCodeStatusMapper Bean以便与该组一起使用,则可以使用 @Qualifier("groupname") .
|
一个健康组也可以 include/exclude 一个 CompositeHealthContributor。 您还可以仅包含/排除 CompositeHealthContributor 的某个组件。 这可以使用组件的完全限定名称来完成，如下所示：
management.endpoint.health.group.custom.include="test/primary"
management.endpoint.health.group.custom.exclude="test/primary/b"在上面的示例中，custom 组将包含名为 primary 的 HealthContributor ，它是组合 test 的一个组件。
在这里，primary 本身是一个复合体，名称为 b 的 HealthContributor 将被排除在 custom 组之外。
可以在主端口或管理端口上的附加路径上提供运行状况组。 这在 Kubernetes 等云环境中很有用，在这些环境中，出于安全目的，为执行器端点使用单独的管理端口是很常见的。 拥有一个单独的端口可能会导致不可靠的健康检查，因为即使健康检查成功，主应用程序也可能无法正常工作。 可以为健康组配置额外的路径，如下所示:
management.endpoint.health.group.live.additional-path="server:/healthz"这将使 live 健康组在 /healthz 的主服务器端口上可用。 前缀是强制性的，必须是 server: （表示主服务器端口）或 management:（如果已配置，则表示管理端口。） 路径必须是单个路径段。
2.9. Kubernetes Probes
部署在 Kubernetes 上的应用程序可以使用 Container Probes 提供有关其内部状态的信息.根据 您的Kubernetes 配置, kubelet 将调用这些探针并对结果做出反应.
Spring Boot 管理您的 应用程序可用性转台.
如果部署在 Kubernetes 环境中,那么 actuator 将从 ApplicationAvailability 接口收集 "Liveness" and "Readiness" 信息,并在 Health Indicators: LivenessStateHealthIndicator 和 ReadinessStateHealthIndicator 中使用这些信息.这些指标将显示在全局健康端点 ("/actuator/health") 中.他们还暴露了单独的 HTTP 探针,这些探针位置 Health Groups 中: "/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: ...
<actuator-port> 应该设置为 actuator 端点可用的端口.它可以是 web 服务器端口,或者是单独的管理端口(如果 "management.server.port" 已设置)
|
仅当应用程序 在 Kubernetes 环境中运行时 ,才会自动启用这些运行状况组.您可以使用 management.endpoint.health.probes.enabled 配置属性在任何环境中启用它们.
如果应用程序的启动时间比配置的激活时间长,Kubernetes 会提及 "startupProbe" 作为可能的解决方案. 由于在所有启动任务完成之前 "readinessProbe" 将失败,因此此处不一定需要 "startupProbe" ,请参阅 探针在应用程序生命周期中的行为.
|
如果您的 Actuator 端点部署在单独的管理上下文中,请注意,端点将不使用与主应用程序相同的 Web 基础结构 (端口,连接池,框架组件) . 在这种情况下,即使主应用程序无法正常运行 (例如,它不能接受新连接) ,也可能会成功进行探测检查.出于这个原因，在主服务器端口上使 liveness 和 readiness 健康组可用是一个好主意。 这可以通过设置以下属性来完成：
|
如果您的 Actuator 端点部署在单独的管理上下文中，则端点不会使用与主应用程序相同的 Web 基础设施（端口、连接池、框架组件）。 在这种情况下，即使主应用程序无法正常工作（例如，它不能接受新连接），探测检查也可能会成功。
management.endpoint.health.probes.add-additional-paths=true这将使 liveness 在主服务器端口上的 /livez 和 readyz 可用。
2.9.1. 使用 Kubernetes 探针检查外部状态
Actuator 将 “liveness” 和 “readiness” 探针配置为 Health Groups features .这意味着所有 Health Groups 功能均可用.例如,您可以配置其他运行状况指标:
management:
endpoint:
health:
group:
readiness:
include: "readinessState,customCheck"默认情况下,Spring Boot 不会将其他运行状况指标添加到这些组中.
“liveness” 探针不应依赖于外部系统的运行状况检查. 如果 应用程序的 Liveness 状态 被破坏,Kubernetes 将尝试通过重新启动应用程序实例来解决该问题. 这意味着,如果外部系统发生故障 (例如数据库,Web API,外部缓存) ,则 Kubernetes 可能会重新启动所有应用程序实例并造成级联故障.
至于 “readiness” 探针,必须由应用程序开发人员仔细选择检查外部系统的选择,即,Spring Boot 在 readiness 探针中不包括任何其他运行状况检查. 如果应用程序实例的 readiness 状态 尚未就绪,Kubernetes 将不会将流量路由到该实例. 应用程序实例可能不会共享某些外部系统,在这种情况下,它们很自然地可以包含在 readiness 探针中. 其他外部系统对于该应用程序可能不是必需的 (该应用程序可能具有 circuit breakers 和 fallbacks) ,在这种情况下,绝对不应该包括它们. 不幸的是,由所有应用程序实例共享的外部系统是常见的,您必须做出判断调用: 将其包括在 readiness 探针中,并期望在外部服务关闭时该应用程序退出服务,或者退出该应用程序 排除并处理更高级别的故障,例如 在回调中使用熔断.
如果应用程序的所有实例尚未就绪,则 type=ClusterIP 或 NodePort 服务将不接受任何传入连接. 由于没有连接,因此没有 HTTP 错误响应 (503 等) . type=LoadBalancer 的服务可能会或可能不会接受连接,具体取决于提供程序. 具有显式 Ingress 的 Service 还将以依赖于实现的方式进行响应- Ingress Service 本身必须决定如何处理下游的 "拒绝连接". 对于负载均衡器和入口都非常可能使用 HTTP 503.
|
另外,如果应用程序正在使用 Kubernetes autoscaling,它可能会对从负载平衡中取出的应用程序做出不同的响应,这取决于它的 autoscaler 配置.
2.9.2. 应用程序生命周期和探针状态
Kubernetes 探针支持的一个重要方面是它与应用程序生命周期的一致性.
在 AvailabilityState (应用程序的内存内部状态)和暴露该状态的实际 Probe 之间有一个显著的区别: 根据应用程序生命周期的阶段， Probe 可能不可用.
Spring Boot 在启动和关闭期间发布应用程序事件.而 Probes 可以监听此类事件并暴露给 AvailabilityState 信息.
下表显示了 AvailabilityState 和 HTTP 连接器在不同阶段的状态.
当 Spring Boot 应用程序启动时:
| Startup phase | LivenessState | ReadinessState | HTTP server | Notes |
|---|---|---|---|---|
Starting |
|
|
Not started |
Kubernetes 检查 "liveness" Probe，如果时间过长则重新启动应用程序。 |
Started |
|
|
Refuses requests |
应用程序上下文被刷新。 应用程序执行启动任务，但尚未接收流量。 |
Ready |
|
|
Accepts requests |
启动任务完成。 应用程序正在接收流量。 |
当 Spring Boot 应用程序关闭时:
| Shutdown phase | Liveness State | Readiness State | HTTP server | Notes |
|---|---|---|---|---|
Running |
|
|
Accepts requests |
已请求关机。 |
Graceful shutdown |
|
|
New requests are rejected |
|
Shutdown complete |
N/A |
N/A |
Server is shut down |
应用程序上下文关闭，应用程序关闭。 |
| 请查看 Kubernetes 容器生命周期章节,以获取有关 Kubernetes 部署的更多信息. |
2.10. 应用程序信息
应用程序信息暴露从 ApplicationContext 中定义的所有 InfoContributor bean 收集的各种信息. Spring Boot 包含许多自动配置的 InfoContributor bean,你可以编写自己的 bean.
2.10.1. 自动配置的 InfoContributors
适当时,Spring Boot 会自动配置以下 InfoContributor bean:
| ID | Name | Description | Prerequisites |
|---|---|---|---|
|
暴露构建信息 |
A |
|
|
从 |
None. |
|
|
暴露 git 信息. |
A |
|
|
暴露 Java 运行时信息. |
None. |
单个 contributors 是否启用由其 management.info.<id>.enabled 属性控制。 不同的贡献者对此属性有不同的默认值，这取决于他们的先决条件和他们暴露的信息的性质。
没有先决条件表明它们应该被启用，env、和 java contributors 默认是禁用的。 每个都可以通过将其 management.info.env.enabled 属性 或 management.info.java.enabled 设置为 true 来启用。
build 和 git contributor 默认启用。 每个都可以通过将其 management.info.<id>.enabled 属性设置为 false 来禁用。
或者，要禁用通常默认启用的每个 contributor，请将 management.info.defaults.enabled 属性设置为 false。
2.10.2. 自定义应用程序信息
你可以通过设置 info.* 字符串属性来自定义 info 端点暴露的数据. info key 下的所有 Environment 属性都会自动暴露. 例如,你可以将以下设置添加到 application.properties 文件中:
info:
app:
encoding: "UTF-8"
java:
source: "11"
target: "11"|
除了对这些值进行硬编码之外,您还可以在 构建时扩展信息属性. 假设您使用 Maven,则可以按如下所示重写前面的示例: |
2.10.3. Git 提交信息
info 端点的另一个有用功能是它能够在构建项目时发布 git 源码仓库相关的状态的信息. 如果 GitProperties bean 可用,则可以使用 info 端点暴露这些属性.
如果 git.properties 文件在 classpath 的根目录中可用,则会自动配置 GitProperties bean. 有关更多详细信息,请参阅 生成 git 信息.
|
默认情况下,git.branch、git.commit.id 和 git.commit.time 属性 (如果存在) . 如果您不希望端点响应中包含任何这些属性,则需要将它们从 git.properties 文件中排除. 如果要显示完整的 git 信息 (即 git.properties 的完整内容) ,请使用 management.info.git.mode 属性,如下所示:
management:
info:
git:
mode: "full"要完全禁用来自 info 端点的 git commit 信息,请将 management.info.git.enabled 属性设置为 false,如下所示:
management:
info:
git:
enabled: false2.10.4. 构建信息
如果 BuildProperties bean 可用,则 info 端点还可以发布构建相关的信息. 如果 classpath 中有 META-INF/build-info.properties 文件,则会发生这种情况.
| Maven 和 Gradle 插件都可以生成该文件. 有关更多详细信息,请参阅 "生成构建信息". |
2.10.5. Java 信息
info 端点发布有关您的 Java 运行时环境的信息，请参阅 JavaInfo 了解更多详细信息。
2.10.6. 编写自定义 InfoContributors
要提供自定义应用程序信息,可以注册实现 InfoContributor 接口的 Spring bean.
以下示例提供了具有单个值的 example entry:
@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 暴露.
默认约定是使用前缀为 /actuator 的端点的 id 作为 URL 路径. 例如,health 以 /actuator/health 暴露.
| Spring MVC,Spring WebFlux 和 Jersey 本身支持 Actuator. 如果同时提供 Jersey 和 Spring MVC,将使用 Spring MVC. |
3.1. 自定义 Management 端点路径
有时,自定义 management 端点的前缀很有用. 例如,你的应用程序可能已将 /actuator 用于其他目的. 你可以使用 management.endpoints.web.base-path 属性更改 management 端点的前缀,如下所示:
management:
endpoints:
web:
base-path: "/manage"前面的 application.properties 示例将端点从 /actuator/{id} 更改为 /manage/{id} (例如,/manage/info) .
除非已将 management 端口配置为使用 使用其他 HTTP 端口暴露端点,否则 management.endpoints.web.base-path 与 server.servlet.context-path 相关联 (Servlet web applications) 或 spring.webflux.base-path (reactive web applications).
如果配置了 management.server.port,则 management.endpoints.web.base-path 与 management.server.base-path 相关联.
|
如果要将端点映射到其他路径,可以使用 management.endpoints.web.path-mapping 属性.
以下示例将 /actuator/health 重新映射到 /healthcheck:
management:
endpoints:
web:
base-path: "/"
path-mapping:
health: "healthcheck"3.2. 自定义 Management 服务器端口
使用默认 HTTP 端口暴露 management 端点是基于云部署的明智选择. 但是,如果应用程序是在自己的数据中心内运行,你可能更喜欢使用其他 HTTP 端口暴露端点.
你可以设置 management.server.port 属性以更改 HTTP 端口,如下所示:
management:
server:
port: 8081| 在 Cloud Foundry上,默认情况下,应用程序仅在端口 8080 上接收 HTTP 和 TCP 路由请求. 如果要在 Cloud Foundry 上使用自定义管理端口,则需要明确设置应用程序的路由,以将流量转发到自定义端口. |
3.3. 配置 Management 的 SSL
当配置为使用自定义端口时,还可以使用各种 management.server.ssl.* 属性为 management 服务器配置自己的 SSL. 例如,这样做可以在主应用程序使用 HTTPS 时可通过 HTTP 使用 management 服务器,如以下属性设置所示:
server:
port: 8443
ssl:
enabled: true
key-store: "classpath:store.jks"
key-password: "secret"
management:
server:
port: 8080
ssl:
enabled: false或者,主服务器和 management 服务器都可以使用 SSL,但他们的 key store 不同,如下所示:
server:
port: 8443
ssl:
enabled: true
key-store: "classpath:main.jks"
key-password: "secret"
management:
server:
port: 8080
ssl:
enabled: true
key-store: "classpath:management.jks"
key-password: "secret"4. 通过 JMX 监控和管理
Java 管理扩展 (Java Management Extensions,JMX) 提供了一种监控和管理应用程序的标准机制. 默认情况下,此功能未启用,可以通过将配置属性 spring.jmx.enabled 设置为 true 来启用.Spring Boot 将最合适的 MBeanServer 暴露为 ID 为 mbeanServer 的 bean。 使用 Spring JMX 注解（@ManagedResource、@ManagedAttribute 或 @ManagedOperation）注解的任何 bean 都会暴露给它。
如果您的平台提供标准的 MBeanServer，Spring Boot 会使用它并在必要时默认使用 VM 的 MBeanServer。 如果这一切都失败了，则会创建一个新的 MBeanServer``MBeanServer。
有关详细信息，请参阅 JmxAutoConfiguration 类。
默认情况下,Spring Boot 将 management 端点暴露为 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. 通过 HTTP 使用 Jolokia 访问 JMX
Jolokia 是一个 JMX-HTTP 桥,它提供了一种访问 JMX bean 的新方式. 要使用 Jolokia,请引入依赖: org.jolokia:jolokia-core. 例如,使用 Maven,你将添加以下依赖:
<dependency>
<groupId>org.jolokia</groupId>
<artifactId>jolokia-core</artifactId>
</dependency>之后可以通过将 jolokia 或 * 添加到 management.endpoints.web.exposure.include 属性来暴露 Jolokia 端点. 最后,你可以在 management HTTP 服务器上使用 /actuator/jolokia 访问它.
| Jolokia 端点将 Jolokia 的 servlet 公开为 actuator endpoint. 它特定于运行于 Spring MVC 和 Jersey 的 servlet 环境.该端点在 WebFlux 应用程序中将不可用. |
5. Loggers
Spring Boot Actuator 有可在运行时查看和配置应用程序日志级别的功能. 你可以查看全部或单个日志记录器的配置,该配置由显式配置的日志记录级别以及日志记录框架为其提供的有效日志记录级别组成. 这些级别可以是以下之一:
-
TRACE -
DEBUG -
INFO -
WARN -
ERROR -
FATAL -
OFF -
null
null 表示没有显式配置.
6. Metrics(指标)
Spring Boot Actuator 为 Micrometer 提供了依赖管理和自动配置, Micrometer 是一个支持 numerous monitoring systems 的应用程序指标门面,包括:
6.1. 入门
Spring Boot 自动配置了一个组合的 MeterRegistry,并为 classpath 中每个受支持的实现向该组合注册一个注册表. 在运行时,只需要 classpath 中有 micrometer-registry-{system} 依赖即可让 Spring Boot 配置该注册表.
大部分注册表都有共同点 例如,即使 Micrometer 注册实现位于 classpath 上,你也可以禁用特定的注册表. 例如,要禁用 Datadog:
management:
metrics:
export:
datadog:
enabled: false您也可以禁用所有注册表， 除非注册表特定属性另有说明， 如下例所示:
management:
metrics:
export:
defaults:
enabled: falseSpring 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");
}
}
你可以通过指定泛型类型,自定义注册表实现:
@Configuration(proxyBeanMethods = false)
public class MyMeterRegistryConfiguration {
@Bean
public MeterRegistryCustomizer<GraphiteMeterRegistry> graphiteMetricsNamingConvention() {
return (registry) -> registry.config().namingConvention(this::name);
}
private String name(String name, Meter.Type type, String baseUnit) {
return ...
}
}
Spring Boot 还 配置内置的测量工具 ,你可以通过配置或专用注解标记来控制.
6.2. 支持的监控系统
本节简要介绍了每个受支持的监控系统。
6.2.1. AppOptics
默认情况下,AppOptics 注册表会定期将指标推送到 api.appoptics.com/v1/measurements. 要将指标导出到 SaaS AppOptics,你必须提供 API 令牌:
management:
metrics:
export:
appoptics:
api-token: "YOUR_TOKEN"6.2.2. Atlas
management:
metrics:
export:
atlas:
uri: "https://atlas.example.com:7101/api/v1/publish"6.2.3. Datadog
management:
metrics:
export:
datadog:
api-key: "YOUR_KEY"如果您另外提供应用程序密钥（可选），则还将导出 descriptions, types, 和 base units 等元数据：
management:
metrics:
export:
datadog:
api-key: "YOUR_API_KEY"
application-key: "YOUR_APPLICATION_KEY"默认情况下，指标会发送到 Datadog US site (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
Dynatrace 提供了两个获取指标 API，这两个 API 都是为 Micrometer 实现的。
v1 命名空间中的配置属性仅在导出到 Timeseries v1 API 时适用。
v2 命名空间中的配置属性仅在导出到 Metrics v2 API 时适用。
请注意，只能导出 API 的 v1 或 v2 版本。 如果在 v1 命名空间中设置了 device-id（v1 需要但未在 v2 中使用），则指标将导出到 v1 端点。
否则，假定为 v2。
v2 API
您可以通过两种方式使用 v2 API。
如果主机上正在运行本地 OneAgent，则指标会自动导出到 local OneAgent 摄取端点 .默认将获取的端点指标转发到 Dynatrace 后端。 除了依赖 io.micrometer:micrometer-registry-dynatrace 之外不需要特殊设置。
如果没有本地 OneAgent 正在运行，则需要 Metrics v2 API 的端点和 API 令牌。
API token 必须具有“Ingest metrics”（metrics.ingest）权限集。
我们建议将令牌的范围限制为这一权限。 您必须确保端点 URI 包含路径（例如，/api/v2/metrics/ingest）：
Metrics API v2 获取端点的 URL 根据您的部署选项而有所不同：
-
SaaS：
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"
api-token: "YOUR_TOKEN"使用 Dynatrace v2 API 时，可以使用以下可选功能：
-
Metric key prefix：设置一个前缀，添加到所有导出的metric key。
-
使用 Dynatrace 元数据丰富：如果 OneAgent 或 Dynatrace 操作员正在运行，则使用其他元数据（例如，关于主机、进程或 pod）来丰富指标。
-
默认维度：指定添加到所有导出指标的键值对。 如果使用 Micrometer 指定具有相同键的标签，它们会覆盖默认尺寸。
可以不指定 URI 和 API 令牌，如下例所示。 在这种情况下，使用本地 OneAgent 端点：
management:
metrics:
export:
dynatrace:
# Specify uri and api-token here if not using the local OneAgent endpoint.
v2:
metric-key-prefix: "your.key.prefix"
enrich-with-dynatrace-metadata: true
default-dimensions:
key1: "value1"
key2: "value2"v1 API (过时)
Dynatrace v1 API 指标注册表使用 Timeseries v1 API 定期将指标推送到配置的 URI。
为了与现有设置向后兼容，当设置了 device-id（v1 需要，但在 v2 中不使用）时，指标将导出到 Timeseries v1 端点。
要将指标导出到 Dynatrace，必须提供您的 API 令牌、设备 ID 和 URI:
management:
metrics:
export:
dynatrace:
uri: "https://{your-environment-id}.live.dynatrace.com"
api-token: "YOUR_TOKEN"
v1:
device-id: "YOUR_DEVICE_ID"对于 v1 API，您必须指定不带路径的基本环境 URI，因为 v1 端点路径是自动添加的。
与版本无关的设置
除了 API 端点和令牌之外，您还可以更改将指标发送到 Dynatrace 的时间间隔。 默认导出间隔为 60s。 以下示例将导出间隔设置为 30 秒：
management:
metrics:
export:
dynatrace:
step: "30s"您可以在 Micrometer 文档 中找到有关如何为 Micrometer 设置 Dynatrace 导出器的更多信息。
6.2.5. Elastic
默认情况下,指标将导出到本地的 Elastic. 可以使用以下属性提供 Elastic 服务器的位置:e.
management:
metrics:
export:
elastic:
host: "https://elastic.example.com:8086"6.2.6. Ganglia
默认情况下,指标将导出到本地的 Ganglia . 可以使用以下方式提供 Ganglia server 主机和端口:
management:
metrics:
export:
ganglia:
host: "ganglia.example.com"
port: 96496.2.7. Graphite
默认情况下,指标将导出到本地的 Graphite. 可以使用以下方式提供 Graphite server 主机和端口:
management:
metrics:
export:
graphite:
host: "graphite.example.com"
port: 9004Micrometer 提供了一个默认的 HierarchicalNameMapper,它管理维度计数器 id 如何 映射到平面分层名称.
|
要控制此行为,请定义 |
6.2.8. Humio
默认情况下,Humio 注册表会定期将指标推送到 cloud.humio.com. 要将指标导出到 SaaS Humio,你必须提供 API 令牌:
management:
metrics:
export:
humio:
api-token: "YOUR_TOKEN"你还应配置一个或多个标签,以标识要推送指标的数据源:
management:
metrics:
export:
humio:
tags:
alpha: "a"
bravo: "b"6.2.9. Influx
默认情况下,指标将导出到本地运行的 Influx v1 实例 ，要将指标导出到 InfluxDB v2，请配置 org、bucket 和身份验证 token 以编写指标。您可以通过以下方式提供 Influx 服务器 的位置以供使用：
management:
metrics:
export:
influx:
uri: "https://influx.example.com:8086"6.2.10. JMX
Micrometer 提供了与 JMX 的分层映射,主要为了方便在本地查看指标且可移植. 默认情况下,指标将导出到 metrics JMX 域. 可以使用以下方式提供要使用的 domain:
management:
metrics:
export:
jmx:
domain: "com.example.app.metrics"Micrometer 提供了一个默认的 HierarchicalNameMapper,它管理维度计数器 id 如何 映射到平面分层名称.
要控制此行为,请定义 JmxMeterRegistry 并提供自己的 HierarchicalNameMapper. 除非你自己定义,否则使用自动配置的 JmxConfig 和 Clock bean:
|
|
要控制此行为,请定义 |
6.2.11. KairosDB
默认情况下,指标将导出到本地的 KairosDB . 可以使用以下方式提供 KairosDB server 的位置:
management:
metrics:
export:
kairos:
uri: "https://kairosdb.example.com:8080/api/v1/datapoints"6.2.12. New Relic
management:
metrics:
export:
newrelic:
api-key: "YOUR_KEY"
account-id: "YOUR_ACCOUNT_ID"你还可以更改将指标发送到 New Relic 的间隔时间:
management:
metrics:
export:
newrelic:
step: "30s"默认情况下,指标标准是通过 REST 调用发布的,但是如果您在类路径中有 Java Agent API,也可以使用它:
management:
metrics:
export:
newrelic:
client-provider-type: "insights-agent"最后,你可以完全控制你定义的 NewRelicClientProvider bean.
6.2.13. Prometheus
Prometheus 希望抓取或轮询各个应用实例以获取指标数据. Spring Boot 在 /actuator/prometheus 上提供 actuator 端点,以适当的格式呈现 Prometheus scrape.
| 默认情况下端点不可用,必须暴露,请参阅 暴露端点以获取更多详细信息. |
以下是要添加到 prometheus.yml 的示例 scrape_config:
scrape_configs:
- job_name: "spring"
metrics_path: "/actuator/prometheus"
static_configs:
- targets: ["HOST:PORT"]对于短暂的或批处理的工作,其时间可能不够长,无法被废弃,可以使用 Prometheus Pushgateway 支持将其指标暴露给 Prometheus. 要启用 Prometheus Pushgateway 支持,请在项目中添加以下依赖:
<dependency>
<groupId>io.prometheus</groupId>
<artifactId>simpleclient_pushgateway</artifactId>
</dependency>当在类路径上存在 Prometheus Pushgateway 依赖,并且 management.metrics.export.prometheus.pushgateway.enabled 属性为 true,Spring Boot 会自动配置 PrometheusPushGatewayManager bean. 这可以管理将指标推送到 Prometheus Pushgateway
可以使用 management.metrics.export.prometheus.pushgateway 下的属性来调整 PrometheusPushGatewayManager. 对于高级配置,您还可以提供自己的 PrometheusPushGatewayManager bean.
6.2.14. SignalFx
management:
metrics:
export:
signalfx:
access-token: "YOUR_ACCESS_TOKEN"你还可以更改将指标发送到 SignalFx 的间隔时间:
management:
metrics:
export:
signalfx:
step: "30s"6.2.15. Simple
Micrometer 附带一个简单的内存后端,如果没有配置其他注册表,它将自动用作后备. 这使你可以查看 指标端点中收集的指标信息.
只要你使用了任何其他可用的后端,内存后端就会自动禁用. 你也可以显式禁用它:
management:
metrics:
export:
simple:
enabled: false6.2.16. Stackdriver
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
StatsD 注册表将 UDP 上的指标推送到 StatsD 代理. 默认情况下,指标将导出到本地的 StatsD 代理,可以使用以下方式提供 StatsD 代理主机和端口和协议:
management:
metrics:
export:
statsd:
host: "statsd.example.com"
port: 9125
protocol: "udp"你还可以更改要使用的 StatsD 线路协议 (默认为 Datadog) :
management:
metrics:
export:
statsd:
flavor: "etsy"6.2.18. Wavefront
management:
metrics:
export:
wavefront:
api-token: "YOUR_API_TOKEN"或者,你可以在环境中使用 Wavefront sidecar 或内部代理设置,将指标数据转发到 Wavefront API 主机:
management:
metrics:
export:
wavefront:
uri: "proxy://localhost:2878"
如果将指标发布到 Wavefront 代理 (如文档中所述) ,则主机必须采用 proxy://HOST:PORT 格式.
|
你还可以更改将指标发送到 Wavefront 的间隔时间:
management:
metrics:
export:
wavefront:
step: "30s"6.3. 支持的 Metrics 和 Meters
Spring Boot 为多种技术提供自动 meter 注册。 在大多数情况下，默认值提供了可以发布到任何受支持的监控系统的合理指标。
6.3.1. JVM 指标
自动配置通过使用核心 Micrometer 类启用 JVM Metrics。 JVM 指标在 jvm. 名称下发布。
提供了以下 JVM 指标：
-
各种内存和缓冲池
-
与垃圾回收有关的统计
-
线程利用率
-
加载/卸载 class 的数量
6.3.2. System 指标
自动配置通过使用核心 Micrometer 类启用系统指标。 系统指标在 system., process., 和 disk. 名称下发布。
提供了以下系统指标：
-
CPU 指标
-
文件描述符指标
-
正常运行时间 指标: 报告正常运行时间和表示应用程序绝对启动时间的固定计量值
-
可用磁盘空间
6.3.3. 应用启动指标
自动配置暴露应用程序启动时间指标：
-
application.started.time: 启动应用程序所用的时间. -
application.ready.time: 应用程序准备好为请求提供服务所需的时间。.
Metrics 由应用程序类的完全限定名称标记。
6.3.5. 任务执行和调度指标
只要底层的 ThreadPoolExecutor 可用，自动配置就可以检测所有可用的 ThreadPoolTaskExecutor 和 ThreadPoolTaskScheduler bean。
指标由 executor 的名称标记，该名称继承自 bean 名称。
6.3.6. Spring MVC 指标
通过自动配置,可以检测由 Spring MVC 处理的请求. 当 management.metrics.web.server.request.autotime.enabled 为 true 时,将对所有请求进行这种检测. 另外,当设置为 false 时,可以通过将 @Timed 添加到请求处理方法来启用检测:
自动配置启用对 Spring MVC 控制器和功能处理程序处理的所有请求的检测。 默认情况下,使用名称为 http.server.requests 生成指标指标. 可以通过设置 management.metrics.web.server.request.metric-name 属性来自定义名称.
@Controller 类和 @RequestMapping 方法支持 @Timed 注解（详见 @Timed 注解支持）。
如果您不想记录所有 Spring MVC 请求的指标，您可以将 management.metrics.web.server.request.autotime.enabled 设置为 false 并专门使用 @Timed 注解。
默认情况下,Spring MVC 相关指标使用了以下标签标记:
| 标签 | 描述 |
|---|---|
|
处理请求时抛出的异常的简单类名. |
|
请求的方法 (例如, |
|
根据响应状态码生成结果. 1xx 是 |
|
响应的 HTTP 状态码 (例如, |
|
如果可能,在变量替换之前请求 URI 模板 (例如, |
要添加到默认标签,请提供一个或多个实现 WebMvcTagsContributor 的 @Bean. 要替换默认标签,请提供实现 WebMvcTagsProvider 的 @Bean.
提示：在某些情况下，Web 控制器中处理的异常不会记录为 request 指标标签。 应用程序可以通过 将处理的异常设置为 request 属性来选择并记录异常。
6.3.7. Spring WebFlux 指标
自动配置启用了 WebFlux 控制器和函数式处理程序处理的所有请求的指标记录功能. 默认情况下,使用名为 http.server.requests 生成指标. 你可以通过设置 management.metrics.web.server.request.metric-name 属性来自定义名称.
@Controller 类和 @RequestMapping 方法支持 @Timed 注解（详见 @Timed 注解支持）。
如果您不想记录所有 Spring WebFlux 请求的指标，可以将 management.metrics.web.server.request.autotime.enabled 设置为 false 并专门使用 @Timed 注解。
默认情况下,与 WebFlux 相关的指标使用以下标签标记:
| 标签 | 描述 |
|---|---|
|
处理请求时抛出的异常的简单类名. |
|
请求方法 (例如, |
|
根据响应状态码生成请求结果. 1xx 是 |
|
响应的 HTTP 状态码 (例如, |
|
如果可能,在变量替换之前请求 URI 模板 (例如, |
要添加到默认标签,请提供一个或多个实现 WebFluxTagsContributor 的 @Bean. 要替换默认标签,请提供实现 WebFluxTagsProvider 的 @Bean.
| 在某些情况下，控制器和处理程序函数中处理的异常不会记录为 request 指标标签。应用程序可以通过 将处理的异常设置为 request 属性来选择加入并记录异常。 |
6.3.8. Jersey Server 指标
当 Micrometer 的 micrometer-jersey2 模块位于类路径上时,自动配置将启用对Jersey JAX-RS实现所处理的请求的检测. 当 management.metrics.web.server.auto-time-requests 为 true 时,将对所有请求进行该项检测. 当设置为 false 时,你可以通过将 @Timed 添加到请求处理方法上来启用检测:
自动配置支持检测由 Jersey JAX-RS 实现处理的所有请求。 默认情况下，生成的指标名称为 http.server.requests。你可以通过设置 management.metrics.web.server.request.metric-name 属性来自定义名称.
请求处理类和方法支持 @Timed 注解（有关详细信息，请参阅 @Timed 注解支持）。
如果您不想记录所有 Jersey 请求的指标，可以将 management.metrics.web.server.request.autotime.enabled 设置为 false 并专门使用 @Timed 注解。
默认情况下,与 Jersey server 相关的指标使用以下标签标记:
| 标签 | 描述 |
|---|---|
|
处理请求时抛出的异常的简单类名. |
|
请求的方法 (例如, |
|
根据响应状态码生成的请求结果. 1xx 是 |
|
响应的 HTTP 状态码 (例如, |
|
如果可能,在变量替换之前请求 URI 模板 (例如, |
要自定义标签,请提供一个实现了 JerseyTagsProvider 的 @Bean.
6.3.9. HTTP Client 指标
Spring Boot Actuator 管理 RestTemplate 和 WebClient 的指标记录. 为此,你必须注入一个自动配置的 builder 并使用它来创建实例:
-
RestTemplateBuilder用于RestTemplate -
WebClient.Builder用于WebClient
也可以手动指定负责此指标记录的自定义程序,即 MetricsRestTemplateCustomizer 和 MetricsWebClientCustomizer.
默认情况下,使用名为 http.client.requests 生成指标. 可以通过设置 management.metrics.web.client.request.metric-name 属性来自定义名称.
默认情况下,通过检测的客户端生成的指标会标记以下信息:
| 标签 | 描述 |
|---|---|
|
URI 的主机部分 |
|
请求的方法 (例如, |
|
根据响应状态码生成的请求结果. 1xx 是 |
|
响应的 HTTP 状态码 (例如, |
|
如果可能,在变量替换之前请求 URI 模板 (例如, |
要根据你选择的客户端自定义标签,你可以提供一个实现了 RestTemplateExchangeTagsProvider 或 WebClientExchangeTagsProvider 的 @Bean. RestTemplateExchangeTags 和 WebClientExchangeTags 中有便捷的静态函数.
6.3.10. Tomcat 指标
自动配置仅在启用 MBeanRegistry 时启用 Tomcat 的检测。
默认情况下，MBeanRegistry 被禁用，但您可以通过将 server.tomcat.mbeanregistry.enabled 设置为 true 来启用它。
Tomcat 指标在 tomcat. 名称下发布。
6.3.11. Cache 指标
在启动时,自动配置启动所有可用 Cache 的指标记录功能,指标以 cache 为前缀. 缓存指标记录针对一组基本指标进行了标准化. 此外,还提供了缓存特定的指标.
支持以下缓存库:
-
Caffeine
-
EhCache 2
-
Hazelcast
-
所有兼容 JCache (JSR-107) 的实现
-
Redis
指标由缓存的名称和从 bean 名称扩展的 CacheManager 的名称标记.
只有启动时可用的缓存才会绑定到注册表. 对于未在缓存配置中定义的缓存,例如在启动阶段之后以编程方式创建的缓存,需要显式注册. 可用 CacheMetricsRegistrar bean 简化该过程.
|
6.3.12. DataSource 指标
通过自动配置,可以使用前缀为 jdbc.connections 的指标来检测所有可用的 DataSource 对象. 数据源指标记录会生成表示池中当前 active 、大允许和最小允许连接的计量器 (gauge) . 指标还标记有基于 bean 名称计算的 DataSource 名称.
指标也由基于 bean 名称计算的 DataSource 的名称标记.
默认情况下,Spring Boot 为所有支持的数据源提供了元数据. 如果开箱即用不支持你喜欢的数据源,则可以添加其他 DataSourcePoolMetadataProvider bean. 有关示例,请参阅 DataSourcePoolMetadataProvidersConfiguration.
|
此外,Hikari 特定的指标用 hikaricp 前缀暴露. 每个指标都由池名称标记 (可以使用 spring.datasource.name 控制) .
6.3.13. Hibernate 指标
如果 org.hibernate:hibernate-micrometer 在类路径上，则自动配置启用所有可用 Hibernate EntityManagerFactory 实例的指标记录功能,这些实例使用名为 hibernate 的指标统计信息.
指标也由从 bean 名称扩展的 EntityManagerFactory 的名称标记.
要启用信息统计,必须将标准 JPA 属性 hibernate.generate_statistics 设置为 true. 你可以在自动配置的 EntityManagerFactory 上启用它,如下所示:
spring:
jpa:
properties:
"[hibernate.generate_statistics]": true6.3.14. Spring Data Repository 指标
自动配置启用所有 Spring Data Repository 方法调用的检测。 默认情况下，生成的指标名称为 spring.data.repository.invocations。
您可以通过设置 management.metrics.data.repository.metric-name 属性来自定义名称。
Repository 类和方法支持 @Timed 注解（详见 @Timed 注解支持>）。
如果您不想记录所有 Repository 调用的指标，可以将 management.metrics.data.repository.autotime.enabled 设置为 false 并专门使用 @Timed 注解。
默认情况下，与 repository 调用相关的指标标记有以下信息:
| 标签 | 描述 |
|---|---|
|
简单的`Repository` 类名. |
|
调用 |
|
结果状态 ( |
|
从调用中引发的任何异常的简单类名。 |
要替换默认标签，请提供一个实现 RepositoryTagsProvider 的 @Bean。
6.3.16. Spring Integration 指标
当 MeterRegistry bean 可用时，Spring Integration 都会自动提供 Micrometer support。 指标以 spring.integration. 名称发布。
6.3.17. Kafka 指标
自动配置将分别为消费者工厂和生产者工厂注册 MicrometerConsumerListener 和 MicrometerProducerListener. 它还将为 StreamsBuilderFactoryBean 注册一个 KafkaStreamsMicrometerListener. 有关更多详细信息,请参阅 Spring Kafka 文档的 Micrometer Native Metrics 部分.
6.3.18. MongoDB 指标
本节简要介绍 MongoDB 的可用指标。
MongoDB 命令行 指标
自动配置通过自动配置的 MongoClient 注册一个 MongoMetricsCommandListener。
为发出给底层 MongoDB 驱动程序的每个命令创建一个名为 mongodb.driver.commands 的计时器指标。 默认情况下，每个指标都标记有以下信息：
| 标签 | 描述 |
|---|---|
|
命令名 |
|
命令发送到的集群的标识符。 |
|
命令发送到的服务器的地址。 |
|
命令输出 ( |
要替换默认的指标标签，请定义一个 MongoCommandTagsProvider bean，如以下示例所示：
@Configuration(proxyBeanMethods = false)
public class MyCommandTagsProviderConfiguration {
@Bean
public MongoCommandTagsProvider customCommandTagsProvider() {
return new CustomCommandTagsProvider();
}
}
要禁用自动配置的命令指标，请设置以下属性：
management:
metrics:
mongo:
command:
enabled: falseMongoDB Connection Pool 指标
自动配置通过自动配置的 MongoClient 注册一个 MongoMetricsConnectionPoolListener。
为连接池创建了以下计量指标：
-
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: false6.3.19. Jetty 指标
自动配置通过使用 Micrometer 的 JettyServerThreadPoolMetrics 为 Jetty 的 ThreadPool 绑定指标。
Jetty 的 Connector 实例的指标是通过使用 Micrometer 的 JettyConnectionMetrics 绑定的，当 server.ssl.enabled 设置为 true 时，Micrometer 的 JettySslHandshakeMetrics。
6.3.20. @Timed 注解支持
您可以将 io.micrometer.core.annotation 包中的 @Timed 注解与前面描述的几种支持的技术一起使用。
如果支持，您可以在类级别或方法级别使用注解。
例如，以下代码展示了如何使用注解来检测 @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 ...
}
}
带有 longTask = true 的 @Timed 注解为该方法启用了一个长任务计时器。 长任务计时器需要一个单独的指标名称，并且可以与短任务计时器叠加。
|
6.3.21. Redis 指标
自动配置为自动配置的 LettuceConnectionFactory 注册一个 MicrometerCommandLatencyRecorder。
有关更多详细信息，请参阅 Lettuce 文档的 Micrometer Metrics section。
6.4. Registering Custom Metrics
要注册自定义指标,请将 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 {
@Bean
public MeterBinder queueSize(Queue queue) {
return (registry) -> Gauge.builder("queueSize", queue::size).register(registry);
}
}
使用 MeterBinder 可以确保设置正确的依赖关系,并且在获取指标值时 Bean 可用. 默认情况下,所有 MeterBinder bean 的指标都将自动绑定到 Spring 管理的 MeterRegistry. 如果你发现跨组件或应用程序重复记录一套指标,则 MeterBinder 实现也可能很有用.
默认情况下，来自所有 MeterBinder bean 的指标会自动绑定到 Spring 管理的 MeterRegistry。
|
6.5. 自定义单个指标
如果需要将自定义应用于特定的 Meter 实例,则可以使用 io.micrometer.core.instrument.config.MeterFilter 接口.
例如,如果要将所有以 com.example 开头的仪表ID的 mytag.region 标签重命名为 mytag.area,则可以执行以下操作:
@Configuration(proxyBeanMethods = false)
public class MyMetricsFilterConfiguration {
@Bean
public MeterFilter renameRegionTagMeterFilter() {
return MeterFilter.renameTag("com.example", "mytag.region", "mytag.area");
}
}
默认情况下，所有 MeterFilter bean 都自动绑定到 Spring 管理的 MeterRegistry。 确保使用 Spring 管理的 MeterRegistry 而不是 Metrics 上的任何静态方法来注册您的指标。 这些使用非 Spring 管理的全局注册表。
|
6.5.1. 常用标签
通用标签通常用于在操作环境 (如主机,实例,区域,堆栈等) 上进行维度深入分析. 通用标签适用于所有仪表,并可以按以下示例所示进行配置:
management:
metrics:
tags:
region: "us-east-1"
stack: "prod"上面的示例将 region 和 stack 标签添加到所有 meter 中,其值分别为 us-east-1 和 prod.
如果你使用 Graphite,那么标签的顺序很重要. 由于使用此方法无法保证通用标签的顺序,因此建议 Graphite 用户定义自定义 MeterFilter.
|
6.5.2. Per-meter 属性
除了 MeterFilter bean 之外,还可以使用 properties 在 per-meter 基础上自定义. Per-meter 定义适用于以给定名称开头的所有 meter ID. 例如,以下将禁用任何以 example.remote 开头的 ID 的 meter:
management:
metrics:
enable:
example:
remote: false以下属性允许 per-meter 自定义:
| 属性 | 描述 |
|---|---|
|
是否拒绝 meter 发布任何指标. |
|
是否发布一个适用于计算可聚合 (跨维度) 的百分比近似柱状图. |
|
通过限制预期值的范围来发布较少的柱状图桶. |
|
发布在你自己的应用程序中计算的百分比数值 |
|
通过在可配置的到期后旋转的环形缓冲区中累积最近的样本，赋予它们更大的权重，具有可配置的缓冲区长度。 |
|
发布包含服务级别目标定义的存储区的累积直方图. |
有关 percentiles-histogram、percentiles 和 slo 概念的更多详细信息,请参阅 "柱状图与百分位数" 部分的文档.
6.6. 指标端点
Spring Boot 提供了一个 metrics 端点,可以在诊断中用于检查应用程序收集的指标. 默认情况下端点不可用,必须手动暴露,请参阅 暴露端点以获取更多详细信息.
访问 /actuator/metrics 会显示可用的 meter 名称列表. 你可以查看某一个 meter 的信息,方法是将其名称作为选择器,例如,/actuator/metrics/jvm.memory.max.
|
你在此处使用的名称应与代码中使用的名称相匹配,而不是在命名约定规范化后的名称 —— 为了发送到监控系统.
换句话说,如果 |
你还可以在 URL 的末尾添加任意数量的 tag=KEY:VALUE 查询参数,以便多维度向下钻取 meter,例如 /actuator/metrics/jvm.memory.max?tag=area:nonheap.
|
报告的测量值是与 meter 名称和已应用的任何标签匹配的所有 meter 的统计数据的总和. 因此,在上面的示例中,返回的 |
7. 审计
一旦 Spring Security 生效,Spring Boot Actuator 就拥有一个灵活的审计框架,它可以发布事件 (默认情况下,“authentication success”, “failure” 和 “access denied” 例外) . 此功能对事件报告和基于身份验证失败实现一个锁定策略非常有用.
可以通过在应用程序的配置中提供类型为 AuditEventRepository 的 bean 来启用审计. 为了方便起见,Spring Boot提供了一个 InMemoryAuditEventRepository. InMemoryAuditEventRepository 具有有限的功能,我们建议仅将其用于开发环境. 对于生产环境,请考虑创建自己的替代 AuditEventRepository 实现.
8. HTTP 追踪
可以通过在应用程序的配置中提供 HttpTraceRepository 类型的 Bean 来启用 HTTP 跟踪. 为了方便起见,Spring Boot默认提供了一个 InMemoryHttpTraceRepository,用于存储最近 100 次请求-响应交换的跟踪.
与其他跟踪解决方案相比,InMemoryHttpTraceRepository 受到限制,我们建议仅将其用于开发环境. 对于生产环境,建议使用可用于生产的跟踪或可观察性解决方案,例如 Zipkin 或 Spring Cloud Sleuth. 或者,创建自己的 HttpTraceRepository 来满足您的需求.
httptrace 端点可用于获取有关存储在 HttpTraceRepository 中的请求-响应交换的信息.
9. 进程监控
在 spring-boot 模块中,你可以找到两个类来创建文件,他们通常用于进程监控:
-
ApplicationPidFileWriter创建一个包含应用程序 PID 的文件 (默认在应用程序目录中,文件名为application.pid) . -
WebServerPortFileWriter创建一个或多个文件,其包含正在运行的 Web 服务器的端口 (默认在应用程序目录中,文件名为application.port) .
默认情况下,这些 writer 未激活,但你可以启用:
10. Cloud Foundry 支持
当你部署到一个兼容 Cloud Foundry 的实例时,Spring Boot 的 Actuator 模块包含的其他支持将被激活. /cloudfoundryapplication 路径为所有 @Endpoint bean 提供了另外一个安全路由.
该扩展支持允许使用 Spring Boot Actuator 信息扩充 Cloud Foundry 管理 UI (例如可用于查看已部署应用的 Web 应用) . 比如,应用程序状态页面可以包括完整的健康信息而不是常见的 “running” 或 “stopped” 状态.
常规用户无法直接访问 /cloudfoundryapplication 路径. 为了能访问端点,你必须在请求时传递一个有效的 UAA 令牌.
|
10.1. 禁用 Cloud Foundry Actuator 扩展支持
如果要完全禁用 /cloudfoundryapplication 端点,可以将以下设置添加到 application.properties 文件中:
management:
cloudfoundry:
enabled: false10.2. Cloud Foundry 自签名证书
默认情况下,/cloudfoundryapplication 端点的安全验证会对各种 Cloud Foundry 服务进行 SSL 调用. 如果你的 Cloud Foundry UAA 或 Cloud Controller 服务使用自签名证书,则需要设置以下属性:
management:
cloudfoundry:
skip-ssl-validation: true10.3. 自定义上下文路径
如果服务器的 context-path 已配置为 / 以外的其他内容,则 Cloud Foundry 端点将无法在应用程序的根目录中使用. 例如,如果 server.servlet.context-path=/app,Cloud Foundry 端点将在 /app/cloudfoundryapplication/* 上可用.
如果你希望 Cloud Foundry 端点始终在 /cloudfoundryapplication/* 上可用,则无论服务器的 context-path 如何,你都需要在应用程序中明确配置它. 配置因使用的 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("/*");
};
}
}