生产就绪功能
1. 启用生产就绪功能
这spring-boot-actuator模块提供了 Spring Boot 的所有生产就绪功能。
启用这些功能的推荐方法是添加对spring-boot-starter-actuator“Starters”。
要将执行器添加到基于 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. 终端节点
Actuator 终端节点允许您监控应用程序并与之交互。
Spring Boot 包含许多内置端点，并允许您添加自己的端点。
例如，healthendpoint 提供基本的应用程序运行状况信息。
您可以启用或禁用每个单独的终端节点，并通过 HTTP 或 JMX 公开它们（使其可远程访问）。
当终端节点同时启用和公开时，该终端节点被视为可用。
仅当内置终端节点可用时，才会自动配置这些终端节点。
大多数应用程序选择通过 HTTP 进行公开，其中终端节点的 ID 和前缀/actuator映射到 URL。
例如，默认情况下，healthendpoint 映射到/actuator/health.
以下与技术无关的终端节点可用：
如果您的应用程序是 Web 应用程序（Spring MVC、Spring WebFlux 或 Jersey），则可以使用以下附加端点：
| 身份证 | 描述 |
|---|---|
|
返回堆转储文件。
在 HotSpot JVM 上， |
|
当 Jolokia 位于 Classpath 上时，通过 HTTP 公开 JMX bean（不适用于 WebFlux）。
需要依赖 |
|
返回日志文件的内容（如果 |
|
以 Prometheus 服务器可抓取的格式公开指标。
需要依赖 |
2.1. 启用端点
默认情况下，除shutdown已启用。
要配置端点的启用，请使用其management.endpoint.<id>.enabled财产。
以下示例启用shutdown端点：
management.endpoint.shutdown.enabled=truemanagement:
endpoint:
shutdown:
enabled: true如果您希望终端节点启用为选择加入而不是选择退出，请将management.endpoints.enabled-by-defaultproperty 设置为false并使用单个端点enabled属性以选择重新加入。
以下示例启用infoendpoint 并禁用所有其他 endpoints：
management.endpoints.enabled-by-default=false
management.endpoint.info.enabled=truemanagement:
endpoints:
enabled-by-default: false
endpoint:
info:
enabled: true已禁用的端点将从应用程序上下文中完全删除。
如果您只想更改终端节点所公开的技术，请使用include和exclude性能相反。 |
2.2. 公开端点
由于 Endpoints 可能包含敏感信息，因此您应该仔细考虑何时公开它们。 下表显示了内置终端节点的默认风险：
| 身份证 | JMX | Web |
|---|---|---|
|
是的 |
不 |
|
是的 |
不 |
|
是的 |
不 |
|
是的 |
不 |
|
是的 |
不 |
|
是的 |
不 |
|
是的 |
不 |
|
是的 |
是的 |
|
不适用 |
不 |
|
是的 |
不 |
|
是的 |
不 |
|
是的 |
不 |
|
不适用 |
不 |
|
不适用 |
不 |
|
是的 |
不 |
|
是的 |
不 |
|
是的 |
不 |
|
是的 |
不 |
|
不适用 |
不 |
|
是的 |
不 |
|
是的 |
不 |
|
是的 |
不 |
|
是的 |
不 |
|
是的 |
不 |
|
是的 |
不 |
要更改公开的终端节点，请使用以下特定于include和exclude性能：
| 财产 | 违约 |
|---|---|
|
|
|
|
|
|
|
|
这includeproperty 列出公开的端点的 ID。
这excludeproperty 列出不应公开的端点的 ID。
这exclude属性优先于include财产。
您可以配置include和exclude属性中，其中包含终端节点 ID 列表。
例如，要停止通过 JMX 公开所有端点，而只公开health和infoendpoints，请使用以下属性：
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. 安全性
出于安全考虑，只有/healthendpoint 默认通过 HTTP 公开。
您可以使用management.endpoints.web.exposure.include属性来配置公开的端点。
在设置management.endpoints.web.exposure.include，确保公开的 actuator 不包含敏感信息，通过将它们放置在防火墙后面进行保护，或者由类似 Spring Security 的东西进行保护。 |
如果 Spring Security 在类路径上，并且没有其他WebSecurityConfigurerAdapter或SecurityFilterChainBean 存在，则除/health由 Spring Boot 自动配置保护。
如果您定义了自定义WebSecurityConfigurerAdapter或SecurityFilterChainbean，Spring Boot 自动配置会回退，并允许您完全控制 actuator 访问规则。
如果您希望为 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();
}
}
@Configuration(proxyBeanMethods = false)
class MySecurityConfiguration {
@Bean
fun securityFilterChain(http: HttpSecurity): SecurityFilterChain {
http.requestMatcher(EndpointRequest.toAnyEndpoint()).authorizeRequests { requests ->
requests.anyRequest().hasRole("ENDPOINT_ADMIN")
}
http.httpBasic()
return http.build()
}
}
前面的示例使用EndpointRequest.toAnyEndpoint()将请求匹配到任何终端节点，然后确保所有终端节点都具有ENDPOINT_ADMIN角色。
其他几种匹配器方法也可用于EndpointRequest.
有关详细信息，请参阅 API 文档（HTML 或 PDF）。
如果您在防火墙后面部署应用程序，您可能希望无需身份验证即可访问所有 actuator 终端节点。
您可以通过更改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.requestMatcher(EndpointRequest.toAnyEndpoint());
http.authorizeRequests((requests) -> requests.anyRequest().permitAll());
return http.build();
}
}
@Configuration(proxyBeanMethods = false)
class MySecurityConfiguration {
@Bean
fun securityFilterChain(http: HttpSecurity): SecurityFilterChain {
http.requestMatcher(EndpointRequest.toAnyEndpoint()).authorizeRequests { requests ->
requests.anyRequest().permitAll()
}
return http.build()
}
}
在上述两个示例中，配置仅适用于 actuator 终端节点。
由于 Spring Boot 的安全配置在存在任何SecurityFilterChainbean，您需要配置一个额外的SecurityFilterChainbean 替换为适用于应用程序其余部分的规则。 |
2.3.1. 跨站请求伪造保护
由于 Spring Boot 依赖于 Spring Security 的默认值，因此 CSRF 保护默认处于打开状态。
这意味着需要POST（shutdown 和 loggers 端点）、一个PUT或DELETE使用默认安全配置时收到 403 （禁止） 错误。
| 我们建议仅在您创建的服务由非浏览器客户端使用时才完全禁用 CSRF 保护。 |
您可以在 Spring Security 参考指南中找到有关 CSRF 保护的其他信息。
2.4. 配置端点
终端节点会自动缓存对不采用任何参数的读取作的响应。
要配置终端节点缓存响应的时间量，请使用其cache.time-to-live财产。
以下示例将beansendpoint 的缓存设置为 10 秒：
management.endpoint.beans.cache.time-to-live=10smanagement:
endpoint:
beans:
cache:
time-to-live: "10s"这management.endpoint.<name>prefix 唯一标识正在配置的终端节点。 |
2.5. 用于 Actuator Web 端点的超媒体
将添加一个“发现页面”，其中包含指向所有终端节点的链接。
“发现页面”位于/actuator默认情况下。
要禁用“发现页面”，请将以下属性添加到您的应用程序属性中：
management.endpoints.web.discovery.enabled=falsemanagement:
endpoints:
web:
discovery:
enabled: false配置自定义管理上下文路径后，“发现页面” 会自动从/actuator到 Management 上下文的根目录。
例如，如果管理上下文路径为/management中，“发现”页面可从/management.
当 Management context path 设置为 时，将禁用发现页面，以防止与其他映射发生冲突。/
2.6. CORS 支持
跨域资源共享 （CORS） 是一种 W3C 规范，可让您以灵活的方式指定授权的跨域请求类型。 如果您使用 Spring MVC 或 Spring WebFlux，则可以配置 Actuator 的 Web 端点以支持此类场景。
CORS 支持默认处于禁用状态，并且只有在您设置了management.endpoints.web.cors.allowed-origins财产。
以下配置允许GET和POST来自example.com域：
management.endpoints.web.cors.allowed-origins=https://example.com
management.endpoints.web.cors.allowed-methods=GET,POSTmanagement:
endpoints:
web:
cors:
allowed-origins: "https://example.com"
allowed-methods: "GET,POST"看CorsEndpointProperties以获取完整的选项列表。 |
2.7. 实现自定义端点
如果您添加了@Bean注解@Endpoint中，任何带有@ReadOperation,@WriteOperation或@DeleteOperation通过 JMX 自动公开，在 Web 应用程序中还通过 HTTP 公开。
可以使用 Jersey、Spring MVC 或 Spring WebFlux 通过 HTTP 公开端点。
如果 Jersey 和 Spring MVC 都可用，则使用 Spring MVC。
以下示例公开返回自定义对象的读取作：
@ReadOperation
public CustomData getData() {
return new CustomData("test", 5);
}
@ReadOperation
fun getData(): CustomData {
return 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
}
@WriteOperation
fun updateData(name: String?, counter: Int) {
// injects "test" and 42
}
由于端点与技术无关，因此只能在方法签名中指定简单类型。
具体而言，使用CustomData类型定义name和counterproperties 的 API 请求。 |
要让 input 映射到 operation 方法的参数，实现端点的 Java 代码应该使用-parameters和实现端点的 Kotlin 代码应使用-java-parameters.
如果您使用 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 MVC。
路径
谓词的路径由终端节点的 ID 和 Web 公开的终端节点的基本路径确定。
默认基本路径为/actuator.
例如，ID 为sessions使用/actuator/sessions作为其在谓词中的路径。
您可以通过使用@Selector.
此类参数将作为 path 变量添加到 path 谓词中。
调用 endpoint作时，变量的值将传递到 operation 方法中。
如果要捕获所有剩余的 path 元素，可以添加@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 （OK）。
如果未返回值，则响应状态将为 404 （Not Found）。
如果@WriteOperation或@DeleteOperation返回一个值，则响应状态将为 200 （OK）。
如果未返回值，则响应状态将为 204 （No Content）。
如果调用作时没有必需的参数，或者使用无法转换为必需类型的参数，则不会调用作方法，并且响应状态将为 400 （Bad Request）。
2.8. 健康信息
您可以使用运行状况信息来检查正在运行的应用程序的状态。
监控软件经常使用它来在生产系统出现故障时提醒某人。
由health端点依赖于management.endpoint.health.show-details和management.endpoint.health.show-components属性，可以使用以下值之一进行配置：
| 名字 | 描述 |
|---|---|
|
详细信息永远不会显示。 |
|
详细信息仅向授权用户显示。
授权角色可使用 |
|
详细信息将向所有用户显示。 |
默认值为never.
当用户处于终端节点的一个或多个角色中时，即被视为已获得授权。
如果终端节点没有配置角色（默认），则所有经过身份验证的用户都被视为已获得授权。
您可以使用management.endpoint.health.roles财产。
如果您已保护应用程序并希望使用always，则您的安全配置必须允许经过身份验证和未经身份验证的用户访问 Health 终端节点。 |
运行状况信息是从HealthContributorRegistry（默认情况下，所有HealthContributor实例ApplicationContext).
Spring Boot 包括许多自动配置的HealthContributors，您也可以编写自己的代码。
一个HealthContributor可以是HealthIndicator或CompositeHealthContributor.
一个HealthIndicator提供实际的运行状况信息，包括Status.
一个CompositeHealthContributor提供其他HealthContributors.
总而言之，贡献者形成一个树结构来表示整个系统的运行状况。
默认情况下，最终的系统运行状况由StatusAggregator，它将对每个HealthIndicator基于状态的有序列表。
排序列表中的第一个状态用作整体运行状况。
如果没有HealthIndicator返回StatusAggregator一UNKNOWNstatus 为 used。
您可以使用HealthContributorRegistry在运行时注册和注销运行状况指示器。 |
2.8.1. 自动配置的 HealthIndicators
在适当的时候， Spring Boot 会自动配置HealthIndicators如下表所示。
您还可以通过配置management.health.key.enabled,
使用key下表列出了：
| 钥匙 | 名字 | 描述 |
|---|---|---|
|
检查 Cassandra 数据库是否已启动。 |
|
|
检查 Couchbase 集群是否已启动。 |
|
|
检查连接到 |
|
|
检查磁盘空间是否不足。 |
|
|
检查 Elasticsearch 集群是否已启动。 |
|
|
检查 Hazelcast 服务器是否已启动。 |
|
|
检查 InfluxDB 服务器是否已启动。 |
|
|
检查 JMS 代理是否已启动。 |
|
|
检查 LDAP 服务器是否已启动。 |
|
|
检查邮件服务器是否已启动。 |
|
|
检查 Mongo 数据库是否已启动。 |
|
|
检查 Neo4j 数据库是否已启动。 |
|
|
始终以 |
|
|
检查 Rabbit 服务器是否已启动。 |
|
|
检查 Redis 服务器是否已启动。 |
|
|
检查 Solr 服务器是否已启动。 |
您可以通过设置management.health.defaults.enabled财产。 |
附加HealthIndicators可用，但默认情况下未启用：
| 钥匙 | 名字 | 描述 |
|---|---|---|
|
公开 “Liveness” 应用程序可用性状态。 |
|
|
公开 “Readiness” 应用程序可用性状态。 |
2.8.2. 编写自定义 HealthIndicator
要提供自定义运行状况信息，您可以注册实现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 的名称，没有HealthIndicatorsuffix （如果存在）。
在前面的示例中，运行状况信息在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.8.3. 反应式健康指标
对于响应式应用程序，例如那些使用 Spring WebFlux 的应用程序，ReactiveHealthContributor提供用于获取应用程序运行状况的非阻塞协定。
与传统的HealthContributor，则运行状况信息是从ReactiveHealthContributorRegistry（默认情况下，所有HealthContributor和ReactiveHealthContributor实例ApplicationContext).
定期HealthContributors不检查反应式 API 的 API 将在 Elastic Scheduler 上执行。
在响应式应用程序中，您应该使用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.8.4. 自动配置的 ReactiveHealthIndicators
在适当的时候， Spring Boot 会自动配置以下内容ReactiveHealthIndicators:
| 钥匙 | 名字 | 描述 |
|---|---|---|
|
检查 Cassandra 数据库是否已启动。 |
|
|
检查 Couchbase 集群是否已启动。 |
|
|
检查 Elasticsearch 集群是否已启动。 |
|
|
检查 Mongo 数据库是否已启动。 |
|
|
检查 Neo4j 数据库是否已启动。 |
|
|
检查 Redis 服务器是否已启动。 |
如有必要，反应式指标将替换常规指标。
此外，任何HealthIndicator未明确处理的 API 将自动包装。 |
2.8.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"默认情况下，组继承相同的StatusAggregator和HttpCodeStatusMapper设置作为系统运行状况。
但是，您也可以按组定义这些 ID。
您还可以覆盖show-details和rolesproperties （如果需要）：
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或HttpCodeStatusMapperbean 用于组。 |
运行状况组还可以包含/排除CompositeHealthContributor.
您还可以仅包含/排除CompositeHealthContributor.
这可以使用组件的完全限定名称来完成，如下所示：
management.endpoint.health.group.custom.include="test/primary"
management.endpoint.health.group.custom.exclude="test/primary/b"在上面的示例中，customgroup 将包含HealthContributor替换为名称primary它是复合体的一个组成部分test.
这里primary本身是一个复合体，而HealthContributor替换为名称b将从custom群。
运行状况组可以在主端口或管理端口上的其他路径上可用。 这在 Kubernetes 等云环境中很有用，出于安全目的，为 actuator 端点使用单独的 management 端口是很常见的。 拥有单独的端口可能会导致运行状况检查不可靠，因为即使运行状况检查成功，主应用程序也可能无法正常工作。 运行状况组可以配置其他路径，如下所示：
management.endpoint.health.group.live.additional-path="server:/healthz"这将使live运行状况组在主服务器端口上可用/healthz.
前缀是必需的，并且必须是server:（表示主服务器端口）或management:（表示管理端口，如果已配置。
路径必须是单个路径段。
2.9. Kubernetes 探针
部署在 Kubernetes 上的应用程序可以通过 Container Probe 提供有关其内部状态的信息。 根据您的 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>应设置为 actuator endpoints 可用的端口。
它可以是主 Web 服务器端口，也可以是单独的管理端口（如果"management.server.port"属性。 |
仅当应用程序在 Kubernetes 环境中运行时，才会自动启用这些运行状况组。
您可以在任何环境中使用management.endpoint.health.probes.enabledconfiguration 属性。
如果应用程序的启动时间超过配置的活跃期，Kubernetes 会提到"startupProbe"作为可能的解决方案。
一般来说，"startupProbe"在这里不一定需要，因为"readinessProbe"失败，直到所有启动任务都完成。
这意味着您的应用程序在准备就绪之前不会接收流量。
但是，如果您的应用程序需要很长时间才能启动，请考虑使用"startupProbe"以确保 Kubernetes 不会在应用程序启动过程中终止它。
请参阅描述 Probe 在应用程序生命周期中的行为方式的部分。 |
如果您的 Actuator 端点部署在单独的 Management 上下文中，则端点不会使用与主应用程序相同的 Web 基础架构（端口、连接池、框架组件）。
在这种情况下，即使主应用程序无法正常工作（例如，它无法接受新连接），探测检查也可能成功。
因此，将liveness和readiness主服务器端口上可用的运行状况组。
这可以通过设置以下属性来完成：
management.endpoint.health.probes.add-additional-paths=true这将使liveness组 available at/livez和readiness组 available at/readyz在主服务器端口上。
可以使用additional-path属性，有关详细信息，请参阅运行状况组。
2.9.1. 使用 Kubernetes 探针检查外部状态
Actuator 将 “liveness” 和 “readiness” 探针配置为 Health Group。 这意味着所有运行状况组功能都可供他们使用。 例如，您可以配置其他运行状况指示器：
management.endpoint.health.group.readiness.include=readinessState,customCheckmanagement:
endpoint:
health:
group:
readiness:
include: "readinessState,customCheck"默认情况下， Spring Boot 不会向这些组添加其他运行状况指示器。
“活动性” 探测不应依赖于外部系统的运行状况检查。 如果应用程序的活跃状态被破坏，Kubernetes 会尝试通过重启应用程序实例来解决这个问题。 这意味着，如果外部系统（例如数据库、Web API 或外部缓存）发生故障，Kubernetes 可能会重新启动所有应用程序实例并产生级联故障。
至于 “readiness” 探测，应用程序开发人员必须仔细选择检查外部系统。 因此， Spring Boot 在就绪情况探测中不包括任何其他运行状况检查。 如果应用程序实例的就绪状态为 unready，Kubernetes 不会将流量路由到该实例。 某些外部系统可能不由应用程序实例共享，在这种情况下，它们可能包含在就绪情况探测中。 其他外部系统对于应用程序可能不是必需的（应用程序可能具有断路器和回退），在这种情况下，它们绝对不应包含在内。 不幸的是，所有应用程序实例共享的外部系统是通用的，您必须做出判断：将其包含在就绪情况探测中，并期望当外部服务关闭时应用程序会停止服务，或者将其排除在外，并处理堆栈上层的故障，也许是在调用者中使用断路器。
如果应用程序的所有实例都未就绪，则具有type=ClusterIP或NodePort不接受任何传入连接。
没有 HTTP 错误响应（503 等），因为没有连接。
具有type=LoadBalancer可能接受也可能不接受连接，具体取决于提供商。
具有显式 Ingress 的服务也以取决于实现的方式进行响应 — Ingress 服务本身必须决定如何处理来自下游的 “connection refused”。
HTTP 503 在负载均衡器和入口的情况下都很可能出现。 |
此外，如果应用程序使用 Kubernetes 自动扩展，则它可能会对从负载均衡器中取出的应用程序做出不同的反应，具体取决于其自动扩展器配置。
2.9.2. 应用程序生命周期和探测状态
Kubernetes 探针支持的一个重要方面是它与应用程序生命周期的一致性。
这两者之间存在显著差异AvailabilityState（这是应用程序的内存中内部状态）
和实际的探针（公开该状态）。
根据应用程序生命周期的阶段，探测可能不可用。
Spring Boot 在启动和关闭期间发布应用程序事件，
探测器可以监听此类事件并公开AvailabilityState信息。
下表显示了AvailabilityState以及 HTTP 连接器在不同阶段的状态。
当 Spring Boot 应用程序启动时：
| 启动阶段 | LivenessState | 就绪状态 | HTTP 服务器 | 笔记 |
|---|---|---|---|---|
开始 |
|
|
未启动 |
Kubernetes 会检查 “liveness” Probe，如果时间过长，则会重启应用程序。 |
开始 |
|
|
拒绝请求 |
应用程序上下文将刷新。应用程序执行启动任务，但尚未接收流量。 |
准备 |
|
|
接受请求 |
启动任务已完成。应用程序正在接收流量。 |
当 Spring Boot 应用程序关闭时：
| 关闭阶段 | 活动状态 | 就绪状态 | HTTP 服务器 | 笔记 |
|---|---|---|---|---|
运行 |
|
|
接受请求 |
已请求关闭。 |
正常关闭 |
|
|
新请求被拒绝 |
如果启用，正常关闭将处理正在进行的请求。 |
关机完成 |
不适用 |
不适用 |
服务器已关闭 |
应用程序上下文已关闭，应用程序已关闭。 |
| 有关 Kubernetes 部署的更多信息，请参阅 Kubernetes 容器生命周期部分。 |
2.10. 应用程序信息
应用程序信息公开了从所有InfoContributorbean 中定义的ApplicationContext.
Spring Boot 包括许多自动配置的InfoContributorbeans 的 bean 中，你可以编写自己的 bean 来编写。
2.10.1. 自动配置的 InfoContributor
在适当的时候， Spring 会自动配置以下内容InfoContributor豆：
| 身份证 | 名字 | 描述 | 先决条件 |
|---|---|---|---|
|
公开生成信息。 |
一个 |
|
|
公开 |
没有。 |
|
|
公开 git 信息。 |
一个 |
|
|
公开 Java 运行时信息。 |
没有。 |
|
|
公开 Operating System 信息。 |
没有。 |
是否启用单个贡献者由其management.info.<id>.enabled财产。
不同的参与者对此属性具有不同的默认值，具体取决于其先决条件和他们公开的信息的性质。
由于没有先决条件来指示应启用它们，env,java和os默认情况下，contributors 处于禁用状态。
每个都可以通过设置其management.info.<id>.enabledproperty 设置为true.
这build和git默认情况下，信息贡献者处于启用状态。
每个都可以通过设置其management.info.<id>.enabledproperty 设置为false.
或者，要禁用通常默认启用的每个贡献者，请将management.info.defaults.enabledproperty 设置为false.
2.10.2. 自定义应用程序信息
当envcontributor 时，您可以自定义info端点info.*Spring 属性。
都Environment属性infokey 会自动公开。
例如，您可以将以下设置添加到application.properties文件：
info.app.encoding=UTF-8
info.app.java.source=11
info.app.java.target=11info:
app:
encoding: "UTF-8"
java:
source: "11"
target: "11"|
除了对这些值进行硬编码外，您还可以在构建时扩展 info 属性。 假设您使用 Maven，则可以按如下方式重写前面的示例： Yaml
|
2.10.3. Git 提交信息
另一个有用的功能是infoendpoint 是它发布有关git源代码存储库。
如果GitPropertiesbean 可用，您可以使用infoendpoint 来公开这些属性。
一个GitProperties如果git.propertiesfile 位于 Classpath 的根目录中。
有关更多详细信息，请参阅“如何生成 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"要从info端点中，将management.info.git.enabledproperty 设置为false如下：
management.info.git.enabled=falsemanagement:
info:
git:
enabled: false2.10.4. 构建信息
如果BuildPropertiesbean 可用，则infoendpoint 还可以发布有关您的构建的信息。
如果META-INF/build-info.propertiesfile 在 Classpath 中可用。
| Maven 和 Gradle 插件都可以生成该文件。 有关更多详细信息，请参阅“如何生成构建信息”。 |
2.10.5. Java 信息
这infoendpoint 发布有关 Java 运行时环境的信息，请参阅JavaInfo了解更多详情。
2.10.6.作系统信息
这infoendpoint 发布有关您的作系统的信息，请参阅OsInfo了解更多详情。
2.10.7. 编写自定义 InfoContributor
要提供自定义应用程序信息，您可以注册实现InfoContributor接口。
以下示例提供了一个exampleentry 中具有单个值：
@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 的 Endpoint，您应该会看到一个包含以下附加条目的响应：
{
"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. 自定义 Management 端点路径
有时，自定义管理终端节点的前缀非常有用。
例如，您的应用程序可能已经使用了/actuator还有另一个目的。
您可以使用management.endpoints.web.base-path属性更改管理终端节点的前缀，如下例所示：
management.endpoints.web.base-path=/managemanagement:
endpoints:
web:
base-path: "/manage"前面的application.properties示例将 endpoint 从/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.*性能。
例如，这样做可以让 Management 服务器通过 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.enabledconfiguration 属性设置为true.
Spring Boot 公开了最合适的MBeanServer作为 ID 为mbeanServer.
任何使用 Spring JMX 注释 （@ManagedResource,@ManagedAttribute或@ManagedOperation） 会接触到它。
如果您的平台提供标准的MBeanServer，Spring Boot 会使用该 VMMBeanServer，如有必要。
如果所有这些都失败了，一个新的MBeanServer已创建。
请参阅JmxAutoConfiguration类了解更多详情。
默认情况下， Spring Boot 还会将管理端点作为 JMX MBean 公开在org.springframework.boot域。
要完全控制 JMX 域中的终端节点注册，请考虑注册您自己的EndpointObjectNameFactory实现。
4.1. 自定义 MBean 名称
MBean 的名称通常是从id的终端节点。
例如，healthendpoint 公开为org.springframework.boot:type=Endpoint,name=Health.
如果您的应用程序包含多个 SpringApplicationContext，您可能会发现名称冲突。
要解决此问题，您可以设置spring.jmx.unique-namesproperty 设置为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"4.2. 禁用 JMX 端点
如果您不想通过 JMX 公开端点，则可以设置management.endpoints.jmx.exposure.exclude属性设置为 ，如下例所示：*
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 端点jolokia或发送到*management.endpoints.web.exposure.include财产。
然后，您可以使用/actuator/jolokia在管理 HTTP 服务器上。
| Jolokia 端点将 Jolokia 的 servlet 公开为 Actuator 端点。 因此，它特定于 servlet 环境，例如 Spring MVC 和 Jersey。 该端点在 WebFlux 应用程序中不可用。 |
5. Logging器
Spring Boot Actuator 包括在运行时查看和配置应用程序的日志级别的能力。 您可以查看整个列表或单个 Logger 的配置，该配置由显式配置的日志记录级别以及日志记录框架为其提供的有效日志记录级别组成。 这些级别可以是以下级别之一：
-
TRACE -
DEBUG -
INFO -
WARN -
ERROR -
FATAL -
OFF -
null
null表示没有显式配置。
6. 指标
Spring Boot Actuator 为 Micrometer 提供依赖项管理和自动配置，Micrometer 是一个支持众多监控系统的应用程序指标门面，包括：
6.1. 入门
Spring Boot 自动配置复合MeterRegistry并为它在 Classpath 上找到的每个受支持的实现向组合添加一个注册表。
依赖于micrometer-registry-{system}在你的运行时 Classpath 中就足够了，Spring Boot 可以配置注册表。
大多数注册表都具有共同的功能。 例如，即使 Micrometer 注册表实现位于 Classpath 上，您也可以禁用特定的注册表。 以下示例禁用 Datadog：
management.metrics.export.datadog.enabled=falsemanagement:
metrics:
export:
datadog:
enabled: false你也可以禁用所有注册表，除非特定于注册表的属性另有说明，如下例所示：
management.metrics.export.defaults.enabled=falsemanagement:
metrics:
export:
defaults:
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 还配置了内置插桩，您可以通过配置或专用 Comments 标记来控制这些插桩。
6.2. 支持的监控系统
本节简要介绍每个受支持的监控系统。
6.2.1. AppOptics
默认情况下，AppOptics 注册表会定期将指标推送到api.appoptics.com/v1/measurements.
要将指标导出到 SaaS AppOptics，必须提供您的 API 令牌：
management.metrics.export.appoptics.api-token=YOUR_TOKENmanagement:
metrics:
export:
appoptics:
api-token: "YOUR_TOKEN"6.2.2. 图集
management.metrics.export.atlas.uri=https://atlas.example.com:7101/api/v1/publishmanagement:
metrics:
export:
atlas:
uri: "https://atlas.example.com:7101/api/v1/publish"6.2.3. Datadog
management.metrics.export.datadog.api-key=YOUR_KEYmanagement:
metrics:
export:
datadog:
api-key: "YOUR_KEY"如果您额外提供应用程序密钥（可选），则还将导出仪表描述、类型和基本单位等元数据：
management.metrics.export.datadog.api-key=YOUR_API_KEY
management.metrics.export.datadog.application-key=YOUR_APPLICATION_KEYmanagement:
metrics:
export:
datadog:
api-key: "YOUR_API_KEY"
application-key: "YOUR_APPLICATION_KEY"默认情况下，指标将发送到 Datadog US 站点 (api.datadoghq.com).
如果您的 Datadog 项目托管在其他站点之一上，或者您需要通过代理发送指标，请相应地配置 URI：
management.metrics.export.datadog.uri=https://api.datadoghq.eumanagement:
metrics:
export:
datadog:
uri: "https://api.datadoghq.eu"您还可以更改将指标发送到 Datadog 的间隔：
management.metrics.export.datadog.step=30smanagement:
metrics:
export:
datadog:
step: "30s"6.2.4. Dynatrace
Dynatrace 提供两种指标摄取 API，这两种 API 都是针对 Micrometer 实现的。
您可以在此处找到有关 Micrometer 指标摄取的 Dynatrace 文档。
Configuration 属性中的v1命名空间仅在导出到时间序列 v1 API 时适用。
Configuration 属性中的v2命名空间仅在导出到 Metrics v2 API 时适用。
请注意，此集成只能导出到v1或v2版本，使用v2被优先考虑。
如果device-id（v1 需要，但在 v2 中未使用）在v1命名空间，指标将导出到v1端点。
否则v2。
v2 API
您可以通过两种方式使用 v2 API。
自动配置
Dynatrace 自动配置可用于由 OneAgent 或 Dynatrace Operator for Kubernetes 监控的主机。
本地 OneAgent：如果 OneAgent 正在主机上运行，则指标会自动导出到本地 OneAgent 摄取终端节点。 摄取端点将指标转发到 Dynatrace 后端。
Dynatrace Kubernetes作员：在安装了 Dynatrace Operator 的 Kubernetes 中运行时，注册表将自动从 Operator 那里获取您的端点 URI 和 API 令牌。
这是默认行为，除了对io.micrometer:micrometer-registry-dynatrace.
手动配置
如果没有可用的自动配置，则需要 Metrics v2 API 的终端节点和 API 令牌。
API 令牌必须具有“摄取量度”（metrics.ingest） 权限集。
我们建议将令牌的范围限制为此权限。
您必须确保端点 URI 包含路径（例如/api/v2/metrics/ingest):
Metrics API v2 摄取端点的 URL 因部署选项而异：
-
软件即服务 （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
management.metrics.export.dynatrace.api-token=YOUR_TOKENmanagement:
metrics:
export:
dynatrace:
uri: "https://example.live.dynatrace.com/api/v2/metrics/ingest"
api-token: "YOUR_TOKEN"使用 Dynatrace v2 API 时，可以使用以下可选功能（更多详细信息可在 Dynatrace 文档中找到）：
-
Metric key prefix（指标键前缀）：设置附加到所有导出的指标键的前缀。
-
使用 Dynatrace 元数据进行扩充：如果 OneAgent 或 Dynatrace 运算符正在运行，请使用其他元数据（例如，关于主机、进程或 pod）来扩充指标。
-
默认维度：指定添加到所有导出指标的键值对。 如果使用 Micrometer 指定了具有相同键的标签，则它们会覆盖默认尺寸。
-
使用 Dynatrace Summary 仪器：在某些情况下，Micrometer Dynatrace 注册表创建的指标被拒绝。 在 Micrometer 1.9.x 中，通过引入 Dynatrace 特定的汇总仪器解决了这个问题。 将此开关设置为
false强制 Micrometer 回退到 1.9.x 之前的默认设置。 它只应在从 Micrometer 1.8.x 迁移到 1.9.x 时遇到问题时使用。
可以不指定 URI 和 API 令牌，如以下示例所示。 在此方案中，使用自动配置的终端节点：
management.metrics.export.dynatrace.v2.metric-key-prefix=your.key.prefix
management.metrics.export.dynatrace.v2.enrich-with-dynatrace-metadata=true
management.metrics.export.dynatrace.v2.default-dimensions.key1=value1
management.metrics.export.dynatrace.v2.default-dimensions.key2=value2
management.metrics.export.dynatrace.v2.use-dynatrace-summary-instruments=truemanagement:
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"
use-dynatrace-summary-instruments: true # (default: true)v1 API（旧版）
Dynatrace v1 API 指标注册表使用时间序列 v1 API 定期将指标推送到配置的 URI。
为了向后兼容现有设置，当device-id（对于 v1 是必需的，但在 v2 中未使用），则指标将导出到时间序列 v1 终端节点。
要将指标导出到 Dynatrace，必须提供您的 API 令牌、设备 ID 和 URI：
management.metrics.export.dynatrace.uri=https://{your-environment-id}.live.dynatrace.com
management.metrics.export.dynatrace.api-token=YOUR_TOKEN
management.metrics.export.dynatrace.v1.device-id=YOUR_DEVICE_IDmanagement:
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=30smanagement:
metrics:
export:
dynatrace:
step: "30s"您可以在 Micrometer 文档和 Dynatrace 文档中找到有关如何为 Micrometer 设置 Dynatrace 导出器的更多信息。
6.2.5. 弹性
默认情况下，指标会导出到本地计算机上运行的 Elastic。 您可以使用以下属性提供要使用的弹性服务器的位置：
management.metrics.export.elastic.host=https://elastic.example.com:8086management:
metrics:
export:
elastic:
host: "https://elastic.example.com:8086"6.2.6. 神经节
默认情况下，指标将导出到本地计算机上运行的 Ganglia。 您可以提供 Ganglia 服务器主机和端口，如下例所示：
management.metrics.export.ganglia.host=ganglia.example.com
management.metrics.export.ganglia.port=9649management:
metrics:
export:
ganglia:
host: "ganglia.example.com"
port: 96496.2.7. 石墨
默认情况下，指标会导出到本地计算机上运行的 Graphite。 您可以提供 Graphite 服务器主机和端口，如下例所示：
management.metrics.export.graphite.host=graphite.example.com
management.metrics.export.graphite.port=9004management:
metrics:
export:
graphite:
host: "graphite.example.com"
port: 9004Micrometer 提供默认的HierarchicalNameMapper控制维度计量器 ID 如何映射到平面分层名称。
|
要控制此行为，请定义 Java
Kotlin
|
6.2.8. 鹰号
默认情况下，Humio 注册表会定期将指标推送到 cloud.humio.com。 要将指标导出到 SaaS Humio，您必须提供 API 令牌：
management.metrics.export.humio.api-token=YOUR_TOKENmanagement:
metrics:
export:
humio:
api-token: "YOUR_TOKEN"您还应配置一个或多个标签，以标识将指标推送到的数据源：
management.metrics.export.humio.tags.alpha=a
management.metrics.export.humio.tags.bravo=bmanagement:
metrics:
export:
humio:
tags:
alpha: "a"
bravo: "b"6.2.9. 流入
默认情况下，指标会导出到使用默认配置在本地计算机上运行的 Influx v1 实例。
要将指标导出到 InfluxDB v2，请配置org,bucket和 authenticationtoken用于编写指标。
您可以使用以下方法提供要使用的 Influx 服务器的位置：
management.metrics.export.influx.uri=https://influx.example.com:8086management:
metrics:
export:
influx:
uri: "https://influx.example.com:8086"6.2.10. JMX
Micrometer 提供到 JMX 的分层映射，主要作为一种在本地查看指标的廉价且可移植的方式。
默认情况下，指标将导出到metricsJMX 域。
您可以使用以下方法提供要使用的域：
management.metrics.export.jmx.domain=com.example.app.metricsmanagement:
metrics:
export:
jmx:
domain: "com.example.app.metrics"Micrometer 提供默认的HierarchicalNameMapper控制维度计量器 ID 如何映射到平面分层名称。
|
要控制此行为，请定义 Java
Kotlin
|
6.2.11. Kairos数据库
默认情况下，指标将导出到本地计算机上运行的 KairosDB。 您可以使用以下方法提供要使用的 KairosDB 服务器的位置：
management.metrics.export.kairos.uri=https://kairosdb.example.com:8080/api/v1/datapointsmanagement:
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
management.metrics.export.newrelic.account-id=YOUR_ACCOUNT_IDmanagement:
metrics:
export:
newrelic:
api-key: "YOUR_KEY"
account-id: "YOUR_ACCOUNT_ID"您还可以更改将指标发送到 New Relic 的间隔：
management.metrics.export.newrelic.step=30smanagement:
metrics:
export:
newrelic:
step: "30s"默认情况下，指标是通过 REST 调用发布的，但如果您在 Classpath 上有 Java 代理 API，也可以使用它：
management.metrics.export.newrelic.client-provider-type=insights-agentmanagement:
metrics:
export:
newrelic:
client-provider-type: "insights-agent"最后，您可以通过定义自己的NewRelicClientProvider豆。
6.2.13. 普罗米修斯
Prometheus 希望抓取或轮询单个应用程序实例的指标。
Spring Boot 在/actuator/prometheus以适当格式呈现 Prometheus 抓取。
| 默认情况下，终端节点不可用，必须公开。有关更多详细信息，请参阅公开终端节点。 |
以下示例scrape_config添加到prometheus.yml:
scrape_configs:
- job_name: "spring"
metrics_path: "/actuator/prometheus"
static_configs:
- targets: ["HOST:PORT"]还支持 Prometheus Exemplars。要启用此功能，需要SpanContextSupplierbean 应该出现。如果您使用 Spring Cloud Sleuth，这将为您自动配置，但您可以根据需要随时创建自己的。
请查看 Prometheus 文档，因为此功能需要在 Prometheus 端明确启用，并且仅支持使用 OpenMetrics 格式。
对于存在时间不够长而无法抓取的临时或批处理作业，您可以使用 Prometheus Pushgateway 支持向 Prometheus 公开指标。 要启用 Prometheus Pushgateway 支持，请将以下依赖项添加到您的项目中：
<dependency>
<groupId>io.prometheus</groupId>
<artifactId>simpleclient_pushgateway</artifactId>
</dependency>当 Prometheus Pushgateway 依赖项存在于 Classpath 上并且management.metrics.export.prometheus.pushgateway.enabled属性设置为true一个PrometheusPushGatewayManagerbean 是自动配置的。
这将管理将指标推送到 Prometheus Pushgateway。
您可以调整PrometheusPushGatewayManager通过使用management.metrics.export.prometheus.pushgateway.
对于高级配置，您还可以提供自己的PrometheusPushGatewayManager豆。
6.2.14. 信号Fx
management.metrics.export.signalfx.access-token=YOUR_ACCESS_TOKENmanagement:
metrics:
export:
signalfx:
access-token: "YOUR_ACCESS_TOKEN"您还可以更改将指标发送到 SignalFx 的间隔：
management.metrics.export.signalfx.step=30smanagement:
metrics:
export:
signalfx:
step: "30s"6.2.15. 简单
Micrometer 附带了一个简单的内存后端，如果未配置其他注册表，则会自动用作后备。 这样，您就可以查看 metrics 终端节点中收集了哪些指标。
一旦您使用任何其他可用的后端，内存中后端就会自行禁用。 您也可以显式禁用它：
management.metrics.export.simple.enabled=falsemanagement:
metrics:
export:
simple:
enabled: false6.2.16. 堆栈驱动
Stackdriver 注册表会定期将指标推送到 Stackdriver。 要将指标导出到 SaaS Stackdriver，您必须提供您的 Google Cloud 项目 ID：
management.metrics.export.stackdriver.project-id=my-projectmanagement:
metrics:
export:
stackdriver:
project-id: "my-project"您还可以更改将指标发送到 Stackdriver 的时间间隔：
management.metrics.export.stackdriver.step=30smanagement:
metrics:
export:
stackdriver:
step: "30s"6.2.17. 统计 D
StatsD 注册表急切地通过 UDP 将指标推送到 StatsD 代理。 默认情况下，指标将导出到本地计算机上运行的 StatsD 代理。 您可以使用以下方法提供要使用的 StatsD 代理主机、端口和协议：
management.metrics.export.statsd.host=statsd.example.com
management.metrics.export.statsd.port=9125
management.metrics.export.statsd.protocol=udpmanagement:
metrics:
export:
statsd:
host: "statsd.example.com"
port: 9125
protocol: "udp"您还可以更改要使用的 StatsD 线路协议（默认为 Datadog）：
management.metrics.export.statsd.flavor=etsymanagement:
metrics:
export:
statsd:
flavor: "etsy"6.2.18. 波前
management.metrics.export.wavefront.api-token=YOUR_API_TOKENmanagement:
metrics:
export:
wavefront:
api-token: "YOUR_API_TOKEN"或者，您可以在环境中使用 Wavefront sidecar 或内部代理将指标数据转发到 Wavefront API 主机：
management.metrics.export.wavefront.uri=proxy://localhost:2878management:
metrics:
export:
wavefront:
uri: "proxy://localhost:2878"如果您将指标发布到 Wavefront 代理（如 Wavefront 文档中所述），则主机必须位于proxy://HOST:PORT格式。 |
您还可以更改将指标发送到 Wavefront 的间隔：
management.metrics.export.wavefront.step=30smanagement:
metrics:
export:
wavefront:
step: "30s"6.3. 支持的度量和计量
Spring Boot 为各种技术提供自动仪表注册。 在大多数情况下，默认值提供合理的指标，这些指标可以发布到任何受支持的监控系统。
6.3.1. JVM 度量
自动配置通过使用核心 Micrometer 类启用 JVM 指标。
JVM 指标发布在jvm.计量名称。
提供了以下 JVM 指标：
-
各种内存和缓冲池详细信息
-
垃圾回收相关统计
-
线程利用率
-
加载和卸载的类数
6.3.2. 系统度量
自动配置通过使用核心 Micrometer 类来启用系统指标。
系统指标发布在system.,process.和disk.计量名称。
提供了以下系统指标：
-
CPU 指标
-
文件描述符指标
-
正常运行时间指标（应用程序已运行的时间量和绝对开始时间的固定衡量标准）
-
可用磁盘空间
6.3.3. 应用程序启动指标
自动配置会公开应用程序启动时间指标：
-
application.started.time：启动应用程序所花费的时间。 -
application.ready.time：应用程序准备好为请求提供服务所花费的时间。
指标由应用程序类的完全限定名称标记。
6.3.5. 任务执行和调度指标
自动配置支持所有可用ThreadPoolTaskExecutor和ThreadPoolTaskScheduler豆子，只要下属ThreadPoolExecutor可用。
度量由执行程序的名称标记，该名称派生自 Bean 名称。
6.3.6. Spring MVC 度量
自动配置可以检测 Spring MVC 控制器和功能处理程序处理的所有请求。
默认情况下，使用名称http.server.requests.
您可以通过设置management.metrics.web.server.request.metric-name财产。
@Timed支持 Comments@Controllerclasses 和@RequestMapping方法（有关详细信息，请参阅 @Timed Annotation Support）。
如果不想记录所有 Spring MVC 请求的 metrics，则可以设置management.metrics.web.server.request.autotime.enabled自false并专门使用@Timedannotations 来代替。
默认情况下，Spring MVC 相关指标使用以下信息进行标记：
| 标记 | 描述 |
|---|---|
|
处理请求时引发的任何异常的简单类名。 |
|
请求的方法（例如 |
|
请求的结果，基于响应的状态代码。
1xx 是 |
|
响应的 HTTP 状态代码（例如 |
|
变量替换之前的请求的 URI 模板（如果可能）（例如 |
要添加到默认标签，请提供一个或多个@Bean实现WebMvcTagsContributor.
要替换默认标签，请提供@Bean实现WebMvcTagsProvider.
| 在某些情况下，在 Web 控制器中处理的异常不会记录为请求指标标签。 应用程序可以通过将已处理的异常设置为请求属性来选择加入并记录异常。 |
默认情况下，将处理所有请求。
要自定义过滤器，请提供@Bean实现FilterRegistrationBean<WebMvcMetricsFilter>.
6.3.7. Spring WebFlux 度量
自动配置允许检测 Spring WebFlux 控制器和功能处理程序处理的所有请求。
默认情况下，使用名称http.server.requests.
您可以通过设置management.metrics.web.server.request.metric-name财产。
@Timed支持 Comments@Controllerclasses 和@RequestMapping方法（有关详细信息，请参阅 @Timed Annotation Support）。
如果不想记录所有 Spring WebFlux 请求的度量，则可以设置management.metrics.web.server.request.autotime.enabled自false并专门使用@Timedannotations 来代替。
默认情况下，WebFlux 相关指标使用以下信息进行标记：
| 标记 | 描述 |
|---|---|
|
处理请求时引发的任何异常的简单类名。 |
|
请求的方法（例如 |
|
请求的结果，基于响应的状态代码。
1xx 是 |
|
响应的 HTTP 状态代码（例如 |
|
变量替换之前的请求的 URI 模板（如果可能）（例如 |
要添加到默认标记，请提供一个或多个实现WebFluxTagsContributor.
要替换默认标记，请提供一个实现WebFluxTagsProvider.
| 在某些情况下，控制器和处理程序函数中处理的异常不会记录为请求指标标签。 应用程序可以通过将已处理的异常设置为请求属性来选择加入并记录异常。 |
6.3.8. Jersey 服务器度量
自动配置允许检测 Jersey JAX-RS 实现处理的所有请求。
默认情况下，使用名称http.server.requests.
您可以通过设置management.metrics.web.server.request.metric-name财产。
@Timed请求处理类和方法支持 Comments（有关详细信息，请参阅 @Timed Annotation Support）。
如果您不想记录所有 Jersey 请求的指标，则可以设置management.metrics.web.server.request.autotime.enabled自false并专门使用@Timedannotations 来代替。
默认情况下，Jersey 服务器指标使用以下信息进行标记：
| 标记 | 描述 |
|---|---|
|
处理请求时引发的任何异常的简单类名。 |
|
请求的方法（例如 |
|
请求的结果，基于响应的状态代码。
1xx 是 |
|
响应的 HTTP 状态代码（例如 |
|
变量替换之前的请求的 URI 模板（如果可能）（例如 |
要自定义标签，请提供@Bean实现JerseyTagsProvider.
6.3.9. HTTP 客户端度量
Spring Boot Actuator 管理两者的插桩RestTemplate和WebClient.
为此，您必须注入自动配置的构建器并使用它来创建实例：
-
RestTemplateBuilder为RestTemplate -
WebClient.Builder为WebClient
您还可以手动应用负责此插桩的定制器，即MetricsRestTemplateCustomizer和MetricsWebClientCustomizer.
默认情况下，使用名称http.client.requests.
您可以通过设置management.metrics.web.client.request.metric-name财产。
默认情况下，分析的客户端生成的指标使用以下信息进行标记：
| 标记 | 描述 |
|---|---|
|
URI 的主机部分 |
|
请求的方法（例如 |
|
请求的结果，基于响应的状态代码。
1xx 是 |
|
响应的 HTTP 状态代码（如果可用）（例如 |
|
变量替换之前的请求的 URI 模板（如果可能）（例如 |
要自定义标签，并根据您选择的客户端，您可以提供@Bean实现RestTemplateExchangeTagsProvider或WebClientExchangeTagsProvider.
中有方便的静态函数RestTemplateExchangeTags和WebClientExchangeTags.
如果您不想记录所有RestTemplate和WebClient请求， 设置management.metrics.web.client.request.autotime.enabled自false.
6.3.10. Tomcat 度量
自动配置仅在MBeanRegistry已启用。
默认情况下，MBeanRegistry已禁用，但您可以通过设置server.tomcat.mbeanregistry.enabled自true.
Tomcat 指标发布在tomcat.计量名称。
6.3.11. 缓存指标
自动配置支持所有可用Cache实例，其指标前缀为cache.
缓存插桩是针对一组基本指标进行标准化的。
此外，还提供了特定于缓存的指标。
支持以下缓存库：
-
缓存2k
-
咖啡因
-
EhCache 2
-
Hazelcast
-
任何兼容的 JCache （JSR-107） 实现
-
Redis
指标按缓存名称和CacheManager，该名称派生自 Bean 名称。
只有在启动时配置的缓存才会绑定到注册表。
对于未在缓存配置中定义的缓存，例如在启动阶段之后动态或以编程方式创建的缓存，需要显式注册。
一个CacheMetricsRegistrarbean 的可用使该过程更容易。 |
6.3.12. Spring GraphQL 指标
自动配置支持对任何支持的传输进行 GraphQL 查询检测。
Spring Boot 会记录一个graphql.requesttimer 替换为：
| 标记 | 描述 | 示例值 |
|---|---|---|
结果 |
请求结果 |
“成功”， “错误” |
单个 GraphQL 查询可能涉及多个DataFetcher调用，因此有一个专用的graphql.datafetcher定时器：
| 标记 | 描述 | 示例值 |
|---|---|---|
路径 |
数据获取器路径 |
“Query.project” |
结果 |
数据获取结果 |
“成功”， “错误” |
这graphql.request.datafetch.count 分布汇总统计非平凡数量DataFetcher根据请求进行的调用。
此指标可用于检测 “N+1” 数据获取问题和考虑批量加载;它提供"TOTAL"通过"COUNT"记录的请求数，以及"MAX"在考虑的时间段内对单个请求进行的调用。
有更多选项可用于配置具有应用程序属性的分配。
单个响应可以包含许多 GraphQL 错误，由graphql.error计数器：
| 标记 | 描述 | 示例值 |
|---|---|---|
errorType 错误类型 |
错误类型 |
“DataFetchingException” |
错误路径 |
错误 JSON 路径 |
“$.project” 项目 |
6.3.13. DataSource 度量
自动配置支持所有可用DataSource指标前缀为jdbc.connections.
数据源检测会生成表示池中当前活动、空闲、允许的最大连接数和允许的最小连接的仪表。
Metrics 也由DataSource根据 bean 名称计算。
默认情况下， Spring Boot 为所有支持的数据源提供元数据。
您可以添加其他DataSourcePoolMetadataProviderbeans（如果您最喜欢的数据源不受支持）。
看DataSourcePoolMetadataProvidersConfiguration例如。 |
此外，特定于 Hikari 的指标通过hikaricp前缀。
每个指标都由池的名称进行标记（您可以使用spring.datasource.name).
6.3.14. Hibernate 指标
如果org.hibernate:hibernate-micrometer在 Classpath 上，所有可用的 HibernateEntityManagerFactory启用了统计信息的实例将使用名为hibernate.
Metrics 也由EntityManagerFactory，该名称派生自 Bean 名称。
要启用统计信息，标准 JPA 属性hibernate.generate_statistics必须设置为true.
您可以在自动配置的EntityManagerFactory:
spring.jpa.properties[hibernate.generate_statistics]=truespring:
jpa:
properties:
"[hibernate.generate_statistics]": true6.3.15. Spring Data Repository 指标
自动配置支持所有 Spring Data 的检测Repository方法调用。
默认情况下，使用名称spring.data.repository.invocations.
您可以通过设置management.metrics.data.repository.metric-name财产。
@Timed支持 CommentsRepository类和方法（有关详细信息，请参阅 @Timed Annotation Support）。
如果您不想记录所有Repositoryinvocations，您可以设置management.metrics.data.repository.autotime.enabled自false并专门使用@Timedannotations 来代替。
默认情况下，存储库调用相关指标使用以下信息进行标记：
| 标记 | 描述 |
|---|---|
|
源的简单类名 |
|
的名称 |
|
结果状态 （ |
|
从调用中引发的任何异常的简单类名。 |
要替换默认标签，请提供@Bean实现RepositoryTagsProvider.
6.3.17. Spring 集成度量
Spring 集成会自动提供 Micrometer 支持，只要有MeterRegistryBean 可用。
指标发布在spring.integration.计量名称。
6.3.18. Kafka 指标
自动配置会注册一个MicrometerConsumerListener和MicrometerProducerListener分别用于 auto-configured Consumer Factory 和 Producer Factory。
它还注册了一个KafkaStreamsMicrometerListener为StreamsBuilderFactoryBean.
有关更多详细信息，请参阅 Spring Kafka 文档的 Micrometer Native Metrics 部分。
6.3.19. 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报告连接池的当前大小，包括 Idle 和 In-use 成员。 -
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: false6.3.20. Jetty 度量
自动配置绑定 Jetty 的ThreadPool通过使用 Micrometer 的JettyServerThreadPoolMetrics.
Jetty's 的指标Connector实例使用 Micrometer 的JettyConnectionMetrics并且，当server.ssl.enabled设置为true、千分尺的JettySslHandshakeMetrics.
6.3.21. @Timed 注解支持
您可以使用@Timed注解io.micrometer.core.annotation与前面描述的几种受支持技术一起打包。
如果支持，您可以在类级别或方法级别使用注释。
例如，下面的代码显示了如何使用注解来检测@RestController:
@RestController
@Timed
public class MyController {
@GetMapping("/api/addresses")
public List<Address> listAddress() {
return ...
}
@GetMapping("/api/people")
public List<Person> listPeople() {
return ...
}
}
@RestController
@Timed
class MyController {
@GetMapping("/api/addresses")
fun listAddress(): List<Address>? {
return ...
}
@GetMapping("/api/people")
fun listPeople(): List<Person>? {
return ...
}
}
如果只想检测单个 Map，则可以在方法上使用 Comments 而不是 Class：
@RestController
public class MyController {
@GetMapping("/api/addresses")
public List<Address> listAddress() {
return ...
}
@GetMapping("/api/people")
@Timed
public List<Person> listPeople() {
return ...
}
}
@RestController
class MyController {
@GetMapping("/api/addresses")
fun listAddress(): List<Address>? {
return ...
}
@GetMapping("/api/people")
@Timed
fun listPeople(): List<Person>? {
return ...
}
}
如果要更改特定方法的计时详细信息，还可以组合 class-level 和 method-level annotations：
@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 ...
}
}
@RestController
@Timed
class MyController {
@GetMapping("/api/addresses")
fun listAddress(): List<Address>? {
return ...
}
@GetMapping("/api/people")
@Timed(value = "all.people", longTask = true, extraTags = ["region", "us-east-1"])
fun listPeople(): List<Person>? {
return ...
}
}
一个@Timedannotation 替换为longTask = true为方法启用长任务计时器。
长任务计时器需要单独的指标名称，并且可以与短任务计时器堆叠。 |
要使用@Timed如果 Spring Boot 不直接支持它，请参阅 Micrometer 文档。 |
6.3.22. Redis 指标
自动配置会注册一个MicrometerCommandLatencyRecorder对于自动配置的LettuceConnectionFactory.
有关更多详细信息，请参阅 Lettuce 文档的 Micrometer Metrics 部分。
6.4. 注册自定义度量
要注册自定义指标，请注入MeterRegistry添加到您的组件中：
@Component
public class MyBean {
private final Dictionary dictionary;
public MyBean(MeterRegistry registry) {
this.dictionary = Dictionary.load();
registry.gauge("dictionary.size", Tags.empty(), this.dictionary.getWords().size());
}
}
@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如果您发现跨组件或应用程序重复检测一套指标，则 implementation 也很有用。
默认情况下，来自所有MeterBinderbean 会自动绑定到 Spring 管理的MeterRegistry. |
6.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 Management 的全局注册表。 |
6.5.1. 通用标签
常用标签通常用于对运行环境进行维度下钻，例如主机、实例、区域、堆栈等。 Commons 标签应用于所有计量，并且可以进行配置，如下例所示：
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，则常用标签的顺序非常重要。
由于使用这种方法无法保证常用 tag 的顺序，因此建议 Graphite 用户定义自定义MeterFilter相反。 |
6.5.2. 每米属性
除了MeterFilterbean 中，您可以使用 properties 按计量应用一组有限的自定义。
使用 Spring Boot 的PropertiesMeterFilter，添加到以给定名称开头的任何计量 ID 中。
以下示例筛选出 ID 以example.remote.
management.metrics.enable.example.remote=falsemanagement:
metrics:
enable:
example:
remote: false以下属性允许按计量进行自定义：
| 财产 | 描述 |
|---|---|
|
是否接受具有特定 ID 的仪表。
不接受的计量将从 |
|
是否发布适合计算可聚合（跨维度）百分位数近似值的直方图。 |
|
通过限制预期值的范围来发布更少的直方图存储桶。 |
|
发布在应用程序中计算的百分位值 |
|
通过将最近的样本累积在可配置的到期后轮换的环形缓冲区中，赋予最近的样本更大的权重，其中 可配置的缓冲区长度。 |
|
发布包含由服务级别目标定义的存储桶的累积直方图。 |
有关背后概念的更多详细信息percentiles-histogram,percentiles和slo，请参阅 Micrometer 文档的“直方图和百分位数”部分。
6.6. Metrics 端点
Spring Boot 提供了一个metrics终端节点，您可以诊断性地使用它来检查应用程序收集的指标。
默认情况下，终端节点不可用，必须公开。有关更多详细信息，请参阅公开终端节点。
导航到/actuator/metrics显示可用计量器名称的列表。
您可以通过提供特定计量的名称作为选择器来深入查看有关该计量的信息，例如，/actuator/metrics/jvm.memory.max.
|
您在此处使用的名称应与代码中使用的名称匹配，而不是与针对其寄送到的监控系统进行命名约定规范化后的名称匹配。
换句话说，如果 |
您还可以添加任意数量的tag=KEY:VALUEquery 参数添加到网址末尾，以维度向下钻取仪表 — 例如，/actuator/metrics/jvm.memory.max?tag=area:nonheap.
|
报告的测量值是与仪表名称和已应用的任何标签匹配的所有仪表的统计数据的总和。
在前面的示例中，返回的 |
7. 审计
一旦 Spring Security 开始发挥作用， Spring Boot Actuator 就会有一个灵活的审计框架来发布事件（默认情况下，“身份验证成功”、“失败”和“访问被拒绝”异常）。 此功能对于报告和实施基于身份验证失败的锁定策略非常有用。
您可以通过提供AuditEventRepository在应用程序的配置中。
为方便起见， Spring Boot 提供了一个InMemoryAuditEventRepository.InMemoryAuditEventRepository功能有限，我们建议仅将其用于开发环境。
对于生产环境，请考虑创建自己的替代方案AuditEventRepository实现。
8. HTTP 跟踪
您可以通过提供HttpTraceRepository在应用程序的配置中。
为方便起见，Spring Boot 提供了InMemoryHttpTraceRepository，它存储最近 100 次（默认）请求-响应交换的跟踪。InMemoryHttpTraceRepository与其他跟踪解决方案相比受到限制，我们建议仅将其用于开发环境。
对于生产环境，我们建议使用生产就绪的跟踪或可观测性解决方案，例如 Zipkin 或 Spring Cloud Sleuth。
或者，您可以创建自己的HttpTraceRepository.
您可以使用httptrace端点获取有关存储在HttpTraceRepository.
9. 过程监控
在spring-boot模块中，您可以找到两个类来创建通常对进程监控有用的文件：
-
ApplicationPidFileWriter创建一个包含应用程序 PID 的文件（默认情况下，在应用程序目录中，文件名为application.pid). -
WebServerPortFileWriter创建一个文件（或多个文件），其中包含正在运行的 Web 服务器的端口（默认情况下，在应用程序目录中，文件名为application.port).
默认情况下，这些写入器未激活，但您可以启用它们：
10. Cloud Foundry 支持
Spring Boot 的 actuator 模块包括额外的支持，当您部署到兼容的 Cloud Foundry 实例时，将激活这些支持。
这/cloudfoundryapplicationpath 为所有@Endpoint豆。
扩展支持允许使用 Spring Boot 执行器信息来增强 Cloud Foundry 管理 UI（例如可用于查看已部署应用程序的 Web 应用程序）。 例如，应用程序状态页面可以包含完整的运行状况信息，而不是典型的“正在运行”或“已停止”状态。
这/cloudfoundryapplicationpath 无法直接访问。
要使用终端节点，您必须在请求中传递有效的 UAA 令牌。 |
10.1. 禁用扩展的 Cloud Foundry Actuator 支持
如果要完全禁用/cloudfoundryapplication端点，您可以将以下设置添加到application.properties文件：
management.cloudfoundry.enabled=falsemanagement:
cloudfoundry:
enabled: false10.2. Cloud Foundry 自签名证书
默认情况下，对/cloudfoundryapplicationendpoints 对各种 Cloud Foundry 服务进行 SSL 调用。
如果您的 Cloud Foundry UAA 或 Cloud Controller 服务使用自签名证书，则需要设置以下属性：
management.cloudfoundry.skip-ssl-validation=truemanagement:
cloudfoundry:
skip-ssl-validation: true10.3. 自定义上下文路径
如果服务器的 context-path 已配置为 以外的任何内容，则 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("/*")
}
}
}