Dubbo 的度量统计基础设施 - Dubbo Metrics 发布新版本

| Photo by Markus Spiske on Unsplash

对服务进行实时监控，了解服务当前的运行指标和健康状态，是微服务体系中不可或缺的环节。Metrics 作为微服务的重要组件，为服务的监控提供了全面的数据基础。近日，Dubbo Metrics 发布了2.0.1版本，本文将为您探秘 Dubbo Metrics 的起源，及 7 大改进。

Dubbo Metrics 的起源

---

Dubbo Metrics（原Alibaba Metrics）是阿里巴巴集团内部广泛使用的度量埋点基础类库，有 Java 和 Node.js 两个版本，目前开源的是 Java 版本。内部版本诞生于2016年，经历过近三年的发展和双十一的考验，已经成为阿里巴巴集团内部微服务监控度量的事实标准，覆盖了从系统、JVM、中间件到应用各层的度量，并且在命名规则、数据格式、埋点方式和计算规则等方面，形成了一套统一的规范。

Dubbo Metrics 的代码是基于 Dropwizard Metrics 衍生而来，版本号是3.1.0，当时决定 fork 到内部进行定制化开发的主要原因有两个。

一是社区的发展非常缓慢，3.1.0之后的第3年才更新了下一个版本，我们担心社区无法及时响应业务需求；另一个更重要的原因是当时的3.1.0还不支持多维度的 Tag，只能基于 a.b.c 这样传统的指标命名方法，这就意味着 Dropwizard Metrics 只能在单维度进行度量。然后，在实际的业务过程中，很多维度并不能事先确定，而且在大规模分布式系统下，数据统计好以后，需要按照各种业务维度进行聚合，例如按机房、分组进行聚合，当时的 Dropwizard 也无法满足，种种原因使得我们做了一个决定，内部fork一个分支进行发展。

Dubbo Metrics 做了哪些改进

---

相对于 Dropwizard Metrics ，Dubbo Metrics 做的改进主要有以下几个方面：

一、引入基于 Tag 的命名规范

如前文所描述，多维度 Tag 在动态埋点，数据聚合等方面相对于传统的 metric 命名方法具有天然的优势，这里举一个例子，要统计一个 Dubbo 服务 DemoService 调用次数和 RT，假设这个服务叫做 DemoService，那么按照传统的命名方式，通常会命名为dubbo.provider.DemoService.qps和dubbo.provider.DemoService.rt。如果只有1个服务的话，这种方法并无太大的问题，但是如果一个微服务应用同时提供了多个 Dubbo 的 Service，那么要聚合统计所有Service 的 QPS 和 RT 就比较困难了。由于 metric 数据具有天然的时间序列属性，因此数据非常适合存储到时间序列数据库当中，要统计所有的 Dubbo 服务的 QPS，那么就需要查找所有名称为dubbo.provider.*.qps的指标，然后对他们进行求和。由于涉及到模糊搜索，这对于绝大部分数据库的实现都是比较费时的。如果要统计更加详细的 Dubbo 方法级别的 QPS 和 RT，那么实现上就会更加复杂了。

通过引入Tag的概念，可以很好的解决了这个问题，我们将 metrics 分为两个部分，Key 和 Tag。

• Metric Key：用英文点号分隔的字符串，来表征这个指标的含义；

• Metric Tag：定义了这个指标的不同切分维度，可以是单个，也可以是多个；

  • tag key：用于描述维度的名称；

  • tag value：用于描述维度的值；

同时，考虑到一个公司所有微服务产生的所有指标，都会统一汇总到同一个平台进行处理，因此Metric Key 的命名方式为应当遵循同一套规范，避免发生命名冲突，其格式为appname.category[.subcategory]*.suffix

• appname: 应用名；

• category: 这个指标在该应用下的分类，多个单词用'_'连接，字母采用小写；

• subcategory: 这个指标在该应用下的某个分类下的子分类，多个单词用'_'连接，字母采用小写；

• suffix: 这个关键的后缀描述了这个指标所度量的具体类型，可以是计数，速率，或者是分布；

在上述例子中，同样的指标可以命名为dubbo.provider.service.qps{service="DemoService"}