滴滴可观测平台 Metrics 指标实时计算如何实现了又准又省？

在滴滴，可观测平台的 Metrics 数据有一些实时计算的需求，承载这些实时计算需求的是一套又一套的 Flink 任务。之所以会有多套 Flink 任务，是因为每个服务按照其业务观测需要不同的指标计算，也就对应了不同数据处理拓扑。我们尽力抽象用户相同的计算需求，不过由于 Flink 实时计算任务开发模式和实时计算框架的限制，这些观测指标计算任务设计的都不够通用。使用 Flink 做 Metrics 指标的实时计算，维护多套 Flink 任务面临如下一些问题:

• 本应抽象出来的通用 Metrics 计算能力被重复建设且良莠不齐，无法沉淀

• 处理逻辑被随意的 hardcode 到流任务的代码中不易更新和维护

• Flink 发布、扩容、缩容需要重启任务，会导致指标产出延迟、断点、错点

• Flink 平台收费相对较贵，在我们内部成本账单中占大头，有一定成本压力

为了解决这些问题，我们自行开发了一套实时计算引擎: observe-compute(简称 OBC)，以下是对 OBC 实现的介绍。

设计目标

在立项之初，OBC 确定的设计目标如下：

1、打造一款 Metrics 指标计算领域通用的实时计算引擎，这个引擎有如下特性：

• 接轨业界标准: 以 PromQL 作为流处理任务的描述语言

• 任务灵活管控: 策略配置化，计算任务实时生效，执行计划能够人为干预

• 计算链路溯源: 能够实现策略级别的计算结果溯源

• 云原生容器化: 引擎容器化部署，可以做到无停机的动态扩缩容

2、产品能够满足可观测平台全部的 Metrics 指标计算需求，替换重复计算任务，降本增效，重塑观测采集传输计算链路。

目前除了计算链路溯源这一特性，其余引擎特性已全部实现。OBC 目前已经在线上稳定运行数月有余，可观测平台最核心的几套 Flink 计算任务已经完成迁移 OBC 的工作，预计到年底已经迁移的任务能累计为可观测平台节约成本 100 万元。    

引擎架构

引擎架构如上图所示，分成三个组件: 其中 obc-ruler 是引擎中的控制组件，对引擎内的其他组件提供服务注册发现能力，同时负责外部计算策略的接入和执行计划的管控。obc-distributor 从 Metrics 消息队列摄取 Metrics 指标，匹配计算策略，并按照策略的执行计划转发数据到 obc-worker。obc-worker 是引擎中实际负责计算的组件，负责按照执行计划完成指标计算并将计算结果投递到外部持久化存储。

可用性讨论

具体介绍各个组件的核心逻辑前，先介绍下我们对可用性的思考和妥协，以及为了达到可用性目标而引入的一些概念，这部分讨论有助于理解各组件的核心逻辑。

可用性思考

实时计算场景对于数据可用性的要求可以拆分为实时性要求和精准性要求，要求数据低延时、高精准。精准性又可以描述为数据不错、不丢。数据不错的要求我称之为准确性要求，数据不丢的要求我称之为完整性要求。

对于业务观测数据来说，从最终产出的结果上来看，也适合从上述三个角度讨论可用性:

• 实时性: 落到存储中的数据不能出现较大延迟

• 准确性: 落到存储中的数据必须准确的反应系统的状态

• 完整性: 落到存储中的数据不能出现丢点、断点

简单的观测数据处理