生产就绪功能
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。
例如,默认情况下,health
endpoint 映射到/actuator/health
.
以下与技术无关的终结点可用:
如果您的应用程序是 Web 应用程序(Spring MVC、Spring WebFlux 或 Jersey),则可以使用以下其他端点:
身份证 | 描述 |
---|---|
|
返回堆转储文件。
在 HotSpot JVM 上,一个 |
|
当 Jolokia 在类路径上时,通过 HTTP 公开 JMX bean(不适用于 WebFlux)。
需要依赖于 |
|
返回日志文件的内容(如果 |
|
以可由 Prometheus 服务器抓取的格式公开指标。
需要依赖于 |
2.1. 启用端点
默认情况下,除shutdown
已启用。
要配置端点的启用,请使用其management.endpoint.<id>.enabled
财产。
以下示例启用shutdown
端点:
management.endpoint.shutdown.enabled=true
management:
endpoint:
shutdown:
enabled: true
如果您希望终端启用是选择加入而不是选择退出,请将management.endpoints.enabled-by-default
属性设置为false
并使用单个端点enabled
属性以选择重新加入。
以下示例启用info
端点并禁用所有其他端点:
management.endpoints.enabled-by-default=false
management.endpoint.info.enabled=true
management:
endpoints:
enabled-by-default: false
endpoint:
info:
enabled: true
禁用的终结点将从应用程序上下文中完全删除。
如果只想更改公开端点的技术,请使用include 和exclude 性能相反。 |
2.2. 公开端点
由于端点可能包含敏感信息,因此应仔细考虑何时公开它们。 下表显示了内置终结点的默认公开:
身份证 | JMX公司 | Web |
---|---|---|
|
是的 |
不 |
|
是的 |
不 |
|
是的 |
不 |
|
是的 |
不 |
|
是的 |
不 |
|
是的 |
不 |
|
是的 |
不 |
|
是的 |
是的 |
|
不适用 |
不 |
|
是的 |
不 |
|
是的 |
不 |
|
是的 |
不 |
|
不适用 |
不 |
|
不适用 |
不 |
|
是的 |
不 |
|
是的 |
不 |
|
是的 |
不 |
|
是的 |
不 |
|
不适用 |
不 |
|
是的 |
不 |
|
是的 |
不 |
|
是的 |
不 |
|
是的 |
不 |
|
是的 |
不 |
|
是的 |
不 |
若要更改要公开的终结点,请使用以下特定于技术的include
和exclude
性能:
属性 | 默认值 |
---|---|
|
|
|
|
|
|
|
|
这include
属性列出了公开的端点的 ID。
这exclude
属性列出了不应公开的端点的 ID。
这exclude
属性优先于include
财产。
您可以配置include
和exclude
属性,其中包含端点 ID 列表。
例如,要停止通过 JMX 公开所有端点,而仅公开health
和info
endpoints,请使用以下属性:
management.endpoints.jmx.exposure.include=health,info
management:
endpoints:
jmx:
exposure:
include: "health,info"
*
可用于选择所有端点。
例如,要通过 HTTP 公开除env
和beans
endpoints,请使用以下属性:
management.endpoints.web.exposure.include=*
management.endpoints.web.exposure.exclude=env,beans
management:
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 在类路径上并且没有其他WebSecurityConfigurerAdapter
或SecurityFilterChain
bean 存在,除/health
由 Spring Boot 自动配置保护。
如果定义自定义WebSecurityConfigurerAdapter
或SecurityFilterChain
bean,Spring Boot 自动配置会回退,让你完全控制执行器访问规则。
如果您希望为 HTTP 端点配置自定义安全性(例如,仅允许具有特定角色的用户访问它们),Spring Boot 提供了一些方便的RequestMatcher
可以与 Spring Security 结合使用的对象。
典型的 Spring Security 配置可能类似于以下示例:
@Configuration(proxyBeanMethods = false)
public class MySecurityConfiguration {
@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
http.requestMatcher(EndpointRequest.toAnyEndpoint());
http.authorizeRequests((requests) -> requests.anyRequest().hasRole("ENDPOINT_ADMIN"));
http.httpBasic(withDefaults());
return http.build();
}
}
@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)。
如果将应用程序部署在防火墙后面,则可能希望无需身份验证即可访问所有执行器端点。为此,您可以将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()
}
}
在上述两个示例中,配置仅适用于执行器端点。
由于 Spring Boot 的安全配置在存在任何SecurityFilterChain bean,您需要配置一个额外的SecurityFilterChain bean 具有适用于应用程序其余部分的规则。 |
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=10s
management:
endpoint:
beans:
cache:
time-to-live: "10s"
这management.endpoint.<name> prefix 唯一标识正在配置的终结点。 |
2.5. 执行器 Web 端点的超介质
将添加一个“发现页面”,其中包含指向所有端点的链接。
“发现页面”可在/actuator
默认情况下。
若要禁用“发现页”,请将以下属性添加到应用程序属性:
management.endpoints.web.discovery.enabled=false
management:
endpoints:
web:
discovery:
enabled: false
配置自定义管理上下文路径后,“发现页面”会自动从/actuator
到管理上下文的根目录。
例如,如果管理上下文路径为/management
,则发现页面可从/management
.
当管理上下文路径设置为 时,将禁用发现页面,以防止与其他映射发生冲突的可能性。/
2.6. CORS 支持
跨域资源共享 (CORS) 是 W3C 规范,允许您以灵活的方式指定授权的跨域请求类型。 如果您使用 Spring MVC 或 Spring WebFlux,则可以配置 Actuator 的 Web 端点以支持此类场景。
默认情况下,CORS 支持处于禁用状态,并且仅在将management.endpoints.web.cors.allowed-origins
财产。 以下配置允许GET
和POST
来自example.com
域:
management.endpoints.web.cors.allowed-origins=https://example.com
management.endpoints.web.cors.allowed-methods=GET,POST
management:
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 和counter 不支持属性。 |
为了让输入映射到作方法的参数,实现端点的 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
.
此类参数将作为路径变量添加到路径谓词中。
调用端点作时,变量的值将传递到作方法中。
如果要捕获所有剩余的路径元素,可以将@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(未找到)。
如果@WriteOperation
或@DeleteOperation
返回一个值,响应状态将为 200 (OK)。
如果它不返回值,则响应状态将为 204(无内容)。
如果调用作时没有必需参数或参数无法转换为所需类型,则不会调用作方法,响应状态将为 400(错误请求)。
2.8. 健康信息
您可以使用运行状况信息来检查正在运行的应用程序的状态。
监控软件通常使用它来在生产系统出现故障时向某人发出警报。
由health
endpoint 依赖于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.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
可用,但默认情况下未启用:
钥匙 | 名称 | 描述 |
---|---|---|
|
公开“活动”应用程序可用性状态。 |
|
|
公开“就绪”应用程序可用性状态。 |
2.8.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.order
configuration 属性。
例如,假设新的Status
代码为FATAL
正在您的一个HealthIndicator
实现。
要配置严重性顺序,请将以下属性添加到应用程序属性:
management.endpoint.health.status.order=fatal,down,out-of-service,unknown,up
management:
endpoint:
health:
status:
order: "fatal,down,out-of-service,unknown,up"
响应中的 HTTP 状态代码反映了整体运行状况。
默认情况下,OUT_OF_SERVICE
和DOWN
映射到 503。
任何未映射的运行状况,包括UP
,映射到 200。
如果通过 HTTP 访问运行状况终结点,您可能还需要注册自定义状态映射。
配置自定义映射会禁用DOWN
和OUT_OF_SERVICE
.
如果要保留默认映射,则必须显式配置它们以及任何自定义映射。
例如,以下属性映射FATAL
设置为 503(服务不可用),并保留DOWN
和OUT_OF_SERVICE
:
management.endpoint.health.status.http-mapping.down=503
management.endpoint.health.status.http-mapping.fatal=503
management.endpoint.health.status.http-mapping.out-of-service=503
management:
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 在弹性调度程序上执行。
在响应式应用程序中,您应该使用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 未显式处理的自动包装。 |
2.8.5. 健康组
有时将健康指标组织成可用于不同目的的组很有用。
要创建运行状况指示器组,您可以使用management.endpoint.health.group.<name>
属性,并指定运行状况指示器 ID 列表,以include
或exclude
.
例如,要创建仅包含数据库指示器的组,您可以定义以下内容:
management.endpoint.health.group.custom.include=db
management:
endpoint:
health:
group:
custom:
include: "db"
然后您可以通过点击localhost:8080/actuator/health/custom
.
同样,要创建一个从组中排除数据库指示器并包括所有其他指示器的组,您可以定义以下内容:
management.endpoint.health.group.custom.exclude=db
management:
endpoint:
health:
group:
custom:
exclude: "db"
默认情况下,组继承相同的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=500
management:
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.9. 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.enabled
configuration 属性。
如果应用程序启动时间超过配置的活跃期,Kubernetes 会提到"startupProbe" 作为可能的解决方案。
一般来说,"startupProbe" 这里不一定需要,因为"readinessProbe" 失败,直到所有启动任务完成。
这意味着您的应用程序在准备就绪之前不会接收流量。
但是,如果您的应用程序需要很长时间才能启动,请考虑使用"startupProbe" 以确保 Kubernetes 不会在应用程序启动过程中终止您的应用程序。
请参阅描述探测在应用程序生命周期中如何运行的部分。 |
如果执行器端点部署在单独的管理上下文中,则端点不会使用与主应用程序相同的 Web 基础结构(端口、连接池、框架组件)。
在这种情况下,即使主应用程序无法正常工作(例如,它无法接受新连接),探测检查也可能成功。
因此,将liveness
和readiness
主服务器端口上可用的运行状况组。
这可以通过设置以下属性来完成:
management.endpoint.health.probes.add-additional-paths=true
这将使liveness
团体可在以下位置购买/livez
和readiness
团体可在以下位置购买/readyz
在主服务器端口上。
可以使用additional-path
属性,请参阅运行状况组了解详细信息。
2.9.1. 使用 Kubernetes 探针检查外部状态
执行器将“活动”和“就绪”探测配置为运行状况组。 这意味着所有运行状况组功能都可供他们使用。 例如,您可以配置其他运行状况指示器:
management.endpoint.health.group.readiness.include=readinessState,customCheck
management:
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.9.2. 应用程序生命周期和探测状态
Kubernetes 探针支持的一个重要方面是它与应用程序生命周期的一致性。
之间存在显着差异AvailabilityState
(即应用程序的内存内部状态)
以及实际的探针(暴露了该状态)。
根据应用程序生命周期的阶段,探测可能不可用。
Spring Boot 在启动和关闭期间发布应用程序事件,
探测器可以监听此类事件并公开AvailabilityState
信息。
下表显示了AvailabilityState
以及不同阶段的 HTTP 连接器状态。
当 Spring Boot 应用程序启动时:
启动阶段 | LivenessState | 就绪状态 | HTTP 服务器 | 笔记 |
---|---|---|---|---|
开始 |
|
|
未开始 |
Kubernetes 会检查“活动性”探针,如果时间过长,则重新启动应用程序。 |
开始 |
|
|
拒绝请求 |
应用程序上下文将刷新。应用程序执行启动任务,但尚未接收流量。 |
准备 |
|
|
接受请求 |
启动任务已完成。应用程序正在接收流量。 |
当 Spring Boot 应用程序关闭时:
关机阶段 | 活跃状态 | 就绪状态 | HTTP 服务器 | 笔记 |
---|---|---|---|---|
运行 |
|
|
接受请求 |
已请求关闭。 |
正常关机 |
|
|
新请求被拒绝 |
如果启用,则正常关闭会处理正在进行的请求。 |
关机完成 |
不适用 |
不适用 |
服务器已关闭 |
应用程序上下文已关闭,应用程序已关闭。 |
有关 Kubernetes 部署的更多信息,请参阅 Kubernetes 容器生命周期部分。 |
2.10. 应用信息
应用程序信息公开从所有InfoContributor
bean 在ApplicationContext
.
Spring Boot 包括许多自动配置的InfoContributor
bean,你可以自己写。
2.10.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.10.2. 自定义应用程序信息
当env
contributor 启用后,您可以自定义info
endpoint 通过设置info.*
弹簧属性。
都Environment
属性下的info
键会自动公开。
例如,您可以将以下设置添加到application.properties
文件:
info.app.encoding=UTF-8
info.app.java.source=11
info.app.java.target=11
info:
app:
encoding: "UTF-8"
java:
source: "11"
target: "11"
除了对这些值进行硬编码,您还可以在构建时扩展信息属性。 假设您使用 Maven,您可以重写前面的示例,如下所示: 亚姆尔
|
2.10.3. Git 提交信息
另一个有用的功能info
endpoint 是它发布有关您的状态的信息的能力git
生成项目时的源代码存储库。
如果GitProperties
bean 可用,您可以使用info
endpoint 来公开这些属性。
一个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=full
management:
info:
git:
mode: "full"
要从info
endpoint 完全,请将management.info.git.enabled
属性设置为false
如下:
management.info.git.enabled=false
management:
info:
git:
enabled: false
2.10.4. 构建信息
如果BuildProperties
bean 可用,则info
endpoint 还可以发布有关您的构建的信息。
如果META-INF/build-info.properties
文件在类路径中可用。
Maven 和 Gradle 插件都可以生成该文件。 有关更多详细信息,请参阅“如何生成构建信息”。 |
2.10.5. Java 信息
这info
endpoint 发布有关 Java 运行时环境的信息,请参阅JavaInfo
了解更多详情。
2.10.6.作系统信息
这info
endpoint 发布有关您的作系统的信息,请参阅OsInfo
了解更多详情。
2.10.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"))
}
}
如果您达到info
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. 自定义管理端点路径
有时,自定义管理端点的前缀很有用。
例如,您的应用程序可能已经使用/actuator
为了另一个目的。
您可以使用management.endpoints.web.base-path
属性来更改管理终结点的前缀,如以下示例所示:
management.endpoints.web.base-path=/manage
management:
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=healthcheck
management:
endpoints:
web:
base-path: "/"
path-mapping:
health: "healthcheck"
3.2. 自定义管理服务器端口
使用默认 HTTP 端口公开管理终结点是基于云的部署的明智选择。 但是,如果您的应用程序在您自己的数据中心内运行,您可能更愿意使用不同的 HTTP 端口来公开端点。
您可以将management.server.port
属性来更改 HTTP 端口,如以下示例所示:
management.server.port=8081
management:
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=false
server:
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=secret
server:
port: 8443
ssl:
enabled: true
key-store: "classpath:main.jks"
key-password: "secret"
management:
server:
port: 8080
ssl:
enabled: true
key-store: "classpath:management.jks"
key-password: "secret"
4. 通过 JMX 进行监控和管理
Java 管理扩展 (JMX) 提供了一种标准机制来监视和管理应用程序。
默认情况下,此功能未启用。
您可以通过设置spring.jmx.enabled
配置属性设置为true
.
Spring Boot 暴露最合适的MBeanServer
作为 ID 为mbeanServer
.
任何使用 Spring JMX 注释(@ManagedResource
,@ManagedAttribute
或@ManagedOperation
)暴露于其中。
如果您的平台提供标准MBeanServer
,Spring Boot 使用它并默认为 VMMBeanServer
,如有必要。
如果所有这些都失败了,则新的MBeanServer
被创建。
请参阅JmxAutoConfiguration
class 了解更多详情。
默认情况下,Spring Boot 还将管理端点公开为 JMX MBeanorg.springframework.boot
域。
要完全控制 JMX 域中的端点注册,请考虑注册您自己的端点EndpointObjectNameFactory
实现。
4.1. 自定义MBean名称
MBean 的名称通常从id
的端点。
例如,health
endpoint 公开为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.myapp
spring:
jmx:
unique-names: true
management:
endpoints:
jmx:
domain: "com.example.myapp"
4.2. 禁用 JMX 端点
如果您不想通过 JMX 公开端点,您可以将management.endpoints.jmx.exposure.exclude
属性设置为 ,如以下示例所示:*
management.endpoints.jmx.exposure.exclude=*
management:
endpoints:
jmx:
exposure:
exclude: "*"
4.3. 将 Jolokia 用于 JMX over HTTP
Jolokia 是一个 JMX-HTTP 桥接器,它提供了访问 JMX bean 的替代方法。
要使用 Jolokia,请包含一个依赖项org.jolokia:jolokia-core
.
例如,使用 Maven,您将添加以下依赖项:
<dependency>
<groupId>org.jolokia</groupId>
<artifactId>jolokia-core</artifactId>
</dependency>
然后,您可以通过添加jolokia
或对*
management.endpoints.web.exposure.include
财产。
然后,您可以使用以下命令访问它/actuator/jolokia
在管理 HTTP 服务器上。
Jolokia 端点将 Jolokia 的 servlet 公开为执行器端点。 因此,它特定于 servlet 环境,例如 Spring MVC 和 Jersey。 该端点在 WebFlux 应用程序中不可用。 |
5. 记录仪
Spring Boot Actuator 包括在运行时查看和配置应用程序日志级别的功能。 您可以查看整个列表或单个记录器的配置,该配置由显式配置的日志记录级别以及日志记录框架给出的有效日志记录级别组成。 这些级别可以是以下级别之一:
-
TRACE
-
DEBUG
-
INFO
-
WARN
-
ERROR
-
FATAL
-
OFF
-
null
null
表示没有显式配置。
6. 计量指标
Spring Boot Actuator 为 Micrometer 提供依赖管理和自动配置,Micrometer 是一种支持众多监控系统的应用程序指标外观,包括:
6.1. 入门
Spring Boot 自动配置复合MeterRegistry
并为它在类路径上找到的每个受支持的实现向复合添加一个注册表。
依赖于micrometer-registry-{system}
足以让 Spring Boot 配置注册表。
大多数注册管理机构具有共同的功能。 例如,即使 Micrometer 注册表实现在类路径上,您也可以禁用特定的注册表。 以下示例禁用 Datadog:
management.metrics.export.datadog.enabled=false
management:
metrics:
export:
datadog:
enabled: false
您还可以禁用所有注册表,除非特定于注册表的属性另有说明,如以下示例所示:
management.metrics.export.defaults.enabled=false
management:
metrics:
export:
defaults:
enabled: false
Spring Boot 还会将任何自动配置的注册表添加到Metrics
类,除非你明确告诉它不要:
management.metrics.use-global-registry=false
management:
metrics:
use-global-registry: false
您可以注册任意数量的MeterRegistryCustomizer
bean 以进一步配置注册表,例如在向注册表注册任何仪表注册之前应用通用标签:
@Configuration(proxyBeanMethods = false)
public class MyMeterRegistryConfiguration {
@Bean
public MeterRegistryCustomizer<MeterRegistry> metricsCommonTags() {
return (registry) -> registry.config().commonTags("region", "us-east-1");
}
}
@Configuration(proxyBeanMethods = false)
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 还配置了内置检测,您可以通过配置或专用注释标记进行控制。
6.2. 支持的监控系统
本节简要介绍每个受支持的监控系统。
6.2.1. 应用光学
默认情况下,AppOptics 注册表会定期将指标推送到api.appoptics.com/v1/measurements
.
要将指标导出到 SaaS AppOptics,必须提供您的 API Tokens:
management.metrics.export.appoptics.api-token=YOUR_TOKEN
management:
metrics:
export:
appoptics:
api-token: "YOUR_TOKEN"
6.2.2. 阿特拉斯
management.metrics.export.atlas.uri=https://atlas.example.com:7101/api/v1/publish
management:
metrics:
export:
atlas:
uri: "https://atlas.example.com:7101/api/v1/publish"
6.2.3. 数据狗
management.metrics.export.datadog.api-key=YOUR_KEY
management:
metrics:
export:
datadog:
api-key: "YOUR_KEY"
如果另外提供应用程序密钥(可选),则还将导出计量说明、类型和基本单位等元数据:
management.metrics.export.datadog.api-key=YOUR_API_KEY
management.metrics.export.datadog.application-key=YOUR_APPLICATION_KEY
management:
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.eu
management:
metrics:
export:
datadog:
uri: "https://api.datadoghq.eu"
您还可以更改将指标发送到 Datadog 的时间间隔:
management.metrics.export.datadog.step=30s
management:
metrics:
export:
datadog:
step: "30s"
6.2.4. Dynatrace
Dynatrace 提供了两个指标摄取 API,这两个 API 都是为 Micrometer 实现的。
您可以在此处找到有关 Micrometer 指标摄取的 Dynatrace 文档。
配置属性中的v1
命名空间仅在导出到 Timeseries v1 API 时适用。
配置属性中的v2
命名空间仅在导出到 Metrics v2 API 时适用。
请注意,此集成只能导出到v1
或v2
API 版本,使用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 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.metrics.export.dynatrace.uri=https://example.live.dynatrace.com/api/v2/metrics/ingest
management.metrics.export.dynatrace.api-token=YOUR_TOKEN
management:
metrics:
export:
dynatrace:
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 时遇到问题时才应使用它。
可以不指定 URI 和 API Tokens,如以下示例所示。在此方案中,使用自动配置的终结点:
management.metrics.export.dynatrace.v2.metric-key-prefix=your.key.prefix
management.metrics.export.dynatrace.v2.enrich-with-dynatrace-metadata=true
management.metrics.export.dynatrace.v2.default-dimensions.key1=value1
management.metrics.export.dynatrace.v2.default-dimensions.key2=value2
management.metrics.export.dynatrace.v2.use-dynatrace-summary-instruments=true
management:
metrics:
export:
dynatrace:
# Specify uri and api-token here if not using the local OneAgent endpoint.
v2:
metric-key-prefix: "your.key.prefix"
enrich-with-dynatrace-metadata: true
default-dimensions:
key1: "value1"
key2: "value2"
use-dynatrace-summary-instruments: true # (default: true)
v1 API(旧版)
Dynatrace v1 API 指标注册表使用 Timeseries v1 API 定期将指标推送到配置的 URI。为了向后兼容现有设置,当device-id
设置为(v1 需要,但在 v2 中不使用),则指标将导出到 Timeseries v1 端点。要将指标导出到 Dynatrace,必须提供您的 API Tokens、设备 ID 和 URI:
management.metrics.export.dynatrace.uri=https://{your-environment-id}.live.dynatrace.com
management.metrics.export.dynatrace.api-token=YOUR_TOKEN
management.metrics.export.dynatrace.v1.device-id=YOUR_DEVICE_ID
management:
metrics:
export:
dynatrace:
uri: "https://{your-environment-id}.live.dynatrace.com"
api-token: "YOUR_TOKEN"
v1:
device-id: "YOUR_DEVICE_ID"
对于 v1 API,必须指定不带路径的基本环境 URI,因为 v1 终结点路径是自动添加的。
与版本无关的设置
除了 API 端点和Tokens之外,您还可以更改将指标发送到 Dynatrace 的时间间隔。默认导出时间间隔为60s
. 以下示例将导出间隔设置为 30 秒:
management.metrics.export.dynatrace.step=30s
management:
metrics:
export:
dynatrace:
step: "30s"
您可以在 Micrometer 文档和 Dynatrace 文档中找到有关如何为 Micrometer 设置 Dynatrace 导出器的更多信息。
6.2.5. 弹性
默认情况下,指标将导出到本地计算机上运行的 Elastic。 您可以使用以下属性提供要使用的弹性服务器的位置:
management.metrics.export.elastic.host=https://elastic.example.com:8086
management:
metrics:
export:
elastic:
host: "https://elastic.example.com:8086"
6.2.6. 神经节
默认情况下,指标将导出到本地计算机上运行的 Ganglia。 您可以提供 Ganglia 服务器主机和端口,如以下示例所示:
management.metrics.export.ganglia.host=ganglia.example.com
management.metrics.export.ganglia.port=9649
management:
metrics:
export:
ganglia:
host: "ganglia.example.com"
port: 9649
6.2.7. 石墨
默认情况下,指标将导出到本地计算机上运行的 Graphite。 您可以提供 Graphite 服务器主机和端口,如以下示例所示:
management.metrics.export.graphite.host=graphite.example.com
management.metrics.export.graphite.port=9004
management:
metrics:
export:
graphite:
host: "graphite.example.com"
port: 9004
Micrometer 提供默认的HierarchicalNameMapper
控制如何将维度计 ID 映射到平面分层名称。
要控制此行为,请定义您的 Java
Kotlin
|
6.2.8. 休米奥
默认情况下,Humio 注册表会定期将指标推送到 cloud.humio.com。 要将指标导出到 SaaS Humio,您必须提供 API Tokens:
management.metrics.export.humio.api-token=YOUR_TOKEN
management:
metrics:
export:
humio:
api-token: "YOUR_TOKEN"
还应配置一个或多个标记,以标识将指标推送到的数据源:
management.metrics.export.humio.tags.alpha=a
management.metrics.export.humio.tags.bravo=b
management:
metrics:
export:
humio:
tags:
alpha: "a"
bravo: "b"
6.2.9. 涌入
默认情况下,指标将导出到具有默认配置的本地计算机上运行的 Influx v1 实例。
要将指标导出到 InfluxDB v2,请配置org
,bucket
和身份验证token
用于编写指标。
您可以使用以下方法提供要使用的 Influx 服务器的位置:
management.metrics.export.influx.uri=https://influx.example.com:8086
management:
metrics:
export:
influx:
uri: "https://influx.example.com:8086"
6.2.10. JMX
Micrometer 提供了与 JMX 的分层映射,主要作为一种廉价且可移植的方式在本地查看指标。
默认情况下,指标将导出到metrics
JMX 域。
您可以使用以下方法提供要使用的域:
management.metrics.export.jmx.domain=com.example.app.metrics
management:
metrics:
export:
jmx:
domain: "com.example.app.metrics"
Micrometer 提供默认的HierarchicalNameMapper
控制如何将维度计 ID 映射到平面分层名称。
要控制此行为,请定义您的 Java
Kotlin
|
6.2.11. 凯罗斯数据库
默认情况下,指标将导出到本地计算机上运行的 KairosDB。您可以使用以下方法提供要使用的 KairosDB 服务器的位置:
management.metrics.export.kairos.uri=https://kairosdb.example.com:8080/api/v1/datapoints
management:
metrics:
export:
kairos:
uri: "https://kairosdb.example.com:8080/api/v1/datapoints"
6.2.12. 新遗迹
management.metrics.export.newrelic.api-key=YOUR_KEY
management.metrics.export.newrelic.account-id=YOUR_ACCOUNT_ID
management:
metrics:
export:
newrelic:
api-key: "YOUR_KEY"
account-id: "YOUR_ACCOUNT_ID"
您还可以更改将指标发送到 New Relic 的时间间隔:
management.metrics.export.newrelic.step=30s
management:
metrics:
export:
newrelic:
step: "30s"
默认情况下,指标通过 REST 调用发布,但如果 Java Agent API 位于类路径上,也可以使用它:
management.metrics.export.newrelic.client-provider-type=insights-agent
management:
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。要启用此功能,请SpanContextSupplier
bean 应该出现。如果您使用 Spring Cloud Sleuth,这将为您自动配置,但如果您愿意,您可以随时创建自己的。
请查看 Prometheus 文档,因为此功能需要在 Prometheus 端显式启用,并且仅支持 OpenMetrics 格式。
对于可能存在时间不够长而无法抓取的临时或批处理作业,您可以使用 Prometheus Pushgateway 支持将指标公开给 Prometheus。要启用 Prometheus Pushgateway 支持,请向项目添加以下依赖项:
<dependency>
<groupId>io.prometheus</groupId>
<artifactId>simpleclient_pushgateway</artifactId>
</dependency>
当 Prometheus Pushgateway 依赖项存在于类路径上并且management.metrics.export.prometheus.pushgateway.enabled
属性设置为true
一个PrometheusPushGatewayManager
bean 是自动配置的。这管理将指标推送到 Prometheus Pushgateway。
您可以调整PrometheusPushGatewayManager
通过使用management.metrics.export.prometheus.pushgateway
. 对于高级配置,您还可以提供自己的配置PrometheusPushGatewayManager
豆。
6.2.14. 信号FX
management.metrics.export.signalfx.access-token=YOUR_ACCESS_TOKEN
management:
metrics:
export:
signalfx:
access-token: "YOUR_ACCESS_TOKEN"
您还可以更改将指标发送到 SignalFx 的时间间隔:
management.metrics.export.signalfx.step=30s
management:
metrics:
export:
signalfx:
step: "30s"
6.2.15. 简单
Micrometer 附带了一个简单的内存中后端,如果没有配置其他注册表,则会自动将其用作回退。 这样,您就可以查看指标端点中收集了哪些指标。
一旦您使用任何其他可用后端,内存中后端就会自行禁用。 您也可以显式禁用它:
management.metrics.export.simple.enabled=false
management:
metrics:
export:
simple:
enabled: false
6.2.16. 堆栈驱动程序
Stackdriver 注册表会定期将指标推送到 Stackdriver。 要将指标导出到 SaaS Stackdriver,您必须提供您的 Google Cloud 项目 ID:
management.metrics.export.stackdriver.project-id=my-project
management:
metrics:
export:
stackdriver:
project-id: "my-project"
您还可以更改将指标发送到 Stackdriver 的时间间隔:
management.metrics.export.stackdriver.step=30s
management:
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=udp
management:
metrics:
export:
statsd:
host: "statsd.example.com"
port: 9125
protocol: "udp"
您还可以更改要使用的 StatsD 线协议(默认为 Datadog):
management.metrics.export.statsd.flavor=etsy
management:
metrics:
export:
statsd:
flavor: "etsy"
6.2.18. 波前
management.metrics.export.wavefront.api-token=YOUR_API_TOKEN
management:
metrics:
export:
wavefront:
api-token: "YOUR_API_TOKEN"
或者,您可以使用环境中的 Wavefront Sidecar 或内部代理将指标数据转发到 Wavefront API 主机:
management.metrics.export.wavefront.uri=proxy://localhost:2878
management:
metrics:
export:
wavefront:
uri: "proxy://localhost:2878"
如果您将指标发布到 Wavefront 代理(如 Wavefront 文档中所述),则主机必须位于proxy://HOST:PORT 格式。 |
您还可以更改将指标发送到 Wavefront 的时间间隔:
management.metrics.export.wavefront.step=30s
management:
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
注释支持@Controller
classes 和@RequestMapping
方法(有关详细信息,请参阅@Timed注释支持)。
如果您不想记录所有 Spring MVC 请求的指标,您可以将management.metrics.web.server.request.autotime.enabled
自false
并专门使用@Timed
注释。
默认情况下,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
注释支持@Controller
classes 和@RequestMapping
方法(有关详细信息,请参阅@Timed注释支持)。
如果您不想记录所有 Spring WebFlux 请求的指标,您可以将management.metrics.web.server.request.autotime.enabled
自false
并专门使用@Timed
注释。
默认情况下,WebFlux 相关指标使用以下信息进行标记:
标记 | 描述 |
---|---|
|
处理请求时引发的任何异常的简单类名。 |
|
请求的方法(例如 |
|
请求的结果,基于响应的状态代码。
1xx 是 |
|
响应的 HTTP 状态代码(例如 |
|
如果可能,请求的 URI 模板在变量替换之前(例如, |
要添加到默认标签中,请提供一个或多个实现WebFluxTagsContributor
.
要替换默认标签,请提供一个实现WebFluxTagsProvider
.
在某些情况下,控制器和处理程序函数中处理的异常不会记录为请求指标标记。 应用程序可以通过将已处理的异常设置为请求属性来选择加入并记录异常。 |
6.3.8. Jersey服务器指标
自动配置支持检测 Jersey JAX-RS 实现处理的所有请求。
默认情况下,生成指标的名称为http.server.requests
.
您可以通过设置management.metrics.web.server.request.metric-name
财产。
@Timed
请求处理类和方法支持注释(有关详细信息,请参阅@Timed注释支持)。
如果您不想记录所有Jersey请求的指标,您可以将management.metrics.web.server.request.autotime.enabled
自false
并专门使用@Timed
注释。
默认情况下,Jersey服务器指标使用以下信息进行标记:
标记 | 描述 |
---|---|
|
处理请求时引发的任何异常的简单类名。 |
|
请求的方法(例如 |
|
请求的结果,基于响应的状态代码。
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
-
咖啡因
-
埃缓存 2
-
榛铸
-
任何符合 JCache (JSR-107) 的实现
-
Redis
指标由缓存的名称和CacheManager
,源自 bean 名称。
只有在启动时配置的缓存才会绑定到注册表。
对于缓存配置中未定义的缓存,例如动态创建的缓存或在启动阶段后以编程方式创建的缓存,需要显式注册。
一个CacheMetricsRegistrar bean 的提供使该过程更容易。 |
6.3.12. Spring GraphQL 指标
自动配置支持检测 GraphQL 查询,适用于任何受支持的传输。
Spring Boot 记录了一个graphql.request
定时器:
标记 | 描述 | 示例值 |
---|---|---|
结果 |
请求结果 |
“成功”、“错误” |
单个 GraphQL 查询可能涉及多个DataFetcher
调用,所以有一个专用的graphql.datafetcher
定时器:
标记 | 描述 | 示例值 |
---|---|---|
路径 |
数据获取器路径 |
“查询项目” |
结果 |
数据获取结果 |
“成功”、“错误” |
这graphql.request.datafetch.count
分布汇总计算非平凡的数量DataFetcher
按请求进行的呼叫。
此指标可用于检测“N+1”数据获取问题并考虑批量加载;它提供了"TOTAL"
通过"COUNT"
记录的请求,以及"MAX"
在所考虑的时间段内对单个请求发出的呼叫。
更多选项可用于使用应用程序属性配置发行版。
单个响应可以包含许多 GraphQL 错误,由graphql.error
计数器:
标记 | 描述 | 示例值 |
---|---|---|
errorType |
错误类型 |
“DataFetchingException” |
错误路径 |
错误 JSON 路径 |
“$.项目” |
6.3.13. 数据源指标
自动配置支持所有可用仪器DataSource
指标前缀为jdbc.connections
.
数据源检测生成仪表,这些仪表表示池中当前活动、空闲、允许的最大连接数和允许的最小连接数。
指标还由DataSource
根据 Bean 名称计算。
默认情况下,Spring Boot 为所有受支持的数据源提供元数据。
您可以添加其他DataSourcePoolMetadataProvider bean,如果不支持您最喜欢的数据源。
看DataSourcePoolMetadataProvidersConfiguration 例如。 |
此外,特定于 Hikari 的指标会通过hikaricp
前缀。
每个指标都由池的名称标记(您可以使用spring.datasource.name
).
6.3.14. 休眠指标
如果org.hibernate:hibernate-micrometer
在类路径上,所有可用的休眠EntityManagerFactory
启用了统计信息的实例使用名为hibernate
.
指标还由EntityManagerFactory
,源自 bean 名称。
要启用统计信息,请标准 JPA 属性hibernate.generate_statistics
必须设置为true
.
您可以在自动配置的EntityManagerFactory
:
spring.jpa.properties[hibernate.generate_statistics]=true
spring:
jpa:
properties:
"[hibernate.generate_statistics]": true
6.3.15. Spring Data Repository 指标
自动配置支持所有 Spring Data 的检测Repository
方法调用。
默认情况下,生成指标的名称为spring.data.repository.invocations
.
您可以通过设置management.metrics.data.repository.metric-name
财产。
@Timed
注释支持Repository
类和方法(有关详细信息,请参阅@Timed Annotation 支持)。
如果您不想记录所有指标Repository
调用,您可以将management.metrics.data.repository.autotime.enabled
自false
并专门使用@Timed
注释。
默认情况下,与存储库调用相关的指标使用以下信息进行标记:
标记 | 描述 |
---|---|
|
源的简单类名 |
|
的名称 |
|
结果状态 ( |
|
从调用引发的任何异常的简单类名。 |
要替换默认标记,请提供一个@Bean
实现RepositoryTagsProvider
.
6.3.17. Spring 集成指标
Spring Integration 每当MeterRegistry
豆子可用。
指标发布在spring.integration.
仪表名称。
6.3.18. Kafka 指标
自动配置注册一个MicrometerConsumerListener
和MicrometerProducerListener
分别用于自动配置的使用者工厂和生产者工厂。
它还注册了一个KafkaStreamsMicrometerListener
为StreamsBuilderFactoryBean
.
有关更多详细信息,请参阅 Spring Kafka 文档的 Micrometer Native Metrics 部分。
6.3.19. MongoDB 指标
本节简要介绍 MongoDB 的可用指标。
MongoDB 命令指标
自动配置注册一个MongoMetricsCommandListener
使用自动配置的MongoClient
.
名为mongodb.driver.commands
为向底层 MongoDB 驱动程序发出的每个命令创建。
默认情况下,每个指标都使用以下信息进行标记:
标记 | 描述 |
---|---|
|
发出的命令的名称。 |
|
命令发送到的集群的标识符。 |
|
命令发送到的服务器的地址。 |
|
命令 ( |
要替换默认指标标记,请定义一个MongoCommandTagsProvider
bean,如以下示例所示:
@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=false
management:
metrics:
mongo:
command:
enabled: false
MongoDB 连接池指标
自动配置注册一个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=false
management:
metrics:
mongo:
connectionpool:
enabled: false
6.3.20. Jetty 指标
自动配置绑定 Jetty 的指标ThreadPool
通过使用 Micrometer 的JettyServerThreadPoolMetrics
.
Jetty 的指标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 ...
}
}
如果只想检测单个映射,则可以在方法上使用注释而不是类:
@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 ...
}
}
如果要更改特定方法的计时详细信息,还可以组合类级和方法级注解:
@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 ...
}
}
一个@Timed 注释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
如果您发现跨组件或应用程序重复检测一套指标,则实施也很有用。
默认情况下,来自所有MeterBinder bean 会自动绑定到 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")
}
}
默认情况下,所有MeterFilter bean 会自动绑定到 Spring 管理的MeterRegistry .
确保使用 Spring 托管的MeterRegistry 而不是任何静态方法Metrics .
这些使用非 Spring 管理的全局注册表。 |
6.5.1. 常用标签
通用标签一般用于对运行环境进行维度下钻,如主机、实例、地域、堆栈等。 共享资源标签应用于所有仪表,并且可以进行配置,如以下示例所示:
management.metrics.tags.region=us-east-1
management.metrics.tags.stack=prod
management:
metrics:
tags:
region: "us-east-1"
stack: "prod"
前面的示例将region
和stack
标记添加到所有值为us-east-1
和prod
分别。
如果您使用 Graphite,则常见标签的顺序很重要。
由于使用这种方法无法保证常见标签的顺序,因此建议 Graphite 用户定义一个自定义MeterFilter 相反。 |
6.5.2. 每米属性
除了MeterFilter
bean,您可以使用属性按米应用一组有限的自定义。
使用 Spring Boot 的PropertiesMeterFilter
,转换为以给定名称开头的任何仪表 ID。
以下示例筛选出 ID 开头为example.remote
.
management.metrics.enable.example.remote=false
management:
metrics:
enable:
example:
remote: false
以下属性允许按计量自定义:
属性 | 描述 |
---|---|
|
是否接受具有特定 ID 的仪表。
不接受的仪表将从 |
|
是否发布适合计算可聚合(跨维度)百分位近似的直方图。 |
|
通过限制预期值的范围来发布更少的直方图桶。 |
|
发布在应用程序中计算的百分位值 |
|
通过将最近的 Samples累积在环形缓冲区中来赋予它们更大的权重,这些缓冲区在可配置的到期后旋转,并使用 可配置的缓冲区长度。 |
|
发布累积直方图,其中包含由服务级别目标定义的存储桶。 |
有关背后概念的更多详细信息percentiles-histogram
,percentiles
和slo
,请参阅千分尺文档的“直方图和百分位数”部分。
6.6. 指标端点
Spring Boot 提供了一个metrics
端点,您可以诊断地使用它来检查应用程序收集的指标。
默认情况下,终结点不可用,必须公开。有关更多详细信息,请参阅公开终结点。
导航到/actuator/metrics
显示可用仪表名称的列表。
您可以通过提供特定仪表的名称作为选择器来向下钻取以查看有关其信息,例如/actuator/metrics/jvm.memory.max
.
您在此处使用的名称应与代码中使用的名称匹配,而不是为它交付到的监视系统进行命名约定规范化后的名称。
换句话说,如果 |
您还可以添加任意数量的tag=KEY:VALUE
查询参数到URL末尾,以对仪表进行维度向下钻取,例如,/actuator/metrics/jvm.memory.max?tag=area:nonheap
.
报告的测量值是与仪表名称匹配的所有仪表的统计数据和已应用的任何标记的统计数据的总和。
在前面的示例中,返回的 |
7. 审计
一旦 Spring Security 开始发挥作用,Spring Boot Actuator 就有一个灵活的审计框架,可以发布事件(默认情况下,“身份验证成功”、“失败”和“访问被拒绝”异常)。 此功能对于报告和实施基于身份验证失败的锁定策略非常有用。
您可以通过提供类型为AuditEventRepository
在应用程序的配置中。
为方便起见,Spring Boot 提供了一个InMemoryAuditEventRepository
.InMemoryAuditEventRepository
功能有限,建议仅将其用于开发环境。
对于生产环境,请考虑创建自己的替代项AuditEventRepository
实现。
8. HTTP 跟踪
您可以通过提供类型HttpTraceRepository
在应用程序的配置中。
为方便起见,Spring Boot 提供InMemoryHttpTraceRepository
,它存储最近 100 次(默认)请求-响应交换的跟踪。InMemoryHttpTraceRepository
与其他跟踪解决方案相比,是有限的,我们建议仅将其用于开发环境。
对于生产环境,我们建议使用生产就绪的跟踪或可观测性解决方案,例如 Zipkin 或 Spring Cloud Sleuth。
或者,您可以创建自己的HttpTraceRepository
.
您可以使用httptrace
endpoint 以获取有关存储在HttpTraceRepository
.
9. 过程监控
在spring-boot
模块中,您可以找到两个类来创建通常对进程监控有用的文件:
-
ApplicationPidFileWriter
创建一个包含应用程序 PID 的文件(默认情况下,在文件名为application.pid
). -
WebServerPortFileWriter
创建一个(或多个文件),其中包含正在运行的 Web 服务器的端口(默认情况下,在文件名为application.port
).
默认情况下,这些写入器不会激活,但您可以启用它们:
10. Cloud Foundry 支持
Spring Boot 的执行器模块包括额外的支持,当您部署到兼容的 Cloud Foundry 实例时,这些支持会激活。
这/cloudfoundryapplication
path 为所有@Endpoint
豆。
扩展支持允许使用 Spring Boot 执行器信息增强 Cloud Foundry 管理 UI(例如可用于查看已部署应用程序的 Web 应用程序)。 例如,应用程序状态页可以包含完整的运行状况信息,而不是典型的“正在运行”或“已停止”状态。
这/cloudfoundryapplication 普通用户无法直接访问路径。
若要使用终结点,必须在请求中传递有效的 UAA Tokens。 |
10.1. 禁用扩展的 Cloud Foundry 执行器支持
如果您想完全禁用/cloudfoundryapplication
endpoints,您可以将以下设置添加到application.properties
文件:
management.cloudfoundry.enabled=false
management:
cloudfoundry:
enabled: false
10.2. Cloud Foundry 自签名证书
默认情况下,安全验证/cloudfoundryapplication
endpoints 对各种 Cloud Foundry 服务进行 SSL 调用。
如果您的 Cloud Foundry UAA 或 Cloud Controller 服务使用自签名证书,则需要设置以下属性:
management.cloudfoundry.skip-ssl-validation=true
management:
cloudfoundry:
skip-ssl-validation: true
10.3. 自定义上下文路径
如果服务器的上下文路径已配置为 以外的任何内容,那么 Cloud Foundry 端点在应用程序的根目录中不可用。
例如,如果/
server.servlet.context-path=/app
,Cloud Foundry 端点可在以下位置获得/app/cloudfoundryapplication/*
.
如果您希望 Cloud Foundry 端点始终在/cloudfoundryapplication/*
,无论服务器的上下文路径如何,您都需要在应用程序中显式配置它。
配置因使用的 Web 服务器而异。
对于 Tomcat,您可以添加以下配置:
@Configuration(proxyBeanMethods = false)
public class MyCloudFoundryConfiguration {
@Bean
public TomcatServletWebServerFactory servletWebServerFactory() {
return new TomcatServletWebServerFactory() {
@Override
protected void prepareContext(Host host, ServletContextInitializer[] initializers) {
super.prepareContext(host, initializers);
StandardContext child = new StandardContext();
child.addLifecycleListener(new Tomcat.FixContextListener());
child.setPath("/cloudfoundryapplication");
ServletContainerInitializer initializer = getServletContextInitializer(getContextPath());
child.addServletContainerInitializer(initializer, Collections.emptySet());
child.setCrossContext(true);
host.addChild(child);
}
};
}
private ServletContainerInitializer getServletContextInitializer(String contextPath) {
return (classes, context) -> {
Servlet servlet = new GenericServlet() {
@Override
public void service(ServletRequest req, ServletResponse res) throws ServletException, IOException {
ServletContext context = req.getServletContext().getContext(contextPath);
context.getRequestDispatcher("/cloudfoundryapplication").forward(req, res);
}
};
context.addServlet("cloudfoundry", servlet).addMapping("/*");
};
}
}
@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("/*")
}
}
}