目录

前言

Micrometer是什么？

开箱即用

Micrometer支持什么监控系统？

metrics和tracing的区别

维度的重要性

Meter filters

为什么/actuator/metrics端点在Spring Boot 2中发生了变化


前言

今天在学习micometer相关的内容，看到一篇博文，突然想到，可以尝试翻译一下博客。


Micrometer是什么？

Micrometer是一个“维度优先”的指标收集门面，目的是让你能用与提供方无关的API来计时/统计/测量代码。通过类路径和配置，你可以选择一个或者多个监控系统来导出你的统计数据。

类似于SLF4J，但是用于指标的！

 

Micrometer是Spring Boot2.x Actuator包含的指标收集工具。Micrometer添加了比Spring Boot1.x里已包含的更丰富的测量基元来统计和计量。

 

Micrometer添加了比Spring Boot 1中更丰富的Meter（注2）。例如，单个Micrometer Timer Meter能够生成与吞吐量、总时间、最近采样的最大等待时间，

预计算的百分位数，百分位数直方图，SLA边界计数。

java springboot中pulsar的topic 分区数量 springboot collector_springboot

 

尽管Micrometer专注于维度指标，但是它仍然会继续服务于Ganglia等较旧的监控方案或者小众的工具比如JMX。Micrometer改变的目的是更好地服务于多维度的监控系统（比如 Prometheus, Datadog, Wavefront, SignalFx, Influx等）。Spring的有个强项就是通过抽象提供多选择实现。通过与Micromer集成，现在Spring Boot可以让您选择一个或者多个监控系统，并且在以后能不用重写自定义指标实现的情况下做出改变。

 

在研发“又一个”指标收集库之前，我们仔细研究了现有或者即将出现的维度收集器。但是，当我们考虑将其导出到更多的监控系统时，名称结构和数据结构重要性变得越来越明显。Micrometer内置了命名约定规范化、时间缩放的基本单位以及对结构专有表达式（如直方图数据）的支持的概念，这些对于使指标在每个目标系统中发挥作用至关重要。在此过程中，我们还添加了Meter过滤功能，使您可以更好地控制上游依赖项的检测。

 

提示：要了解有关Micrometer功能的更多信息，请参阅其参考文档，特别是概念部分。

开箱即用

spring Boot 2自动配置了很多指标。包括：

  • JVM, report utilization of:
  • Various memory and buffer pools
  • Statistics related to garbage collection
  • Thread utilization
  • Number of classes loaded/unloaded
  • CPU usage
  • Spring MVC and WebFlux request latencies
  • RestTemplate latencies
  • Cache utilization
  • Datasource utilization, including HikariCP pool metrics
  • RabbitMQ connection factories
  • File descriptor usage
  • Logback: record the number of events logged to Logback at each level
  • Uptime: report a gauge for uptime and a fixed gauge representing the application’s absolute start time
  • Tomcat usage

上面很多指标在Spring Boot 1中已经存在，但在Spring Boot 2中已包含更多详细信息和标签。

Micrometer支持什么监控系统？

Micrometer提供了一个与提供方无关的指标收集API（父类是：io.micrometer.core.instrument.MeterRegistry）并且能适用于很多监控系统：

  • Netflix Atlas
  • CloudWatch
  • Datadog
  • Ganglia
  • Graphite
  • InfluxDB
  • JMX
  • New Relic
  • Prometheus
  • SignalFx
  • StatsD (Etsy, dogstatsd, Telegraf, and proprietary formats)
  • Wavefront

对下面附加系统的支持计划放在2018年年中的1.1.0正式发布版。

  • AppOptics
  • Azure Application Insights
  • Dynatrace
  • Elasticsearch
  • StackDriver

Spring Boot2配置了一个组合的MeterRegistry，可以在其中添加任何数量的的注册器实现。从而使您能把指标数据传输给多个不同 监控系统。通过MeterRegistryCustomizer，你可以自定义整个注册表，也可以自定义个别的实现。

 

metrics和tracing的区别

metrics明确指的的是一类信息，它能推测一个聚合系统的性能（包括单个应用的不同组件，集群的实例，不同的集群等）。

这个不包括通过推测不同组件在一系列服务请求时对总延迟的提供的信息；但是这个却是Spring Cloud Sleuth, Zipkin's Brave等分布式跟踪收集器的责任。

 

分布式链路系统提供有关子系统延迟的详细信息，通常会降低采样率以进行扩展（例如Spring Cloud Sleuth默认提供10％的采样率）。指标数据通常是预汇总的，因此自然会缺乏相关信息，但是它并没有降低采样率。

因此，对于一分钟内的100000个请求，这些请求和A服务有功能交互，且可能和B服务有输入的交互，会有以下结果：

  1. （Metrics）指标数据会告诉你，总的来说服务A的观察吞吐量是10万个请求，服务B的观察吞吐量是6万个请求。此外，在那一分钟内，服务A的最大总体平均延迟为100毫秒，服务B的最大总体平均延迟为50毫秒。它还将提供有关该期间内最大延迟和其他分布统计信息。
  2. （Tracing）分布式跟踪系统将告诉您，对于一个特定的请求（但不是整个请求总数，记住因为有采样降低），服务A花费了50毫秒，服务B花费了90毫秒。

 

您可以从指标数据中合理地推断出，在最坏情况下的用户体验中花费的时间大约有一半是花在A和B上的，但是从汇总数据上看，你不能完全确定。因为在最坏的情况下，所有100毫秒都用在了服务A中，而服务B根本没有被调用。

 

相反，从跟踪数据中，您无法推断出一定时间间隔内的吞吐量或最坏情况的用户体验。

维度的重要性

Spring Boot 1.x的指标接口本质上是分层的。这意味着发布的指标完全由其名称标识。因此，您可能有个 jvm.memory.used的指标。

当你是查看单个应用实例的指标的时候，这个可能适用。但是当你有十个实例发布了 jvm.memory.used指标在同一个监控系统呢？

当某一个实例的内存消耗增加，我们怎么区分呢？

答案通常是增加一个前缀或者后缀到名字里。所以，我们可能会把指标名字换成${HOST}.jvm.memory.used，用主机名替代${HOST}。重新部署十个实例后，我们知道哪个实例有内存压力。

假设现在在3个部署区域中的每个区域中都有10个应用程序实例。 此外，我们要按区域推断应用程序的平均或最大内存占用量。 现在，如果我们向度量标准名称添加一个附加前缀

（以使其看起来像$ {REGION}.$ {HOST} .jvm.memory.used)。

 

我们已经提到过Micometer是维度优先的指标收集器。 Micrometer中使用多个标签（又称规模）可以记录同一个指标。

Gauge.builder("jvm.memory.used", ..)
.tag("host", "MYHOST")
.tag("region", "us-east-1")
.register(registry);

 

如果您没有深入其中一个或者多个标签，维度监控系统会显示jvm.memory.used 的聚合。 维度监控系统中的查询将首先选择名称（jvm.memory.used），并允许随后按标签进行过滤。在上面的场景中，如果我们已有一个基于主机的内存消耗过高的图表/警报，然后又给某个区域添加了一个标签，则基于主机的查询将继续不间断地工作，因为新的区域的指标数据会自动在系统中输出。

Meter filters

Meter过滤器使您可以控制Meter的注册方式和时间以及发出的统计信息类型。 Meter过滤器具有三个基本功能：

  • 拒绝或者允许Meter注册
  • 转换MeterID（例如更改名字，添加或者删除tag，更改描述或基本单位）
  • 配置某些Meter类型的分布统计信息（例如百分位数，直方图，计时器的SLA？和分布汇总）

Spring Boot 2将很多属性绑定到一个开箱即用的Meter过滤器，你可以通过修改properties来控制指标输出。例如：

management.metrics.enable.jvm=false
management.metrics.distribution.percentiles-histogram.http.server.requests=true
management.metrics.distribution.sla.http.server.requests=1ms,5ms

上面的代码关闭了所有以前缀“ jvm”开头的指标，发布了Spring Boot自动配置的http服务器请求指标的百分比直方图，并发送了小于或等于1ms和5ms SLA边界的请求计数，因此您可以确切地了解 许多要求都符合您的期望。 SLA分发配置也是核心功能，使您可以可视化更复杂的度量，例如Apdex分数。

 

您可以从根本上完全关闭指标的启用，以针对所需的少数指标生成白名单。 假设您只需要JVM指标，而没有其他要求：

management.metrics.enable.root=false
management.metrics.enable.jvm=true

 

为什么/actuator/metrics端点在Spring Boot 2中发生了变化

Spring Boot1中提供一个单个REST断点列出所有指标的方式是不好的，因为里面只有分层的计数器和计量表。像计时器这种复杂类型的会表现出多个时间系数（至少包含一个计数，一个最大值和一个总和）。另外，我们的指标具有了维度。 很快就会清楚发现没有办法在单个有效载荷中输出所有这些信息。 甚至对于维数计数器，我们是否也显示标签的每个排列的汇总？为了简洁起见，扁平化为层次结构名称，结果变成这样：

http.server.requests.method.GET.response.200.uri./foo=100
http.server.requests.method.GET.response.500.uri./foo=1
http.server.requests.method.GET.response.200.uri./bar=5
http.server.requests.method.GET.response.400.uri./foo=1
 
# and now the aggregates...
http.server.requests.method.GET=107
http.server.requests.method.GET.response.200=105
http.server.requests.method.GET.uri./foo=101
http.server.requests.response.200.uri./foo=100
http.server.requests.response.500.uri./foo=1
http.server.requests.response.200.uri./bar=5
...

如您所见，这样肯定行不通。 例如，如果您要在MeterRegistry的内容上构建自定义UI，并且您知道UI仅对URI的http吞吐量感兴趣，而与方法，状态等无关，则可以大幅减少输出。 对于此类情况，我们建议创建一个组件，该组件仅向UI显示所需的数据。 将MeterRegistry注入您的组件，并使用其find和get方法来搜索您需要公开的指标。 然后以适合您使用的格式序列化它们。

 

参考

可以通过slack.micrometer.io，Twitter @micrometerio和Github来获得对Micrometer的支持。 不要犹豫，提出问题，建议或问题！

 

译者注

1,metrics统一翻译成指标，实际上也有度量的意思

2,Meter是指一组用于收集应用中的度量数据的接口，Meter单词可以翻译为”米”或者”千分尺”，但是显然听起来都不是很合理，因此下文直接叫Meter，理解它为度量接口即可。