生产就绪功能
1. 启用生产就绪功能
这spring-boot-actuator模块提供了 Spring Boot 的所有生产就绪功能。
启用这些功能的推荐方法是添加对spring-boot-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. 端点
执行器端点允许您监控应用程序并与之交互。
Spring Boot 包括许多内置端点，并允许您添加自己的端点。
例如，health端点提供基本的应用程序运行状况信息。
您可以启用或禁用每个单独的端点，并通过 HTTP 或 JMX 公开它们（使其可远程访问）。
当终结点同时启用和公开时，它被视为可用。
内置终结点仅在可用时才自动配置。
大多数应用程序选择通过 HTTP 进行公开，其中终结点的 ID 和前缀/actuator映射到 URL。
例如，默认情况下，healthendpoint 映射到/actuator/health.
以下与技术无关的终结点可用：
| 身份证 | 描述 |
|---|---|
|
公开当前应用程序的审核事件信息。
需要 |
|
显示应用程序中所有 Spring Bean 的完整列表。 |
|
公开可用缓存。 |
|
显示对配置类和自动配置类进行评估的条件，以及它们匹配或不匹配的原因。 |
|
显示所有 |
|
公开 Spring 的 |
|
显示已应用的任何 Flyway 数据库迁移。
需要一个或多个 |
|
显示应用程序运行状况信息。 |
|
显示 HTTP 交换信息（默认情况下，最近 100 个 HTTP 请求-响应交换）。
需要 |
|
显示任意应用程序信息。 |
|
显示 Spring Integration 图。
需要依赖于 |
|
显示和修改应用程序中记录器的配置。 |
|
显示已应用的任何 Liquibase 数据库迁移。
需要一个或多个 |
|
显示当前应用程序的“指标”信息。 |
|
显示所有 |
|
显示有关 Quartz Scheduler 作业的信息。 需要消毒。 |
|
显示应用程序中的计划任务。 |
|
允许从 Spring Session 支持的会话存储中检索和删除用户会话。 需要使用 Spring Session 的基于 servlet 的 Web 应用程序。 |
|
允许正常关闭应用程序。 仅在使用罐装时有效。 默认禁用。 |
|
显示由 |
|
执行线程转储。 |
如果您的应用程序是 Web 应用程序（Spring MVC、Spring WebFlux 或 Jersey），则可以使用以下其他端点：
| 身份证 | 描述 |
|---|---|
|
返回堆转储文件。
在 HotSpot JVM 上，一个 |
|
返回日志文件的内容（如果 |
|
以 Prometheus 服务器可抓取的格式公开指标。需要依赖于 |
2.1. 启用端点
默认情况下，除shutdown已启用。要配置端点的启用，请使用其management.endpoint.<id>.enabled财产。 以下示例启用shutdown端点：
management.endpoint.shutdown.enabled=truemanagement:
endpoint:
shutdown:
enabled: true如果您希望终端启用是选择加入而不是选择退出，请将management.endpoints.enabled-by-default属性设置为false并使用单个端点enabled属性以重新选择加入。以下示例启用info端点并禁用所有其他端点：
management.endpoints.enabled-by-default=false
management.endpoint.info.enabled=truemanagement:
endpoints:
enabled-by-default: false
endpoint:
info:
enabled: true禁用的端点将从应用程序上下文中完全删除。如果只想更改公开端点的技术，请使用include和exclude性能相反。 |
2.2. 公开端点
默认情况下，只有运行状况终结点通过 HTTP 和 JMX 公开。由于终结点可能包含敏感信息，因此应仔细考虑何时公开它们。
若要更改要公开的终结点，请使用以下特定于技术的include和exclude性能：
| 属性 | 默认值 |
|---|---|
|
|
|
|
|
|
|
|
这include属性列出了公开的端点的 ID。
这exclude属性列出了不应公开的端点的 ID。
这exclude属性优先于include财产。
您可以配置include和exclude属性，其中包含端点 ID 列表。
例如，要仅公开health和infoendpoints over JMX，请使用以下属性：
management.endpoints.jmx.exposure.include=health,infomanagement:
endpoints:
jmx:
exposure:
include: "health,info"*可用于选择所有端点。
例如，要通过 HTTP 公开除env和beansendpoints，请使用以下属性：
management.endpoints.web.exposure.include=*
management.endpoints.web.exposure.exclude=env,beansmanagement:
endpoints:
web:
exposure:
include: "*"
exclude: "env,beans"
*在 YAML 中具有特殊含义，因此如果要包含（或排除）所有端点，请务必添加引号。 |
| 如果应用程序公开，强烈建议同时保护终结点。 |
如果要在端点公开时实现自己的策略，可以注册EndpointFilter豆。 |
2.3. 安全性
出于安全考虑，只有/health默认情况下，端点通过 HTTP 公开。
您可以使用management.endpoints.web.exposure.include属性来配置公开的端点。
在设置management.endpoints.web.exposure.include，确保公开的执行器不包含敏感信息，通过将它们放置在防火墙后面来保护，或者由 Spring Security 之类的东西保护。 |
如果 Spring Security 在类路径上并且没有其他SecurityFilterChainbean 存在，除/health由 Spring Boot 自动配置保护。
如果定义自定义SecurityFilterChainbean，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.securityMatcher(EndpointRequest.toAnyEndpoint());
http.authorizeHttpRequests((requests) -> requests.anyRequest().hasRole("ENDPOINT_ADMIN"));
http.httpBasic(withDefaults());
return http.build();
}
}
@Configuration(proxyBeanMethods = false)
class MySecurityConfiguration {
@Bean
fun securityFilterChain(http: HttpSecurity): SecurityFilterChain {
http.securityMatcher(EndpointRequest.toAnyEndpoint()).authorizeHttpRequests { 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=*management:
endpoints:
web:
exposure:
include: "*"此外，如果存在 Spring Security，则需要添加自定义安全配置，允许对端点进行未经身份验证的访问，如以下示例所示：
@Configuration(proxyBeanMethods = false)
public class MySecurityConfiguration {
@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
http.securityMatcher(EndpointRequest.toAnyEndpoint());
http.authorizeHttpRequests((requests) -> requests.anyRequest().permitAll());
return http.build();
}
}
@Configuration(proxyBeanMethods = false)
class MySecurityConfiguration {
@Bean
fun securityFilterChain(http: HttpSecurity): SecurityFilterChain {
http.securityMatcher(EndpointRequest.toAnyEndpoint()).authorizeHttpRequests { requests ->
requests.anyRequest().permitAll()
}
return http.build()
}
}
在上述两个示例中，配置仅适用于执行器端点。
由于 Spring Boot 的安全配置在存在任何SecurityFilterChainbean，您需要配置一个额外的SecurityFilterChainbean 具有适用于应用程序其余部分的规则。 |
2.3.1. 跨站请求伪造保护
由于 Spring Boot 依赖于 Spring Security 的默认值，因此默认情况下打开 CSRF 保护。
这意味着需要POST（关闭和记录器端点），一个PUT或DELETE使用默认安全配置时，收到 403（禁止）错误。
| 我们建议仅在创建由非浏览器客户端使用的服务时完全禁用 CSRF 保护。 |
您可以在 Spring Security 参考指南中找到有关 CSRF 保护的其他信息。
2.4. 配置端点
端点会自动缓存对不采用任何参数的读取作的响应。
要配置端点缓存响应的时间量，请使用其cache.time-to-live财产。
以下示例设置beans端点的缓存到 10 秒：
management.endpoint.beans.cache.time-to-live=10smanagement:
endpoint:
beans:
cache:
time-to-live: "10s"这management.endpoint.<name>prefix 唯一标识正在配置的终结点。 |
2.5. 清理敏感值
返回的信息/env,/configprops和/quartz端点可能是敏感的，因此默认情况下，值始终完全清理（替换为 ）。******
只有在以下情况下，才能以未经清理的形式查看值：
-
这
show-values属性已设置为NEVER -
无自定义
SanitizingFunctionBeans应用
这show-values可以为可清理的端点配置为以下值之一：
-
NEVER- 值始终完全清理（替换为******) -
ALWAYS- 向所有用户显示值（只要没有SanitizingFunctionbean 适用） -
WHEN_AUTHORIZED- 值仅向授权用户显示（只要没有SanitizingFunctionbean 适用）
对于 HTTP 端点，如果用户已进行身份验证并具有由端点的 roles 属性配置的角色，则该用户被视为已授权。 默认情况下，任何经过身份验证的用户都是授权的。
对于 JMX 端点，所有用户始终获得授权。
以下示例允许所有使用adminrole 从/env端点的原始形式。
未经授权的用户，或没有adminrole，将仅看到经过清理的值。
management.endpoint.env.show-values=WHEN_AUTHORIZED
management.endpoint.env.roles=adminmanagement:
endpoint:
env:
show-values: WHEN_AUTHORIZED
roles: "admin"此示例假设没有SanitizingFunctionbean 已被定义。 |
2.6. 执行器 Web 端点的超介质
将添加一个“发现页面”，其中包含指向所有端点的链接。
“发现页面”可在/actuator默认情况下。
若要禁用“发现页”，请将以下属性添加到应用程序属性：
management.endpoints.web.discovery.enabled=falsemanagement:
endpoints:
web:
discovery:
enabled: false配置自定义管理上下文路径后，“发现页面”会自动从/actuator到管理上下文的根目录。例如，如果管理上下文路径为/management，则发现页面可从/management. 当管理上下文路径设置为 时，将禁用发现页面，以防止与其他映射发生冲突的可能性。/
2.7. 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,POSTmanagement:
endpoints:
web:
cors:
allowed-origins: "https://example.com"
allowed-methods: "GET,POST"看CorsEndpointProperties获取完整的选项列表。 |
2.8. 实现自定义端点
如果您添加@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);
}
@ReadOperation
fun getData(): CustomData {
return CustomData("test", 5)
}
您还可以使用@JmxEndpoint或@WebEndpoint.
这些端点仅限于各自的技术。
例如@WebEndpoint仅通过 HTTP 公开，而不是通过 JMX。
您可以使用以下命令编写特定于技术的扩展@EndpointWebExtension和@EndpointJmxExtension.
这些注释允许您提供特定于技术的作来扩充现有端点。
最后，如果您需要访问特定于 Web 框架的功能，您可以实现 servlet 或 Spring@Controller和@RestController端点的代价是它们无法通过 JMX 或使用不同的 Web 框架时使用。
2.8.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
}
@WriteOperation
fun updateData(name: String?, counter: Int) {
// injects "test" and 42
}
由于终结点与技术无关，因此只能在方法签名中指定简单类型。
特别是，使用CustomData定义name和counter不支持属性。 |
为了让输入映射到作方法的参数，实现端点的 Java 代码应该使用-parameters，并且实现端点的 Kotlin 代码应使用-java-parameters.
如果您使用 Spring Boot 的 Gradle 插件或使用 Maven 和spring-boot-starter-parent. |
2.8.2. 自定义 Web 端点
对@Endpoint,@WebEndpoint或@EndpointWebExtension使用 Jersey、Spring MVC 或 Spring WebFlux 通过 HTTP 自动公开。
如果 Jersey 和 Spring MVC 都可用，则使用 Spring MVC。
路径
谓词的路径由端点的 ID 和 Web 公开的端点的基本路径确定。
默认基本路径为/actuator.
例如，ID 为sessions使用/actuator/sessions作为谓词中的路径。
您可以通过在作方法的一个或多个参数上添加注释来进一步自定义路径@Selector.
此类参数将作为路径变量添加到路径谓词中。
调用端点作时，变量的值将传递到作方法中。
如果要捕获所有剩余的路径元素，可以将@Selector(Match=ALL_REMAINING)添加到最后一个参数，并使其成为与String[].
HTTP 方法
谓词的HTTP方法由作类型决定，如下表所示：
| 操作 | HTTP 方法 |
|---|---|
|
|
|
|
|
|
消耗
对于一个@WriteOperation（HTTPPOST）使用请求正文的consumes谓词的子句是application/vnd.spring-boot.actuator.v2+json, application/json.
对于所有其他作，consumes子句为空。
生产
这produces谓词的子句可以由produces属性的@DeleteOperation,@ReadOperation和@WriteOperation附注。 该属性是可选的。如果不使用它，则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（正常）。如果它不返回值，则响应状态将为 404（未找到）。
如果@WriteOperation或@DeleteOperation返回一个值，响应状态将为 200（正常）。如果它不返回值，则响应状态将为 204（无内容）。
如果调用作时没有必需参数或参数无法转换为所需类型，则不会调用作方法，响应状态将为 400（错误请求）。
2.9. 健康信息
您可以使用运行状况信息来检查正在运行的应用程序的状态。
监控软件通常使用它来在生产系统出现故障时向某人发出警报。
由healthendpoint 依赖于management.endpoint.health.show-details和management.endpoint.health.show-components属性，可以使用以下值之一进行配置：
| 名称 | 描述 |
|---|---|
|
从不显示详细信息。 |
|
详细信息仅显示给授权用户。可以使用 |
|
详细信息将显示给所有用户。 |
默认值为never. 当用户处于一个或多个端点的角色时，该用户被视为已授权。如果端点没有配置角色（默认），则所有经过身份验证的用户都被视为已授权。您可以使用management.endpoint.health.roles财产。
如果您已保护您的应用程序并希望使用always，则安全配置必须允许经过身份验证和未经身份验证的用户访问运行状况终结点。 |
健康信息是从HealthContributorRegistry（默认情况下，所有HealthContributor在ApplicationContext). Spring Boot 包括许多自动配置的HealthContributors，您也可以编写自己的。
一个HealthContributor可以是HealthIndicator或CompositeHealthContributor. 一个HealthIndicator提供实际的健康信息，包括Status. 一个CompositeHealthContributor提供其他HealthContributors. 总之，参与者形成一个树结构来表示整个系统运行状况。
默认情况下，最终系统运行状况由StatusAggregator，它对每个HealthIndicator基于状态的有序列表。排序列表中的第一个状态用作整体运行状况。如果没有HealthIndicator返回已知的状态StatusAggregator一UNKNOWN状态。
您可以使用HealthContributorRegistry在运行时注册和注销运行状况指标。 |
2.9.1. 自动配置的 HealthIndicators
在适当的时候，Spring Boot 会自动配置HealthIndicators如下表所示。
您还可以通过配置来启用或禁用选定的指标management.health.key.enabled,
使用key如下表所示：
| 钥匙 | 名称 | 描述 |
|---|---|---|
|
检查 Cassandra 数据库是否已启动。 |
|
|
检查 Couchbase 集群是否已启动。 |
|
|
检查与 |
|
|
检查磁盘空间不足。 |
|
|
检查 Elasticsearch 集群是否已启动。 |
|
|
检查 Hazelcast 服务器是否已启动。 |
|
|
检查 InfluxDB 服务器是否已启动。 |
|
|
检查 JMS 代理是否已启动。 |
|
|
检查 LDAP 服务器是否已启动。 |
|
|
检查邮件服务器是否已启动。 |
|
|
检查 Mongo 数据库是否已启动。 |
|
|
检查 Neo4j 数据库是否已启动。 |
|
|
始终以 |
|
|
检查 Rabbit 服务器是否已启动。 |
|
|
检查 Redis 服务器是否已启动。 |
您可以通过设置management.health.defaults.enabled财产。 |
附加HealthIndicators可用，但默认情况下未启用：
| 钥匙 | 名称 | 描述 |
|---|---|---|
|
公开“活动”应用程序可用性状态。 |
|
|
公开“就绪”应用程序可用性状态。 |
2.9.2. 编写自定义 HealthIndicators
要提供自定义运行状况信息，您可以注册实现HealthIndicator接口。 您需要提供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 ...
}
}
@Component
class MyHealthIndicator : HealthIndicator {
override fun health(): Health {
val errorCode = check()
if (errorCode != 0) {
return Health.down().withDetail("Error Code", errorCode).build()
}
return Health.up().build()
}
private fun check(): Int {
// perform some specific health check
return ...
}
}
给定的标识符HealthIndicator是 bean 的名称，不带HealthIndicator后缀，如果存在。
在前面的示例中，运行状况信息在名为my. |
运行状况指示器通常通过 HTTP 调用，需要在任何连接超时之前做出响应。
Spring Boot 将记录任何响应时间超过 10 秒的运行状况指示器的警告消息。
如果要配置此阈值，可以使用management.endpoint.health.logging.slow-indicator-threshold财产。 |
除了 Spring Boot 的预定义Status类型Health可以返回自定义Status这代表一种新的系统状态。
在这种情况下，您还需要提供StatusAggregator接口，或者您必须使用management.endpoint.health.status.orderconfiguration 属性。
例如，假设新的Status代码为FATAL正在您的一个HealthIndicator实现。
要配置严重性顺序，请将以下属性添加到应用程序属性：
management.endpoint.health.status.order=fatal,down,out-of-service,unknown,upmanagement:
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=503management:
endpoint:
health:
status:
http-mapping:
down: 503
fatal: 503
out-of-service: 503如果您需要更多控制，可以定义自己的控制HttpCodeStatusMapper豆。 |
下表显示了内置状态的默认状态映射：
| 地位 | 映射 |
|---|---|
|
|
|
|
|
默认情况下没有映射，因此 HTTP 状态为 |
|
默认情况下没有映射，因此 HTTP 状态为 |
2.9.3. 反应性健康指标
对于响应式应用程序，例如那些使用 Spring WebFlux 的应用程序，ReactiveHealthContributor提供用于获取应用程序运行状况的非阻塞协定。
类似于传统的HealthContributor，健康信息是从ReactiveHealthContributorRegistry（默认情况下，所有HealthContributor和ReactiveHealthContributor在ApplicationContext).
定期HealthContributors不检查响应式 API 的 API 在弹性调度程序上执行。
在响应式应用程序中，您应该使用ReactiveHealthContributorRegistry在运行时注册和注销运行状况指标。
如果您需要注册常规HealthContributor，你应该用ReactiveHealthContributor#adapt. |
要从响应式 API 提供自定义运行状况信息，您可以注册实现ReactiveHealthIndicator接口。
以下代码显示了一个示例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 ...
}
}
@Component
class MyReactiveHealthIndicator : ReactiveHealthIndicator {
override fun health(): Mono<Health> {
return doHealthCheck()!!.onErrorResume { exception: Throwable? ->
Mono.just(Health.Builder().down(exception).build())
}
}
private fun doHealthCheck(): Mono<Health>? {
// perform some specific health check
return ...
}
}
要自动处理错误，请考虑从AbstractReactiveHealthIndicator. |
2.9.4. 自动配置的 ReactiveHealthIndicators
在适当的情况下，Spring Boot 会自动配置以下内容ReactiveHealthIndicators:
| 钥匙 | 名称 | 描述 |
|---|---|---|
|
检查 Cassandra 数据库是否已启动。 |
|
|
检查 Couchbase 集群是否已启动。 |
|
|
检查 Elasticsearch 集群是否已启动。 |
|
|
检查 Mongo 数据库是否已启动。 |
|
|
检查 Neo4j 数据库是否已启动。 |
|
|
检查 Redis 服务器是否已启动。 |
如有必要，反应指示器取代常规指示器。
此外，任何HealthIndicator未显式处理的自动包装。 |
2.9.5. 健康组
有时将健康指标组织成可用于不同目的的组很有用。
要创建运行状况指示器组，您可以使用management.endpoint.health.group.<name>属性，并指定运行状况指示器 ID 列表，以include或exclude.
例如，要创建仅包含数据库指示器的组，您可以定义以下内容：
management.endpoint.health.group.custom.include=dbmanagement:
endpoint:
health:
group:
custom:
include: "db"然后您可以通过点击localhost:8080/actuator/health/custom.
同样，要创建一个从组中排除数据库指示器并包括所有其他指示器的组，您可以定义以下内容：
management.endpoint.health.group.custom.exclude=dbmanagement:
endpoint:
health:
group:
custom:
exclude: "db"默认情况下，如果运行状况组包含或排除不存在的运行状况指示器，则启动将失败。
要禁用此行为，请management.endpoint.health.validate-group-membership自false.
默认情况下，组继承相同的StatusAggregator和HttpCodeStatusMapper设置作为系统运行状况。
但是，您也可以按组定义这些值。
您还可以覆盖show-details和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=500management:
endpoint:
health:
group:
custom:
show-details: "when-authorized"
roles: "admin"
status:
order: "fatal,up"
http-mapping:
fatal: 500
out-of-service: 500您可以使用@Qualifier("groupname")如果您需要注册自定义StatusAggregator或HttpCodeStatusMapper用于组的豆子。 |
运行状况组还可以包含/排除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.10. Kubernetes 探针
部署在 Kubernetes 上的应用程序可以使用容器探针提供有关其内部状态的信息。 根据您的 Kubernetes 配置，kubelet 会调用这些探针并对结果做出反应。
默认情况下，Spring Boot 管理应用程序可用性状态。
如果部署在 Kubernetes 环境中，执行器会从ApplicationAvailability接口，并在专用的运行状况指标中使用该信息：LivenessStateHealthIndicator和ReadinessStateHealthIndicator.
这些指示器显示在全局运行状况终结点 （"/actuator/health").
它们还通过使用运行状况组作为单独的 HTTP 探测公开："/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>应设置为执行器端点可用的端口。
它可以是主 Web 服务器端口，也可以是单独的管理端口，如果"management.server.port"属性已设置。 |
仅当应用程序在 Kubernetes 环境中运行时，才会自动启用这些运行状况组。
您可以使用management.endpoint.health.probes.enabledconfiguration 属性。
如果应用程序启动时间超过配置的活跃期，Kubernetes 会提到"startupProbe"作为可能的解决方案。
一般来说，"startupProbe"这里不一定需要，因为"readinessProbe"失败，直到所有启动任务完成。
这意味着您的应用程序在准备就绪之前不会接收流量。
但是，如果您的应用程序需要很长时间才能启动，请考虑使用"startupProbe"以确保 Kubernetes 不会在应用程序启动过程中终止您的应用程序。
请参阅描述探测在应用程序生命周期中如何运行的部分。 |
如果执行器端点部署在单独的管理上下文中，则端点不会使用与主应用程序相同的 Web 基础结构（端口、连接池、框架组件）。
在这种情况下，即使主应用程序无法正常工作（例如，它无法接受新连接），探测检查也可能成功。
因此，最好将liveness和readiness主服务器端口上可用的运行状况组。
这可以通过设置以下属性来完成：
management.endpoint.health.probes.add-additional-paths=true这将使liveness团体可在以下位置购买/livez和readiness团体可在以下位置购买/readyz在主服务器端口上。
可以使用additional-path属性，请参阅运行状况组了解详细信息。
2.10.1. 使用 Kubernetes 探针检查外部状态
执行器将“活动”和“就绪”探测配置为运行状况组。 这意味着所有运行状况组功能都可供他们使用。 例如，您可以配置其他运行状况指示器：
management.endpoint.health.group.readiness.include=readinessState,customCheckmanagement:
endpoint:
health:
group:
readiness:
include: "readinessState,customCheck"默认情况下，Spring Boot 不会向这些组添加其他健康指标。
“活跃度”探测不应依赖于外部系统的运行状况检查。 如果应用程序的活跃状态被破坏，Kubernetes 会尝试通过重新启动应用程序实例来解决该问题。 这意味着，如果外部系统（例如数据库、Web API 或外部缓存）发生故障，Kubernetes 可能会重新启动所有应用程序实例并产生级联故障。
至于“就绪”探测，应用程序开发人员必须仔细选择检查外部系统。 因此，Spring Boot 在就绪情况探测中不包含任何其他健康检查。 如果应用程序实例的就绪状态为“未就绪”，则 Kubernetes 不会将流量路由到该实例。 某些外部系统可能不由应用程序实例共享，在这种情况下，它们可以包含在就绪性探测中。 其他外部系统可能对应用程序不是必需的（应用程序可能具有断路器和回退），在这种情况下，它们绝对不应该包含在内。 遗憾的是，所有应用程序实例共享的外部系统很常见，您必须进行判断调用：将其包含在就绪探测中，并期望在外部服务关闭时应用程序停止服务，或者将其排除在外并处理堆栈上层的故障，也许是在调用者中使用断路器。
如果应用程序的所有实例都未就绪，则具有type=ClusterIP或NodePort不接受任何传入连接。
没有 HTTP 错误响应（503 等），因为没有连接。
一项服务type=LoadBalancer可能接受也可能不接受连接，具体取决于提供商。
具有显式入口的服务也会以依赖于实现的方式进行响应——入口服务本身必须决定如何处理来自下游的“拒绝连接”。
HTTP 503 很可能在负载均衡器和入口的情况下出现。 |
此外，如果应用程序使用 Kubernetes 自动缩放，则它可能会对从负载均衡器中取出的应用程序做出不同的反应，具体取决于其自动缩放器配置。
2.10.2. 应用程序生命周期和探测状态
Kubernetes 探针支持的一个重要方面是它与应用程序生命周期的一致性。
之间存在显着差异AvailabilityState（即应用程序的内存内部状态）
以及实际的探针（暴露了该状态）。
根据应用程序生命周期的阶段，探测可能不可用。
Spring Boot 在启动和关闭期间发布应用程序事件，并且探针可以监听此类事件并公开AvailabilityState信息。
下表显示了AvailabilityState以及不同阶段的 HTTP 连接器状态。
当 Spring Boot 应用程序启动时：
| 启动阶段 | LivenessState | 就绪状态 | HTTP 服务器 | 笔记 |
|---|---|---|---|---|
开始 |
|
|
未开始 |
Kubernetes 会检查“活动性”探针，如果时间过长，则重新启动应用程序。 |
开始 |
|
|
拒绝请求 |
应用程序上下文将刷新。应用程序执行启动任务，但尚未接收流量。 |
准备 |
|
|
接受请求 |
启动任务已完成。应用程序正在接收流量。 |
当 Spring Boot 应用程序关闭时：
| 关机阶段 | 活跃状态 | 就绪状态 | HTTP 服务器 | 笔记 |
|---|---|---|---|---|
运行 |
|
|
接受请求 |
已请求关闭。 |
正常关机 |
|
|
新请求被拒绝 |
如果启用，则正常关闭会处理正在进行的请求。 |
关机完成 |
不适用 |
不适用 |
服务器已关闭 |
应用程序上下文已关闭，应用程序已关闭。 |
| 有关 Kubernetes 部署的更多信息，请参阅 Kubernetes 容器生命周期部分。 |
2.11. 应用信息
应用程序信息公开从所有InfoContributorbean 在ApplicationContext.
Spring Boot 包括许多自动配置的InfoContributorbean，你可以自己写。
2.11.1. 自动配置的 InfoContributors
在适当的情况下，Spring 会自动配置以下内容InfoContributor豆：
| 身份证 | 名称 | 描述 | 前提条件 |
|---|---|---|---|
|
公开生成信息。 |
一个 |
|
|
从 |
没有。 |
|
|
公开 git 信息。 |
一个 |
|
|
公开 Java 运行时信息。 |
没有。 |
|
|
公开作系统信息。 |
没有。 |
是否启用单个贡献者由其控制management.info.<id>.enabled财产。 不同的参与者对此属性有不同的默认值，具体取决于其前提条件和他们公开的信息的性质。
由于没有前提条件来指示应启用它们，因此env,java和os默认情况下，贡献者处于禁用状态。可以通过设置其management.info.<id>.enabled属性设置为true.
这build和git信息贡献者默认启用。可以通过设置其management.info.<id>.enabled属性设置为false. 或者，要禁用通常默认启用的每个贡献者，请将management.info.defaults.enabled属性设置为false.
2.11.2. 自定义应用程序信息
当envcontributor 启用后，您可以自定义infoendpoint 通过设置info.*弹簧属性。
都Environment属性下的info键会自动公开。
例如，您可以将以下设置添加到application.properties文件：
info.app.encoding=UTF-8
info.app.java.source=17
info.app.java.target=17info:
app:
encoding: "UTF-8"
java:
source: "17"
target: "17"|
除了对这些值进行硬编码，您还可以在构建时扩展信息属性。 假设您使用 Maven，您可以重写前面的示例，如下所示： 亚姆尔
|
2.11.3. Git 提交信息
另一个有用的功能infoendpoint 是它发布有关您的状态的信息的能力git生成项目时的源代码存储库。
如果GitPropertiesbean 可用，您可以使用infoendpoint 来公开这些属性。
一个GitProperties如果git.properties文件位于类路径的根目录中。
有关更多详细信息，请参阅“如何生成 git 信息”。 |
默认情况下，终结点会公开git.branch,git.commit.id和git.commit.time属性（如果存在）。
如果您不希望在端点响应中包含任何这些属性，则需要将它们从git.properties文件。
如果要显示完整的 git 信息（即git.properties），使用management.info.git.mode属性，如下所示：
management.info.git.mode=fullmanagement:
info:
git:
mode: "full"要从infoendpoint 完全，请将management.info.git.enabled属性设置为false如下：
management.info.git.enabled=falsemanagement:
info:
git:
enabled: false2.11.4. 构建信息
如果BuildPropertiesbean 可用，则infoendpoint 还可以发布有关您的构建的信息。
如果META-INF/build-info.properties文件在类路径中可用。
| Maven 和 Gradle 插件都可以生成该文件。 有关更多详细信息，请参阅“如何生成构建信息”。 |
2.11.5. Java 信息
这infoendpoint 发布有关 Java 运行时环境的信息，请参阅JavaInfo了解更多详情。
2.11.6.作系统信息
这infoendpoint 发布有关您的作系统的信息，请参阅OsInfo了解更多详情。
2.11.7. 编写自定义 InfoContributors
要提供自定义应用程序信息，您可以注册实现InfoContributor接口。
以下示例贡献了example条目：
@Component
public class MyInfoContributor implements InfoContributor {
@Override
public void contribute(Info.Builder builder) {
builder.withDetail("example", Collections.singletonMap("key", "value"));
}
}
@Component
class MyInfoContributor : InfoContributor {
override fun contribute(builder: Info.Builder) {
builder.withDetail("example", Collections.singletonMap("key", "value"))
}
}
如果您达到infoendpoint，您应该会看到包含以下附加条目的响应：
{
"example": {
"key" : "value"
}
}3. 通过 HTTP 进行监控和管理
如果您正在开发 Web 应用程序，Spring Boot Actuator 会自动配置所有已启用的端点以通过 HTTP 公开。
默认约定是使用id前缀为/actuator作为 URL 路径。
例如health公开为/actuator/health.
| Spring MVC、Spring WebFlux 和 Jersey 原生支持 Actuator。 如果 Jersey 和 Spring MVC 都可用，则使用 Spring MVC。 |
3.1. 自定义管理端点路径
有时，自定义管理端点的前缀很有用。
例如，您的应用程序可能已经使用/actuator为了另一个目的。
您可以使用management.endpoints.web.base-path属性来更改管理终结点的前缀，如以下示例所示：
management.endpoints.web.base-path=/managemanagement:
endpoints:
web:
base-path: "/manage"前面的application.properties示例将端点从/actuator/{id}自/manage/{id}（例如，/manage/info).
除非管理端口已配置为使用不同的 HTTP 端口公开端点，management.endpoints.web.base-path相对于server.servlet.context-path（对于 servlet Web 应用程序）或spring.webflux.base-path（对于响应式 Web 应用程序）。
如果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=/
management.endpoints.web.path-mapping.health=healthcheckmanagement:
endpoints:
web:
base-path: "/"
path-mapping:
health: "healthcheck"3.2. 自定义管理服务器端口
使用默认 HTTP 端口公开管理终结点是基于云的部署的明智选择。 但是，如果您的应用程序在您自己的数据中心内运行，您可能更愿意使用不同的 HTTP 端口来公开端点。
您可以将management.server.port属性来更改 HTTP 端口，如以下示例所示：
management.server.port=8081management:
server:
port: 8081| 在 Cloud Foundry 上，默认情况下，应用程序仅在端口 8080 上接收 HTTP 和 TCP 路由的请求。 如果要在 Cloud Foundry 上使用自定义管理端口，则需要显式设置应用程序的路由，以将流量转发到自定义端口。 |
3.3. 配置特定于管理的SSL
当配置为使用自定义端口时，您还可以使用各种management.server.ssl.*性能。
例如，这样做可以让管理服务器通过 HTTP 可用，而主应用程序使用 HTTPS，如以下属性设置所示：
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=falseserver:
port: 8443
ssl:
enabled: true
key-store: "classpath:store.jks"
key-password: "secret"
management:
server:
port: 8080
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=secretserver:
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 管理扩展 （JMX） 提供了一种标准机制来监视和管理应用程序。
默认情况下，此功能未启用。
您可以通过设置spring.jmx.enabled配置属性设置为true.
Spring Boot 暴露最合适的MBeanServer作为 ID 为mbeanServer.
任何使用 Spring JMX 注释（@ManagedResource,@ManagedAttribute或@ManagedOperation）暴露于其中。
如果您的平台提供标准MBeanServer，Spring Boot 使用它并默认为 VMMBeanServer，如有必要。
如果所有这些都失败了，则新的MBeanServer被创建。
spring.jmx.enabled仅影响 Spring 提供的管理 Bean。
启用其他库（例如 Log4j2 或 Quartz）提供的管理 Bean 是独立的。 |
请参阅JmxAutoConfigurationclass 了解更多详情。
默认情况下，Spring Boot 还将管理端点公开为 JMX MBeanorg.springframework.boot域。
要完全控制 JMX 域中的端点注册，请考虑注册您自己的端点EndpointObjectNameFactory实现。
4.1. 自定义MBean名称
MBean 的名称通常从id的端点。
例如，healthendpoint 公开为org.springframework.boot:type=Endpoint,name=Health.
如果您的应用程序包含多个 SpringApplicationContext，您可能会发现名称冲突。
要解决此问题，您可以将spring.jmx.unique-names属性设置为true因此 MBean 名称始终是唯一的。
您还可以自定义在下公开端点的 JMX 域。
以下设置显示了在application.properties:
spring.jmx.unique-names=true
management.endpoints.jmx.domain=com.example.myappspring:
jmx:
unique-names: true
management:
endpoints:
jmx:
domain: "com.example.myapp"5. 可观测性
可观测性是从外部观察运行系统内部状态的能力。 它由三个支柱组成：日志记录、指标和跟踪。
对于指标和跟踪，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
});
}
}
| 低基数标记将添加到指标和跟踪中，而高基数标记将仅添加到跟踪中。 |
Beans类型ObservationPredicate,GlobalObservationConvention,ObservationFilter和ObservationHandler将自动注册在ObservationRegistry.
您可以额外注册任意数量的ObservationRegistryCustomizerbean 来进一步配置注册表。
可观测性支持依赖于上下文传播库跨线程和响应式管道转发当前观察。
默认情况下，ThreadLocal值不会在响应式运算符中自动恢复。
此行为由spring.reactor.context-propagation属性，可以设置为auto以启用自动传播。
有关观测的更多详细信息，请参阅千分尺观测文档。
| JDBC 的可观测性可以使用单独的项目进行配置。 Datasource Micrometer 项目提供了一个 Spring Boot Starters，它在调用 JDBC作时自动创建观察结果。 在参考文档中阅读有关它的更多信息。 |
R2DBC 的可观测性内置于 Spring Boot 中。
要启用它，请将io.r2dbc:r2dbc-proxy依赖项目。 |
5.1. 常用标签
通用标签一般用于对运行环境进行维度下钻，如主机、实例、地域、堆栈等。 通用标记作为低基数标记应用于所有观测值，并且可以进行配置，如以下示例所示：
management.observations.key-values.region=us-east-1
management.observations.key-values.stack=prodmanagement:
observations:
key-values:
region: "us-east-1"
stack: "prod"前面的示例将region和stack标记添加到值为us-east-1和prod分别。
5.2. 防止观察
如果要阻止报告某些观察结果，可以使用management.observations.enable性能：
management.observations.enable.denied.prefix=false
management.observations.enable.another.denied.prefix=falsemanagement:
observations:
enable:
denied:
prefix: false
another:
denied:
prefix: false前面的示例将阻止名称以denied.prefix或another.denied.prefix.
如果要阻止 Spring Security 报告观察结果，请将属性management.observations.enable.spring.security自false. |
如果您需要更好地控制观察的预防，您可以注册类型为ObservationPredicate.
仅当所有ObservationPredicate豆子返回true为了那个观察。
@Component
class MyObservationPredicate implements ObservationPredicate {
@Override
public boolean test(String name, Context context) {
return !name.contains("denied");
}
}
前面的示例将阻止名称包含“denied”的所有观察。
5.3. OpenTelemetry 支持
| 有多种方法可以在应用程序中支持 OpenTelemetry。 您可以使用 OpenTelemetry Java 代理或 OpenTelemetry Spring Boot Starter， 由 OTel 社区支持;指标和跟踪使用OTel库定义的语义约定。 本文档描述了 Spring 团队使用 Micrometer 和 OTLP 导出器正式支持的 OpenTelemetry; 指标和跟踪使用 Spring 项目文档中描述的语义约定，例如 Spring Framework。 |
Spring Boot 的执行器模块包括对 OpenTelemetry 的基本支持。
它提供了一种类型的 beanOpenTelemetry，如果存在类型SdkTracerProvider,ContextPropagators,SdkLoggerProvider或SdkMeterProvider在应用程序上下文中，它们会自动注册。
此外，它还提供了一个Resource豆。
自动配置的属性Resource可以通过management.opentelemetry.resource-attributesconfiguration 属性。
如果您已经定义了自己的Resourcebean，情况将不再如此。
| Spring Boot 不提供 OpenTelemetry 指标或日志记录的自动配置。 OpenTelemetry 跟踪仅在与 Micrometer Tracking 一起使用时自动配置。 |
接下来的部分将提供有关日志记录、指标和跟踪的更多详细信息。
6. 记录仪
Spring Boot Actuator 包括在运行时查看和配置应用程序日志级别的功能。 您可以查看整个列表或单个记录器的配置，该配置由显式配置的日志记录级别以及日志记录框架给出的有效日志记录级别组成。 这些级别可以是以下级别之一：
-
TRACE -
DEBUG -
INFO -
WARN -
ERROR -
FATAL -
OFF -
null
null表示没有显式配置。
7. 计量指标
Spring Boot Actuator 为 Micrometer 提供依赖管理和自动配置，Micrometer 是一种支持众多监控系统的应用程序指标外观，包括：
7.1. 开始使用
Spring Boot 自动配置复合MeterRegistry并为它在类路径上找到的每个受支持的实现向复合添加一个注册表。
依赖于micrometer-registry-{system}足以让 Spring Boot 配置注册表。
大多数注册管理机构具有共同的功能。 例如，即使 Micrometer 注册表实现在类路径上，您也可以禁用特定的注册表。 以下示例禁用 Datadog：
management.datadog.metrics.export.enabled=falsemanagement:
datadog:
metrics:
export:
enabled: false您还可以禁用所有注册表，除非特定于注册表的属性另有说明，如以下示例所示：
management.defaults.metrics.export.enabled=falsemanagement:
defaults:
metrics:
export:
enabled: falseSpring Boot 还会将任何自动配置的注册表添加到Metrics类，除非你明确告诉它不要：
management.metrics.use-global-registry=falsemanagement:
metrics:
use-global-registry: false您可以注册任意数量的MeterRegistryCustomizerbean 以进一步配置注册表，例如在向注册表注册任何仪表注册之前应用通用标签：
@Configuration(proxyBeanMethods = false)
public class MyMeterRegistryConfiguration {
@Bean
public MeterRegistryCustomizer<MeterRegistry> metricsCommonTags() {
return (registry) -> registry.config().commonTags("region", "us-east-1");
}
}
@Configuration(proxyBeanMethods = false)
class MyMeterRegistryConfiguration {
@Bean
fun metricsCommonTags(): MeterRegistryCustomizer<MeterRegistry> {
return MeterRegistryCustomizer { 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 ...
}
}
@Configuration(proxyBeanMethods = false)
class MyMeterRegistryConfiguration {
@Bean
fun graphiteMetricsNamingConvention(): MeterRegistryCustomizer<GraphiteMeterRegistry> {
return MeterRegistryCustomizer { registry: GraphiteMeterRegistry ->
registry.config().namingConvention(this::name)
}
}
private fun name(name: String, type: Meter.Type, baseUnit: String?): String {
return ...
}
}
Spring Boot 还配置了内置检测，您可以通过配置或专用注释标记进行控制。
7.2. 支持的监控系统
本节简要介绍每个受支持的监控系统。
7.2.1. 应用光学
默认情况下，AppOptics 注册表会定期将指标推送到api.appoptics.com/v1/measurements.
要将指标导出到 SaaS AppOptics，必须提供您的 API Tokens：
management.appoptics.metrics.export.api-token=YOUR_TOKENmanagement:
appoptics:
metrics:
export:
api-token: "YOUR_TOKEN"7.2.2. 地图集
management.atlas.metrics.export.uri=https://atlas.example.com:7101/api/v1/publishmanagement:
atlas:
metrics:
export:
uri: "https://atlas.example.com:7101/api/v1/publish"7.2.3. 数据狗
management.datadog.metrics.export.api-key=YOUR_KEYmanagement:
datadog:
metrics:
export:
api-key: "YOUR_KEY"如果另外提供应用程序密钥（可选），则还将导出计量说明、类型和基本单位等元数据：
management.datadog.metrics.export.api-key=YOUR_API_KEY
management.datadog.metrics.export.application-key=YOUR_APPLICATION_KEYmanagement:
datadog:
metrics:
export:
api-key: "YOUR_API_KEY"
application-key: "YOUR_APPLICATION_KEY"默认情况下，指标被发送到 Datadog US 站点 (api.datadoghq.com).
如果您的 Datadog 项目托管在其他站点之一上，或者您需要通过代理发送指标，请相应地配置 URI：
management.datadog.metrics.export.uri=https://api.datadoghq.eumanagement:
datadog:
metrics:
export:
uri: "https://api.datadoghq.eu"您还可以更改将指标发送到 Datadog 的时间间隔：
management.datadog.metrics.export.step=30smanagement:
datadog:
metrics:
export:
step: "30s"7.2.4. Dynatrace
Dynatrace 提供了两个指标摄取 API，这两个 API 都是为 Micrometer 实现的。
您可以在此处找到有关 Micrometer 指标摄取的 Dynatrace 文档。
配置属性中的v1命名空间仅在导出到 Timeseries v1 API 时适用。
配置属性中的v2命名空间仅在导出到 Metrics v2 API 时适用。
请注意，此集成只能导出到v1或v2API 版本，使用v2是首选。
如果device-id（v1 需要，但在 v2 中不使用）在v1命名空间，则指标将导出到v1端点。
否则v2被假设。
v2 API
您可以通过两种方式使用 v2 API。
自动配置
Dynatrace 自动配置适用于由 OneAgent 或 Dynatrace Operator for Kubernetes 监控的主机。
本地 OneAgent：如果主机上正在运行 OneAgent，则指标会自动导出到本地 OneAgent 摄取端点。 摄取端点将指标转发到 Dynatrace 后端。
Dynatrace Kubernetes Operator：在安装了 Dynatrace Operator 的 Kubernetes 中运行时，注册表将自动从操作员那里获取您的端点 URI 和 API Tokens。
这是默认行为，除了依赖io.micrometer:micrometer-registry-dynatrace.
手动配置
如果没有可用的自动配置，则需要指标 v2 API 的端点和 API Tokens。API Tokens必须具有“引入指标”（metrics.ingest） 权限集。我们建议将Tokens的范围限制为此一个权限。您必须确保终端节点 URI 包含路径（例如，/api/v2/metrics/ingest):
指标 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.dynatrace.metrics.export.uri=https://example.live.dynatrace.com/api/v2/metrics/ingest
management.dynatrace.metrics.export.api-token=YOUR_TOKENmanagement:
dynatrace:
metrics:
export:
uri: "https://example.live.dynatrace.com/api/v2/metrics/ingest"
api-token: "YOUR_TOKEN"使用 Dynatrace v2 API 时，可以使用以下可选功能（更多详细信息可以在 Dynatrace 文档中找到）：
-
指标键前缀：设置前缀，该前缀附加到所有导出的指标键。
-
使用 Dynatrace 元数据进行扩充：如果 OneAgent 或 Dynatrace 运算符正在运行，请使用其他元数据（例如，关于主机、进程或 Pod）来扩充指标。
-
默认维度：指定添加到所有导出指标的键值对。如果使用 Micrometer 指定具有相同键的标记，它们将覆盖默认维度。
-
使用 Dynatrace 摘要工具：在某些情况下，Micrometer Dynatrace 注册表创建的指标被拒绝。在 Micrometer 1.9.x 中，通过引入特定于 Dynatrace 的摘要工具修复了此问题。将此切换设置为
false强制 Micrometer 回退到 1.9.x 之前的默认行为。只有在从 Micrometer 1.8.x 迁移到 1.9.x 时遇到问题时才应使用它。 -
导出仪表元数据：从 Micrometer 1.12.0 开始，Dynatrace 导出器还将默认导出仪表元数据，例如单位和描述。 使用
export-meter-metadata切换以关闭此功能。
可以不指定 URI 和 API Tokens，如以下示例所示。在此方案中，使用自动配置的终结点：
management.dynatrace.metrics.export.v2.metric-key-prefix=your.key.prefix
management.dynatrace.metrics.export.v2.enrich-with-dynatrace-metadata=true
management.dynatrace.metrics.export.v2.default-dimensions.key1=value1
management.dynatrace.metrics.export.v2.default-dimensions.key2=value2
management.dynatrace.metrics.export.v2.use-dynatrace-summary-instruments=true
management.dynatrace.metrics.export.v2.export-meter-metadata=truemanagement:
dynatrace:
metrics:
export:
# 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"
use-dynatrace-summary-instruments: true # (default: true)
export-meter-metadata: true # (default: true)v1 API（旧版）
Dynatrace v1 API 指标注册表使用 Timeseries v1 API 定期将指标推送到配置的 URI。
为了向后兼容现有设置，当device-id设置为（v1 需要，但在 v2 中不使用），则指标将导出到 Timeseries v1 终结点。
要将指标导出到 Dynatrace，必须提供您的 API Tokens、设备 ID 和 URI：
management.dynatrace.metrics.export.uri=https://{your-environment-id}.live.dynatrace.com
management.dynatrace.metrics.export.api-token=YOUR_TOKEN
management.dynatrace.metrics.export.v1.device-id=YOUR_DEVICE_IDmanagement:
dynatrace:
metrics:
export:
uri: "https://{your-environment-id}.live.dynatrace.com"
api-token: "YOUR_TOKEN"
v1:
device-id: "YOUR_DEVICE_ID"对于 v1 API，必须指定不带路径的基本环境 URI，因为 v1 终结点路径是自动添加的。
与版本无关的设置
除了 API 端点和Tokens之外，您还可以更改将指标发送到 Dynatrace 的时间间隔。
默认导出间隔为60s.
以下示例将导出间隔设置为 30 秒：
management.dynatrace.metrics.export.step=30smanagement:
dynatrace:
metrics:
export:
step: "30s"您可以在 Micrometer 文档和 Dynatrace 文档中找到有关如何为 Micrometer 设置 Dynatrace 导出器的更多信息。
7.2.5. 弹性
默认情况下，指标将导出到本地计算机上运行的 Elastic。 您可以使用以下属性提供要使用的弹性服务器的位置：
management.elastic.metrics.export.host=https://elastic.example.com:8086management:
elastic:
metrics:
export:
host: "https://elastic.example.com:8086"7.2.6. 神经节
默认情况下，指标将导出到本地计算机上运行的 Ganglia。 您可以提供 Ganglia 服务器主机和端口，如以下示例所示：
management.ganglia.metrics.export.host=ganglia.example.com
management.ganglia.metrics.export.port=9649management:
ganglia:
metrics:
export:
host: "ganglia.example.com"
port: 96497.2.7. 石墨
默认情况下，指标将导出到本地计算机上运行的 Graphite。 您可以提供 Graphite 服务器主机和端口，如以下示例所示：
management.graphite.metrics.export.host=graphite.example.com
management.graphite.metrics.export.port=9004management:
graphite:
metrics:
export:
host: "graphite.example.com"
port: 9004Micrometer 提供默认的HierarchicalNameMapper控制如何将维度计 ID 映射到平面分层名称。
|
要控制此行为，请定义您的 Java
Kotlin
|
7.2.8. 腐殖
默认情况下，Humio 注册表会定期将指标推送到 cloud.humio.com。 要将指标导出到 SaaS Humio，您必须提供 API Tokens：
management.humio.metrics.export.api-token=YOUR_TOKENmanagement:
humio:
metrics:
export:
api-token: "YOUR_TOKEN"还应配置一个或多个标记，以标识将指标推送到的数据源：
management.humio.metrics.export.tags.alpha=a
management.humio.metrics.export.tags.bravo=bmanagement:
humio:
metrics:
export:
tags:
alpha: "a"
bravo: "b"7.2.9. 涌入
默认情况下，指标将导出到具有默认配置的本地计算机上运行的 Influx v1 实例。
要将指标导出到 InfluxDB v2，请配置org,bucket和身份验证token用于编写指标。
您可以使用以下方法提供要使用的 Influx 服务器的位置：
management.influx.metrics.export.uri=https://influx.example.com:8086management:
influx:
metrics:
export:
uri: "https://influx.example.com:8086"7.2.10. JMX
Micrometer 提供了与 JMX 的分层映射，主要作为一种廉价且可移植的方式在本地查看指标。
默认情况下，指标将导出到metricsJMX 域。
您可以使用以下方法提供要使用的域：
management.jmx.metrics.export.domain=com.example.app.metricsmanagement:
jmx:
metrics:
export:
domain: "com.example.app.metrics"Micrometer 提供默认的HierarchicalNameMapper控制如何将维度计 ID 映射到平面分层名称。
|
要控制此行为，请定义您的 Java
Kotlin
|
7.2.11. 凯罗斯数据库
默认情况下，指标将导出到本地计算机上运行的 KairosDB。您可以使用以下方法提供要使用的 KairosDB 服务器的位置：
management.kairos.metrics.export.uri=https://kairosdb.example.com:8080/api/v1/datapointsmanagement:
kairos:
metrics:
export:
uri: "https://kairosdb.example.com:8080/api/v1/datapoints"7.2.12. 新遗迹
management.newrelic.metrics.export.api-key=YOUR_KEY
management.newrelic.metrics.export.account-id=YOUR_ACCOUNT_IDmanagement:
newrelic:
metrics:
export:
api-key: "YOUR_KEY"
account-id: "YOUR_ACCOUNT_ID"您还可以更改将指标发送到 New Relic 的时间间隔：
management.newrelic.metrics.export.step=30smanagement:
newrelic:
metrics:
export:
step: "30s"默认情况下，指标通过 REST 调用发布，但如果 Java Agent API 位于类路径上，也可以使用它：
management.newrelic.metrics.export.client-provider-type=insights-agentmanagement:
newrelic:
metrics:
export:
client-provider-type: "insights-agent"最后，您可以通过定义自己的NewRelicClientProvider豆。
7.2.13. OpenTelemetry
默认情况下，指标将导出到本地计算机上运行的 OpenTelemetry。 可以使用以下方法提供要使用的 OpenTelemetry 指标终结点的位置：
management.otlp.metrics.export.url=https://otlp.example.com:4318/v1/metricsmanagement:
otlp:
metrics:
export:
url: "https://otlp.example.com:4318/v1/metrics"7.2.14. 普罗米修斯
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 Exemplars。
要启用此功能，请SpanContextSupplier豆子应该存在。
如果您使用千分尺追踪，这将为您自动配置，但如果您愿意，您可以随时创建自己的追踪。
请查看 Prometheus 文档，因为该功能需要在 Prometheus 端显式启用，并且仅支持 OpenMetrics 格式。
对于可能存在时间不够长而无法抓取的临时或批处理作业，您可以使用 Prometheus Pushgateway 支持将指标公开给 Prometheus。 要启用 Prometheus Pushgateway 支持，请向项目添加以下依赖项：
<dependency>
<groupId>io.prometheus</groupId>
<artifactId>simpleclient_pushgateway</artifactId>
</dependency>当 Prometheus Pushgateway 依赖项存在于类路径上并且management.prometheus.metrics.export.pushgateway.enabled属性设置为true一个PrometheusPushGatewayManagerbean 是自动配置的。
这管理将指标推送到 Prometheus Pushgateway。
您可以调整PrometheusPushGatewayManager通过使用management.prometheus.metrics.export.pushgateway.
对于高级配置，您还可以提供自己的配置PrometheusPushGatewayManager豆。
7.2.15. 信号FX
management.signalfx.metrics.export.access-token=YOUR_ACCESS_TOKENmanagement:
signalfx:
metrics:
export:
access-token: "YOUR_ACCESS_TOKEN"您还可以更改将指标发送到 SignalFx 的时间间隔：
management.signalfx.metrics.export.step=30smanagement:
signalfx:
metrics:
export:
step: "30s"7.2.16. 简单
Micrometer 附带了一个简单的内存中后端，如果没有配置其他注册表，则会自动将其用作回退。 这样，您就可以查看指标端点中收集了哪些指标。
一旦您使用任何其他可用后端，内存中后端就会自行禁用。 您也可以显式禁用它：
management.simple.metrics.export.enabled=falsemanagement:
simple:
metrics:
export:
enabled: false7.2.17. 堆栈驱动程序
Stackdriver 注册表会定期将指标推送到 Stackdriver。 要将指标导出到 SaaS Stackdriver，您必须提供您的 Google Cloud 项目 ID：
management.stackdriver.metrics.export.project-id=my-projectmanagement:
stackdriver:
metrics:
export:
project-id: "my-project"您还可以更改将指标发送到 Stackdriver 的时间间隔：
management.stackdriver.metrics.export.step=30smanagement:
stackdriver:
metrics:
export:
step: "30s"7.2.18. 统计D
StatsD 注册表急切地通过 UDP 将指标推送到 StatsD 代理。 默认情况下，指标将导出到本地计算机上运行的 StatsD 代理。 您可以使用以下方法提供要使用的 StatsD 代理主机、端口和协议：
management.statsd.metrics.export.host=statsd.example.com
management.statsd.metrics.export.port=9125
management.statsd.metrics.export.protocol=udpmanagement:
statsd:
metrics:
export:
host: "statsd.example.com"
port: 9125
protocol: "udp"您还可以更改要使用的 StatsD 线协议（默认为 Datadog）：
management.statsd.metrics.export.flavor=etsymanagement:
statsd:
metrics:
export:
flavor: "etsy"7.2.19. 波前
management.wavefront.api-token=YOUR_API_TOKENmanagement:
wavefront:
api-token: "YOUR_API_TOKEN"或者，您可以使用环境中的 Wavefront Sidecar 或内部代理将指标数据转发到 Wavefront API 主机：
management.wavefront.uri=proxy://localhost:2878management:
wavefront:
uri: "proxy://localhost:2878"如果您将指标发布到 Wavefront 代理（如 Wavefront 文档中所述），则主机必须位于proxy://HOST:PORT格式。 |
您还可以更改将指标发送到 Wavefront 的时间间隔：
management.wavefront.metrics.export.step=30smanagement:
wavefront:
metrics:
export:
step: "30s"7.3. 支持的指标和仪表
Spring Boot 为各种技术提供自动仪表注册。 在大多数情况下，默认值提供了合理的指标，可以发布到任何受支持的监控系统。
7.3.1. JVM 指标
自动配置通过使用核心 Micrometer 类启用 JVM 指标。JVM 指标发布在jvm.仪表名称。
提供了以下 JVM 指标：
-
各种内存和缓冲池详细信息
-
与垃圾回收相关的统计信息
-
线程利用率
-
加载和卸载的类数
-
JVM 版本信息
-
JIT 编译时间
7.3.2. 系统指标
自动配置通过使用核心 Micrometer 类启用系统度量。
系统指标发布在system.,process.和disk.仪表名称。
提供以下系统指标：
-
CPU 指标
-
文件描述符指标
-
正常运行时间指标（应用程序运行的时间量和绝对启动时间的固定指标）
-
可用磁盘空间
7.3.3. 应用程序启动指标
自动配置公开应用程序启动时间指标：
-
application.started.time：启动应用程序所花费的时间。 -
application.ready.time：应用程序准备好处理请求所花费的时间。
指标由应用程序类的完全限定名称标记。
7.3.5. 任务执行和调度指标
自动配置支持所有可用仪器ThreadPoolTaskExecutor和ThreadPoolTaskScheduler豆子，只要下属ThreadPoolExecutor可用。
指标由执行器的名称标记，该名称派生自 Bean 名称。
7.3.6. JMS 指标
自动配置支持所有可用仪器JmsTemplatebeans 和@JmsListener带注释的方法。
这将产生"jms.message.publish"和"jms.message.process"指标。有关生成的观察的更多信息，请参阅 Spring Framework 参考文档。
7.3.7. Spring MVC 指标
自动配置允许检测 Spring MVC 控制器和功能处理程序处理的所有请求。默认情况下，指标的生成名称为http.server.requests. 您可以通过设置management.observations.http.server.requests.name财产。
要添加到默认标记，请提供@Bean延伸DefaultServerRequestObservationConvention从org.springframework.http.server.observation包。
要替换默认标记，请提供一个@Bean实现ServerRequestObservationConvention.
| 在某些情况下，Web 控制器中处理的异常不会记录为请求指标标记。 应用程序可以通过将已处理的异常设置为请求属性来选择加入并记录异常。 |
默认情况下，将处理所有请求。
要自定义过滤器，请提供@Bean实现FilterRegistrationBean<ServerHttpObservationFilter>.
7.3.8. Spring WebFlux 指标
自动配置允许检测 Spring WebFlux 控制器和功能处理程序处理的所有请求。
默认情况下，生成指标的名称为http.server.requests. 您可以通过设置management.observations.http.server.requests.name财产。
要添加到默认标记，请提供@Bean延伸DefaultServerRequestObservationConvention从org.springframework.http.server.reactive.observation包。
要替换默认标记，请提供一个@Bean实现ServerRequestObservationConvention.
| 在某些情况下，控制器和处理程序函数中处理的异常不会记录为请求指标标记。 应用程序可以通过将已处理的异常设置为请求属性来选择加入并记录异常。 |
7.3.9. Jersey服务器指标
自动配置支持检测 Jersey JAX-RS 实现处理的所有请求。
默认情况下，生成指标的名称为http.server.requests. 您可以通过设置management.observations.http.server.requests.name财产。
默认情况下，Jersey服务器指标使用以下信息进行标记：
| 标记 | 描述 |
|---|---|
|
处理请求时引发的任何异常的简单类名。 |
|
请求的方法（例如 |
|
请求的结果，基于响应的状态代码。
1xx 是 |
|
响应的 HTTP 状态代码（例如 |
|
如果可能，请求的 URI 模板在变量替换之前（例如， |
要自定义标记，请提供@Bean实现JerseyTagsProvider.
7.3.10. HTTP 客户端指标
Spring Boot Actuator 管理RestTemplate,WebClient和RestClient.
为此，您必须注入自动配置的构建器并使用它来创建实例：
-
RestTemplateBuilder为RestTemplate -
WebClient.Builder为WebClient -
RestClient.Builder为RestClient
您还可以手动应用负责此检测的定制器，即ObservationRestTemplateCustomizer,ObservationWebClientCustomizer和ObservationRestClientCustomizer.
默认情况下，生成指标的名称为http.client.requests. 您可以通过设置management.observations.http.client.requests.name财产。
在使用RestTemplate或RestClient，提供一个@Bean实现ClientRequestObservationConvention从org.springframework.http.client.observation包。
在使用WebClient，提供一个@Bean实现ClientRequestObservationConvention从org.springframework.web.reactive.function.client包。
7.3.11. Tomcat 指标
自动配置仅在MBeanRegistry已启用。
默认情况下，MBeanRegistry已禁用，但您可以通过将server.tomcat.mbeanregistry.enabled自true.
Tomcat 指标发布在tomcat.仪表名称。
7.3.12. 缓存指标
自动配置支持所有可用仪器Cache启动时的实例，指标前缀为cache.
缓存检测针对一组基本指标进行了标准化。
还提供其他特定于缓存的指标。
支持以下缓存库：
-
缓存2k
-
咖啡因
-
榛铸
-
任何符合 JCache （JSR-107） 的实现
-
Redis
指标由缓存的名称和CacheManager，源自 bean 名称。
只有在启动时配置的缓存才会绑定到注册表。
对于缓存配置中未定义的缓存，例如动态创建的缓存或在启动阶段后以编程方式创建的缓存，需要显式注册。
一个CacheMetricsRegistrarbean 的提供使该过程更容易。 |
7.3.13. Spring 批处理指标
请参阅 Spring Batch 参考文档。
7.3.14. Spring GraphQL 指标
请参阅 Spring GraphQL 参考文档。
7.3.15. 数据源指标
自动配置支持所有可用仪器DataSource指标前缀为jdbc.connections.
数据源检测生成仪表，这些仪表表示池中当前活动、空闲、允许的最大连接数和允许的最小连接数。
指标还由DataSource根据 Bean 名称计算。
默认情况下，Spring Boot 为所有受支持的数据源提供元数据。
您可以添加其他DataSourcePoolMetadataProviderbean，如果不支持您最喜欢的数据源。
看DataSourcePoolMetadataProvidersConfiguration例如。 |
此外，特定于 Hikari 的指标会通过hikaricp前缀。
每个指标都由池的名称标记（您可以使用spring.datasource.name).
7.3.16. Hibernate 指标
如果org.hibernate.orm:hibernate-micrometer在类路径上，所有可用的休眠EntityManagerFactory启用了统计信息的实例使用名为hibernate.
指标还由EntityManagerFactory，源自 bean 名称。
要启用统计信息，请标准 JPA 属性hibernate.generate_statistics必须设置为true.
您可以在自动配置的EntityManagerFactory:
spring.jpa.properties[hibernate.generate_statistics]=truespring:
jpa:
properties:
"[hibernate.generate_statistics]": true7.3.17. Spring Data Repository指标
自动配置支持所有 Spring Data 的检测Repository方法调用。
默认情况下，生成指标的名称为spring.data.repository.invocations. 您可以通过设置management.metrics.data.repository.metric-name财产。
这@Timed注释io.micrometer.core.annotation软件包支持Repository接口和方法。
如果您不想记录所有指标Repository调用，您可以将management.metrics.data.repository.autotime.enabled自false并专门使用@Timed注释。
一个@Timed注释longTask = true为该方法启用较长的任务计时器。
长任务计时器需要单独的指标名称，并且可以与短任务计时器堆叠。 |
默认情况下，与存储库调用相关的指标使用以下信息进行标记：
| 标记 | 描述 |
|---|---|
|
源的简单类名 |
|
的名称 |
|
结果状态 （ |
|
从调用引发的任何异常的简单类名。 |
要替换默认标记，请提供一个@Bean实现RepositoryTagsProvider.
7.3.19. Spring 集成指标
Spring Integration 每当MeterRegistry豆子可用。
指标发布在spring.integration.仪表名称。
7.3.20. Kafka 指标
自动配置注册一个MicrometerConsumerListener和MicrometerProducerListener分别用于自动配置的使用者工厂和生产者工厂。
它还注册了一个KafkaStreamsMicrometerListener为StreamsBuilderFactoryBean.
有关更多详细信息，请参阅 Spring Kafka 文档的 Micrometer Native Metrics 部分。
7.3.21. MongoDB 指标
本节简要介绍 MongoDB 的可用指标。
MongoDB 命令指标
自动配置注册一个MongoMetricsCommandListener使用自动配置的MongoClient.
名为mongodb.driver.commands为向底层 MongoDB 驱动程序发出的每个命令创建。
默认情况下，每个指标都使用以下信息进行标记：
| 标记 | 描述 |
|---|---|
|
发出的命令的名称。 |
|
命令发送到的集群的标识符。 |
|
命令发送到的服务器的地址。 |
|
命令 （ |
要替换默认指标标记，请定义一个MongoCommandTagsProviderbean，如以下示例所示：
@Configuration(proxyBeanMethods = false)
public class MyCommandTagsProviderConfiguration {
@Bean
public MongoCommandTagsProvider customCommandTagsProvider() {
return new CustomCommandTagsProvider();
}
}
@Configuration(proxyBeanMethods = false)
class MyCommandTagsProviderConfiguration {
@Bean
fun customCommandTagsProvider(): MongoCommandTagsProvider? {
return CustomCommandTagsProvider()
}
}
要禁用自动配置的命令指标，请设置以下属性：
management.metrics.mongo.command.enabled=falsemanagement:
metrics:
mongo:
command:
enabled: falseMongoDB 连接池指标
自动配置注册一个MongoMetricsConnectionPoolListener使用自动配置的MongoClient.
为连接池创建以下仪表指标：
-
mongodb.driver.pool.size报告连接池的当前大小，包括空闲和正在使用的成员。 -
mongodb.driver.pool.checkedout报告当前正在使用的连接计数。 -
mongodb.driver.pool.waitqueuesize报告来自池的连接的等待队列的当前大小。
默认情况下，每个指标都使用以下信息进行标记：
| 标记 | 描述 |
|---|---|
|
连接池对应的集群的标识符。 |
|
连接池对应的服务器的地址。 |
要替换默认指标标记，请定义一个MongoConnectionPoolTagsProvider豆：
@Configuration(proxyBeanMethods = false)
public class MyConnectionPoolTagsProviderConfiguration {
@Bean
public MongoConnectionPoolTagsProvider customConnectionPoolTagsProvider() {
return new CustomConnectionPoolTagsProvider();
}
}
@Configuration(proxyBeanMethods = false)
class MyConnectionPoolTagsProviderConfiguration {
@Bean
fun customConnectionPoolTagsProvider(): MongoConnectionPoolTagsProvider {
return CustomConnectionPoolTagsProvider()
}
}
要禁用自动配置的连接池衡量指标，请设置以下属性：
management.metrics.mongo.connectionpool.enabled=falsemanagement:
metrics:
mongo:
connectionpool:
enabled: false7.3.22. Jetty 指标
自动配置绑定 Jetty 的指标ThreadPool通过使用 Micrometer 的JettyServerThreadPoolMetrics.
Jetty 的指标Connector实例使用 Micrometer 的JettyConnectionMetrics并且，当server.ssl.enabled设置为true， 千分尺的JettySslHandshakeMetrics.
7.3.23. @Timed Commentation 支持
启用扫描@Timed注释，您需要将management.observations.annotations.enabled属性设置为true. 请参阅千分尺文档。
7.3.24. Redis 指标
自动配置注册一个MicrometerCommandLatencyRecorder对于自动配置的LettuceConnectionFactory. 有关更多详细信息，请参阅 Lettuce 文档的 Micrometer Metrics 部分。
7.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());
}
}
@Component
class MyBean(registry: MeterRegistry) {
private val dictionary: Dictionary
init {
dictionary = Dictionary.load()
registry.gauge("dictionary.size", Tags.empty(), dictionary.words.size)
}
}
如果您的指标依赖于其他 Bean，我们建议您使用MeterBinder要注册它们：
public class MyMeterBinderConfiguration {
@Bean
public MeterBinder queueSize(Queue queue) {
return (registry) -> Gauge.builder("queueSize", queue::size).register(registry);
}
}
class MyMeterBinderConfiguration {
@Bean
fun queueSize(queue: Queue): MeterBinder {
return MeterBinder { registry ->
Gauge.builder("queueSize", queue::size).register(registry)
}
}
}
使用MeterBinder确保设置了正确的依赖关系，并且在检索度量值时 Bean 可用。
一个MeterBinder如果您发现跨组件或应用程序重复检测一套指标，则实施也很有用。
默认情况下，来自所有MeterBinderbean 会自动绑定到 Spring 管理的MeterRegistry. |
7.5. 自定义单个指标
如果需要将自定义应用于特定Meter实例中，您可以使用io.micrometer.core.instrument.config.MeterFilter接口。
例如，如果要将mytag.region标签设置为mytag.area对于以com.example，您可以执行以下作：
@Configuration(proxyBeanMethods = false)
public class MyMetricsFilterConfiguration {
@Bean
public MeterFilter renameRegionTagMeterFilter() {
return MeterFilter.renameTag("com.example", "mytag.region", "mytag.area");
}
}
@Configuration(proxyBeanMethods = false)
class MyMetricsFilterConfiguration {
@Bean
fun renameRegionTagMeterFilter(): MeterFilter {
return MeterFilter.renameTag("com.example", "mytag.region", "mytag.area")
}
}
默认情况下，所有MeterFilterbean 会自动绑定到 Spring 管理的MeterRegistry. 确保使用 Spring 托管的MeterRegistry而不是任何静态方法Metrics. 这些使用非 Spring 管理的全局注册表。 |
7.5.1. 常用标签
通用标签一般用于运行环境的维度下钻，如主机、实例、地域、堆栈等。通用标签应用于所有仪表，可以配置，如下例所示：
management.metrics.tags.region=us-east-1
management.metrics.tags.stack=prodmanagement:
metrics:
tags:
region: "us-east-1"
stack: "prod"前面的示例将region和stack标记添加到所有值为us-east-1和prod分别。
如果您使用 Graphite，则常见标签的顺序很重要。由于使用这种方法无法保证常见标签的顺序，因此建议 Graphite 用户定义自定义MeterFilter相反。 |
7.5.2. 每米属性
除了MeterFilterbean，您可以使用属性按米应用一组有限的自定义。使用 Spring Boot 的PropertiesMeterFilter，转换为以给定名称开头的任何仪表 ID。以下示例筛选出 ID 开头为 的任何仪表example.remote.
management.metrics.enable.example.remote=falsemanagement:
metrics:
enable:
example:
remote: false以下属性允许按计量自定义：
| 属性 | 描述 |
|---|---|
|
是否接受具有特定 ID 的仪表。
不接受的仪表将从 |
|
是否发布适合计算可聚合（跨维度）百分位近似的直方图。 |
|
通过限制预期值的范围来发布更少的直方图桶。 |
|
发布在应用程序中计算的百分位值 |
|
通过将最近的 Samples累积在环形缓冲区中来赋予它们更大的权重，这些缓冲区在可配置的到期后旋转，并使用 可配置的缓冲区长度。 |
|
发布累积直方图，其中包含由服务级别目标定义的存储桶。 |
有关背后概念的更多详细信息percentiles-histogram,percentiles和slo，请参阅千分尺文档的“直方图和百分位数”部分。
7.6. 指标端点
Spring Boot 提供了一个metrics端点，您可以诊断地使用它来检查应用程序收集的指标。
默认情况下，终结点不可用，必须公开。
有关更多详细信息，请参阅公开终结点。
导航到/actuator/metrics显示可用仪表名称的列表。
您可以通过提供特定仪表的名称作为选择器来向下钻取以查看有关其信息，例如/actuator/metrics/jvm.memory.max.
|
您在此处使用的名称应与代码中使用的名称匹配，而不是为它交付到的监视系统进行命名约定规范化后的名称。
换句话说，如果 |
您还可以添加任意数量的tag=KEY:VALUE查询参数到URL末尾，以对仪表进行维度向下钻取，例如，/actuator/metrics/jvm.memory.max?tag=area:nonheap.
|
报告的测量值是与仪表名称匹配的所有仪表的统计数据和已应用的任何标记的统计数据的总和。
在前面的示例中，返回的 |
8. 追踪
Spring Boot Actuator 为 Micrometer Tracking 提供依赖管理和自动配置，Micrometer Tracking 是流行的跟踪器库的外观。
| 要了解有关千分尺追踪功能的更多信息，请参阅其参考文档。 |
8.2. 入门
我们需要一个示例应用程序，可以使用它来开始跟踪。 就我们的目的而言，“getting-started.html”部分中介绍的简单“Hello World！” Web 应用程序就足够了。 我们将使用 OpenTelemetry 跟踪器和 Zipkin 作为跟踪后端。
回顾一下，我们的主要应用程序代码如下所示：
@RestController
@SpringBootApplication
public class MyApplication {
private static final Log logger = LogFactory.getLog(MyApplication.class);
@RequestMapping("/")
String home() {
logger.info("home() has been called");
return "Hello World!";
}
public static void main(String[] args) {
SpringApplication.run(MyApplication.class, args);
}
}
在home()方法，这在以后会很重要。 |
现在我们必须添加以下依赖项：
-
org.springframework.boot:spring-boot-starter-actuator -
io.micrometer:micrometer-tracing-bridge-otel- 将 Micrometer Observation API 桥接到 OpenTelemetry。 -
io.opentelemetry:opentelemetry-exporter-zipkin- 向 Zipkin 报告痕迹。
添加以下应用程序属性：
management.tracing.sampling.probability=1.0management:
tracing:
sampling:
probability: 1.0默认情况下，Spring Boot 仅采样 10% 的请求，以防止跟踪后端不堪重负。 此属性将其切换为 100%，以便将每个请求发送到跟踪后端。
为了收集和可视化跟踪，我们需要一个正在运行的跟踪后端。 我们在这里使用 Zipkin 作为跟踪后端。 Zipkin 快速入门指南提供了如何在本地启动 Zipkin 的说明。
Zipkin 运行后，您可以启动应用程序。
如果您打开 Web 浏览器以localhost:8080，您应该会看到以下输出：
Hello World!
在后台，已经为 HTTP 请求创建了一个观察，该观察又被桥接到 OpenTelemetry，后者向 Zipkin 报告新的跟踪。
现在打开 Zipkin UIlocalhost:9411，然后按“运行查询”按钮列出所有收集的跟踪。
您应该会看到一条痕迹。
按“显示”按钮可查看该跟踪的详细信息。
8.3. 记录相关 ID
相关 ID 提供了一种有用的方法，用于将日志文件中的行链接到跨度/跟踪。 如果您使用的是 Micrometer Tracing，Spring Boot 将默认在您的日志中包含相关 ID。
默认关联 ID 是从traceId和spanId MDC 值。
例如，如果千分尺跟踪已添加 MDCtraceId之803B448A0489F84084905D3093480352和 MDCspanId之3425F23BB2432450日志输出将包括相关 ID[803B448A0489F84084905D3093480352-3425F23BB2432450].
如果您更喜欢对相关 ID 使用不同的格式，可以使用logging.pattern.correlation属性来定义一个。
例如，以下内容将以 Spring Cloud Sleuth 以前使用的格式提供 Logback 的相关 ID：
logging.pattern.correlation=[${spring.application.name:},%X{traceId:-},%X{spanId:-}]
logging.include-application-name=falselogging:
pattern:
correlation: "[${spring.application.name:},%X{traceId:-},%X{spanId:-}] "
include-application-name: false在上面的示例中，logging.include-application-name设置为false以避免应用程序名称在日志消息 （logging.pattern.correlation已经包含它）。
还值得一提的是logging.pattern.correlation包含尾随空格，以便它与默认情况下紧跟在它后面的记录器名称分开。 |
8.4. 传播跟踪
要通过网络自动传播跟踪，请使用自动配置的RestTemplateBuilder,RestClient.Builder或WebClient.Builder以构建客户端。
如果您创建RestTemplate这RestClient或WebClient如果不使用自动配置的构建器，自动跟踪传播将不起作用！ |
8.5. 跟踪器实现
由于 Micrometer Tracer 支持多个跟踪器实现，因此 Spring Boot 可能有多种依赖项组合。
所有跟踪器实现都需要org.springframework.boot:spring-boot-starter-actuatorDependency。
8.5.1. 使用 Zipkin 的 OpenTelemetry
使用 OpenTelemetry 进行跟踪并向 Zipkin 报告需要以下依赖项：
-
io.micrometer:micrometer-tracing-bridge-otel- 将 Micrometer Observation API 桥接到 OpenTelemetry。 -
io.opentelemetry:opentelemetry-exporter-zipkin- 向 Zipkin 报告痕迹。
使用management.zipkin.tracing.*配置属性来配置向 Zipkin 报告。
8.5.2. 带有波前的 OpenTelemetry
使用 OpenTelemetry 进行跟踪并向 Wavefront 报告需要以下依赖项：
-
io.micrometer:micrometer-tracing-bridge-otel- 将 Micrometer Observation API 桥接到 OpenTelemetry。 -
io.micrometer:micrometer-tracing-reporter-wavefront- 向 Wavefront 报告跟踪。
使用management.wavefront.*配置属性以配置对 Wavefront 的报告。
8.5.3. 使用 OTLP 的 OpenTelemetry
使用 OpenTelemetry 进行跟踪并使用 OTLP 进行报告需要以下依赖项：
-
io.micrometer:micrometer-tracing-bridge-otel- 将 Micrometer Observation API 桥接到 OpenTelemetry。 -
io.opentelemetry:opentelemetry-exporter-otlp- 向可以接受 OTLP 的收集器报告跟踪。
使用management.otlp.tracing.*配置属性，以使用 OTLP 配置报告。
8.5.4. OpenZipkin Brave 与 Zipkin
使用 OpenZipkin Brave 进行跟踪并向 Zipkin 报告需要以下依赖项：
-
io.micrometer:micrometer-tracing-bridge-brave- 将千分尺观察 API 桥接到 Brave。 -
io.zipkin.reporter2:zipkin-reporter-brave- 向 Zipkin 报告痕迹。
如果您的项目不使用 Spring MVC 或 Spring WebFlux，则io.zipkin.reporter2:zipkin-sender-urlconnection依赖性也是需要的。 |
使用management.zipkin.tracing.*配置属性来配置向 Zipkin 报告。
8.7. 创建自定义跨度
您可以通过开始观测来创建自己的跨度。
为此，注入ObservationRegistry到你的组件中：
@Component
class CustomObservation {
private final ObservationRegistry observationRegistry;
CustomObservation(ObservationRegistry observationRegistry) {
this.observationRegistry = observationRegistry;
}
void someOperation() {
Observation observation = Observation.createNotStarted("some-operation", this.observationRegistry);
observation.lowCardinalityKeyValue("some-tag", "some-value");
observation.observe(() -> {
// Business logic ...
});
}
}
这将创建一个名为“some-operation”的观察，标签为“some-tag=some-value”。
如果要在不创建指标的情况下创建范围，则需要使用较低级别Tracer应用程序接口来自千分尺。 |
8.8. 行李
您可以使用Tracer应用程序接口：
@Component
class CreatingBaggage {
private final Tracer tracer;
CreatingBaggage(Tracer tracer) {
this.tracer = tracer;
}
void doSomething() {
try (BaggageInScope scope = this.tracer.createBaggageInScope("baggage1", "value1")) {
// Business logic
}
}
}
此示例创建名为baggage1与值value1. 如果您使用的是 W3C 传播，则行李会自动通过网络传播。如果您使用的是 B3 传播，则行李不会自动传播。要通过网络手动传播行李，请使用management.tracing.baggage.remote-fieldsconfiguration 属性（这也适用于 W3C）。对于上面的示例，将此属性设置为baggage1结果为 HTTP 标头baggage1: value1.
如果要将行李传播到 MDC，请使用management.tracing.baggage.correlation.fieldsconfiguration 属性。对于上面的示例，将此属性设置为baggage1导致名为baggage1.
8.9. 测试
使用@SpringBootTest. 有关更多详细信息，请参阅测试部分。
9. 审计
一旦 Spring Security 开始运行，Spring Boot Actuator 就有一个灵活的审计框架，可以发布事件（默认情况下，“身份验证成功”、“失败”和“访问被拒绝”异常）。此功能对于报告和实施基于身份验证失败的锁定策略非常有用。
您可以通过提供类型为AuditEventRepository在应用程序的配置中。
为方便起见，Spring Boot 提供了一个InMemoryAuditEventRepository.InMemoryAuditEventRepository功能有限，建议仅将其用于开发环境。
对于生产环境，请考虑创建自己的替代项AuditEventRepository实现。
10. 记录 HTTP 交换
您可以通过提供类型为HttpExchangeRepository在应用程序的配置中。
为方便起见，Spring Boot 提供InMemoryHttpExchangeRepository，默认情况下，它存储最近 100 个请求-响应交换。InMemoryHttpExchangeRepository与跟踪解决方案相比有限，我们建议仅将其用于开发环境。
对于生产环境，建议使用生产就绪的跟踪或可观测性解决方案，例如 Zipkin 或 OpenTelemetry。
或者，您可以创建自己的HttpExchangeRepository.
您可以使用httpexchangesendpoint 以获取有关存储在HttpExchangeRepository.
11. 过程监控
在spring-boot模块中，您可以找到两个类来创建通常对进程监控有用的文件：
-
ApplicationPidFileWriter创建一个包含应用程序 PID 的文件（默认情况下，在文件名为application.pid). -
WebServerPortFileWriter创建一个（或多个文件），其中包含正在运行的 Web 服务器的端口（默认情况下，在文件名为application.port).
默认情况下，这些写入器不会激活，但您可以启用它们：
12. Cloud Foundry 支持
Spring Boot 的执行器模块包括额外的支持，当您部署到兼容的 Cloud Foundry 实例时，这些支持会激活。 这/cloudfoundryapplicationpath 为所有@Endpoint豆。
扩展支持允许使用 Spring Boot 执行器信息增强 Cloud Foundry 管理 UI（例如可用于查看已部署应用程序的 Web 应用程序）。例如，应用程序状态页面可以包含完整的运行状况信息，而不是典型的“正在运行”或“已停止”状态。
这/cloudfoundryapplication普通用户无法直接访问路径。
若要使用终结点，必须在请求中传递有效的 UAA Tokens。 |
12.1. 禁用扩展的 Cloud Foundry 执行器支持
如果您想完全禁用/cloudfoundryapplicationendpoints，您可以将以下设置添加到application.properties文件：
management.cloudfoundry.enabled=falsemanagement:
cloudfoundry:
enabled: false12.2. Cloud Foundry 自签名证书
默认情况下，安全验证/cloudfoundryapplicationendpoints 对各种 Cloud Foundry 服务进行 SSL 调用。
如果您的 Cloud Foundry UAA 或 Cloud Controller 服务使用自签名证书，则需要设置以下属性：
management.cloudfoundry.skip-ssl-validation=truemanagement:
cloudfoundry:
skip-ssl-validation: true12.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("/*");
};
}
}
@Configuration(proxyBeanMethods = false)
class MyCloudFoundryConfiguration {
@Bean
fun servletWebServerFactory(): TomcatServletWebServerFactory {
return object : TomcatServletWebServerFactory() {
override fun prepareContext(host: Host, initializers: Array<ServletContextInitializer>) {
super.prepareContext(host, initializers)
val child = StandardContext()
child.addLifecycleListener(FixContextListener())
child.path = "/cloudfoundryapplication"
val initializer = getServletContextInitializer(contextPath)
child.addServletContainerInitializer(initializer, emptySet())
child.crossContext = true
host.addChild(child)
}
}
}
private fun getServletContextInitializer(contextPath: String): ServletContainerInitializer {
return ServletContainerInitializer { classes: Set<Class<*>?>?, context: ServletContext ->
val servlet: Servlet = object : GenericServlet() {
@Throws(ServletException::class, IOException::class)
override fun service(req: ServletRequest, res: ServletResponse) {
val servletContext = req.servletContext.getContext(contextPath)
servletContext.getRequestDispatcher("/cloudfoundryapplication").forward(req, res)
}
}
context.addServlet("cloudfoundry", servlet).addMapping("/*")
}
}
}
如果您使用的是基于 Webflux 的应用程序，则可以使用以下配置：
@Configuration(proxyBeanMethods = false)
@EnableConfigurationProperties(WebFluxProperties.class)
public class MyReactiveCloudFoundryConfiguration {
@Bean
public HttpHandler httpHandler(ApplicationContext applicationContext, WebFluxProperties properties) {
HttpHandler httpHandler = WebHttpHandlerBuilder.applicationContext(applicationContext).build();
return new CloudFoundryHttpHandler(properties.getBasePath(), httpHandler);
}
private static final class CloudFoundryHttpHandler implements HttpHandler {
private final HttpHandler delegate;
private final ContextPathCompositeHandler contextPathDelegate;
private CloudFoundryHttpHandler(String basePath, HttpHandler delegate) {
this.delegate = delegate;
this.contextPathDelegate = new ContextPathCompositeHandler(Map.of(basePath, delegate));
}
@Override
public Mono<Void> handle(ServerHttpRequest request, ServerHttpResponse response) {
// Remove underlying context path first (e.g. Servlet container)
String path = request.getPath().pathWithinApplication().value();
if (path.startsWith("/cloudfoundryapplication")) {
return this.delegate.handle(request, response);
}
else {
return this.contextPathDelegate.handle(request, response);
}
}
}
}
@Configuration(proxyBeanMethods = false)
@EnableConfigurationProperties(WebFluxProperties::class)
class MyReactiveCloudFoundryConfiguration {
@Bean
fun httpHandler(applicationContext: ApplicationContext, properties: WebFluxProperties): HttpHandler {
val httpHandler = WebHttpHandlerBuilder.applicationContext(applicationContext).build()
return CloudFoundryHttpHandler(properties.basePath, httpHandler)
}
private class CloudFoundryHttpHandler(basePath: String, private val delegate: HttpHandler) : HttpHandler {
private val contextPathDelegate = ContextPathCompositeHandler(mapOf(basePath to delegate))
override fun handle(request: ServerHttpRequest, response: ServerHttpResponse): Mono<Void> {
// Remove underlying context path first (e.g. Servlet container)
val path = request.path.pathWithinApplication().value()
return if (path.startsWith("/cloudfoundryapplication")) {
delegate.handle(request, response)
} else {
contextPathDelegate.handle(request, response)
}
}
}
}