共计 4364 个字符，预计需要花费 11 分钟才能阅读完成。
作者：姚辉
在 2018 年，Observability（即可观测性）首次被引入 IT 畛域，并逐步取代只关注零碎整体可用性的传统监控。随着云原生技术的一直倒退，企业从单体架构倒退到分布式架构，应用容器部署拆分进去的一众微服务、与业务联系严密，传统的监控仅适宜报告零碎的整体运行状况无奈进行高度细化的剖析与关联，于是须要将研发视角融入监控，倒退具备比原有监控更宽泛、更被动、更细粒度的能力，这种能力就是可观测性。
Dubbo 3 的建设布局有上云，可观测性是上云必不可少的能力，集群间依据实例可用性负载平衡、Kubernetes 弹性伸缩、建设实例衰弱模型等等使用场景都须要可观测性。
目前 Dubbo 3 的可观测性正在建设中，本文次要介绍 Metrics 模块基础知识与进度。
零 -APM 介绍
APM 全称是 application performance management，翻译过去就是利用的性能治理，次要是用来治理和监控软件系统的性能和可用性。能够保障线上服务的品质，是一个重要的服务治理工具。
如果从零碎职能上分的话，APM 零碎的话能够能够分为三个子系统，别离是 Metrics、Tracing 和 Logging。
Metrics 也叫指标监控，次要是负责解决一些结构化的能够聚合的一些指标数据。
Tracing 又叫链路追踪，次要是围绕单次申请进行信息处理，而后所有的数据都被绑定到零碎的单个申请或者说单个事务上。
Logging 是日志监控，次要梳理一些非结构化的事件。
Metrics 构造与类型
一个 Metrics 由四局部组成，第一个是指标名称；第二个是 labels 或者说 tags 也就是标签，是一些维度数据，这些维度数据能够用来做一些过滤或者聚合查问；第三个是工夫戳，就是它的工夫字段；第四个就是具体的指标的一个值。
除了上述四个局部之外，还有一个十分重要的字段没有体现在数据模型里，就是这条数据的指标类型。不同的指标类型的话它是会用在不同的监控场景，同时它的一些查问和可视化的一些形式，也会有一些区别。
上面简略介绍一些罕用的指标类型。
第一个是 Gague，这个类型的特点就是他是可增可减的。比如说 CPU 负载、沉闷线程数、内存使用率、磁盘使用率，这些数它都是会随着工夫进行稳定的。它存储和展现的都是一个瞬时值。
第二个指标类型 Counter，这个类型的特点是只增不减，比如说接口申请总量，对于这个类型，个别会有几个衍生的解决，一个是能够比拟两个工夫点前后的一个差值，这样能够计算出这个单位工夫内的申请的一个稳定量。第二个就是对工夫进行求导之后，就失去 QPS 这种类型的一个字段。
第三个指标类型是 Summary，次要做的是一个汇总统计，比如说平均值，分位数这样的一些指标。而后这个指标类型的话次要用于接口响应提早这样的一个场景。因为咱们平时在看接口响应提早这个指标的时候，个别除了看它的平均值，可能还会看一些那种分位数指标。
第四个指标类型是 Historgram，它是一个柱状统计，个别是会先对指标进行一个分桶，分桶之后再去统计它的一些值。比如说咱们的还是以那个接口响应提早为例的话，它会比如说有一些那种可视化展现的话，展现它的那个柱状图。
指标收集
Dubbo 的指标体系，总共波及三个模块，别离是指标收集、本地聚合、指标推送。
- 指标收集：将 Dubbo 外部须要监控的指标推送至对立的 collector 中进行存储。
- 本地聚合：指标收集获取的均为根底指标，而一些分位数指标则需通过本地聚合计算得出。
- 指标推送：而获取指标的话有两种形式，第一种是间接拜访 Dubbo 裸露的接口就能够取得 Dubbo 外部统计的指标，第二种是接入第三方服务器进行指标推送，Dubbo 会将收集和聚合后的指标通过 pull 或者 push 的形式推送至第三方服务器，目前只波及 Prometheus，其中 pull 或者 push 由用户抉择。
指标收集
指标收集的目标是为了存储微服务的运行状态，相当于给微服务拍了一个快照，以及为进一步的剖析（比方指标聚合）提供根底数据。
上图为 Dubbo 的架构图，本计划中指标收集的埋点地位或者说切入地位是在 provider 中通过 SPI 的形式增加一个 Filter。
这里贴了局部代码，展现了其中一部分指标收集的逻辑。
咱们是通过 interfaceName、methodName、group、version 四个维度的信息作为 map 存储构造的 key，当然这四个维度的信息最初在指标导出的时候都会转换成后面 metrics 存储构造的 labels 或者说 tags。
接下来给大家展现一个的是咱们一个默认存储器的成员变量。
使用分段锁构造的 ConcurrentHashMap 来保障并发度，其中的 MethodMetric 就是前文说的四个维度信息组成的一个 class。
有一个比拟重要的构造是一个 MetricsListener 的 list，这里其实是一种生产者消费者的模式，因为默认收集器是咱们默认接入的，然而如果须要收集其余指标则须要持续在此增加监听，让其余收集器监听默认收集器的状态，当默认收集器收集到了值就向监听列表推送一个事件，这样其余收集器就能收集到元信息再进一步加工解决。这里也是本地聚合实现的一个逻辑，具体细节不展现了，有趣味的同学能够去看看 Dubbo 3.1 的代码。
本地聚合 - 滑动窗口与 TDigest
本地聚合次要应用滑动窗口与 TDigest，滑动窗口原理如图，假如咱们初始有 6 个 bucket，每个窗口工夫（即一个 bucket 在 current 指针下的停留时间）设置为 2 分钟，每次写入指标数据时，会将数据别离写入 6 个 bucket 内，也就是一条数据写六遍，咱们会每隔两分钟挪动一个 bucket 并且革除原来 bucket 内的数据，读取指标时，会读取以后 current 指向的 bucket 内的指标数据，以达到滑动窗口的成果。
滑动窗口的作用是为了可能对近期的数据做一个聚合，使得咱们每次指向的 bucket 外面存储的都是从以后工夫到过来一个 bucket 生命周期（即 [now – bucketLiveTime * bucketNum, now] 这样一个工夫区间）的指标数据。其中 bucket 的生命周期受窗口工夫和 bucket 数量管制，这个反对用户自定义配置。
接下来是介绍 Dubbo 分位数指标的解决，咱们常说的 p99，p95 这样的指标就是分位数指标，p99 是指在 100 个申请外面，响应时延排名第 99 位的值，能够较好的反馈一个服务的可用性，被称为黄金指标。
Dubbo 在计算分位数指标的时候应用了 TDigest 算法，TDigest 是一个简略，疾速，精确度高，可并行化的近似百分位算法。
TDigest 应用的思维是近似算法罕用的 Sketch，也就是素描，用一部分数据来刻画整体数据集的特色，就像咱们日常的素描画一样，尽管和实物有差距，然而却看着和实物很像，可能展示实物的特色。
上面是 TDigest 的原理。如果有 500 个 -30 ~ 30 间的数字，能够应用概率密度函数也就是 PDF 函数示意这一数据集
该函数上的某一点的 y 值就是其 x 值在整体数据集中的呈现概率，整个函数的面积相加就正好为 1，能够说它刻画了数据在数据集中的散布态势，也就是大家相熟的正态分布。
有了数据集对应的 PDF 函数，数据集的百分位数也能用 PDF 函数的面积示意。如下图所示，百分位数 P75 就是面积占了 75% 时对应的 x 坐标。
PDF 函数曲线中的点都对应着数据集中的数据，当数据量较少时，咱们能够应用数据集的所有点来计算该函数，然而当数据量较大时，只有通过大量数据来代替数据集的所有数据。
这里，须要将数据集进行分组，相邻的数据分为一组，用平均数和来代替这一组数。这两个数合称为质心数，而后用这个质心数来计算 PDF，这就是 TDigest 算法的核心思想。
如下图所示，质心数的平均值作为 x 值，个数作为 y 值，能够通过这组质心数大抵绘制出这个数据集的 PDF 函数：
对应的，计算百分位数也只须要从这些质心数中找到对应的地位的质心数，它的平均值就是百分位数值。
很显著，质心数的个数值越大，表白它代表的数据越多，失落的信息越大，也就越不精准。如这张图所示，太大的质心数失落精准度太多，太小的质心数则有耗费内存等资源较大，达不到近似算法实时性高的成果。
所以，TDigest 在压缩比率的根底上，依照百分位数来管制各个质心数代表的数据的多少，在两侧的质心数较小，精准度更高，而在两头的质心数则较大，以此达到 P1 或 P99 的值要比 P20 更精确的成果。
指标推送之 Prometheus
指标推送的作用是为了将目前 Dubbo 提供的指标进行进一步的存储、运算和可视化，目前第三方服务器只反对 Prometheus。Prometheus 是 CNCF 开源的一个利用于利用监控的零碎。次要有三个模块组成，别离是获取数据，存储数据，数据查问。
获取数据有 Pull 和 Push 两种形式，也是 Dubbo 接入的形式；存储数据 Prometheus 是用的时序数据库这里就不开展讲了；数据查问是其自定义的一套查问 IDL，能够接入 Grafana 这一类报警零碎，当监控指标异样时候能够应用邮件报警或者电话报警。
目前的设计：
指标推送只有用户在设置了配置且配置 protocol 参数后才开启，若只开启指标聚合，则默认不推送指标。
- Promehteus Pull ServiceDiscovery：启动时依据配置将本机 IP、Port、MetricsURL 推送地址信息至中间层，裸露 HTTP ServiceDiscovery 供 Prometheus 读取，配置形式如，其中在 Pull 模式下 address 为可选参数，若不填则需用户手动在 Prometheus 配置文件中配置地址。
- Prometheus Push Pushgateway：用户间接在 Dubbo 配置文件中配置 Prometheus Pushgateway 的地址即可
其中 interval 代表推送距离
相干 Dubbo Metrics 性能咱们预计会在 3.1.2 / 3.1.3 版本中正式 release 公布。
服务治理与商业化
Dubbo 3 的可观测性建设是 Dubbo 3 上云必不可少的一个环节。在 Dubbo 3 对标的商业化产品微服务引擎 MSE 中，针对 Dubbo 3 做了全方面的加强，以一种无侵入的形式加强 Dubbo 3 服务，使其具备残缺的微服务治理能力。
在建设 Dubbo 可观测性的同时，咱们也在联合 OpenSergo 规范构建 Dubbo 3 的残缺的服务治理体系。
OpenSergo 在联结各个社区进行进一步的单干，心愿通过社区来一起探讨与定义对立的服务治理规范。以后社区也在联结 bilibili、CloudWeGo 等企业、社区一起共建规范，也欢送感兴趣的开发者、社区与企业一起退出到 OpenSergo 服务治理规范共建中。欢送大家退出 OpenSergo 社区交换群（钉钉群）进行探讨：34826335
