Uber 开源其大规模指标平台 M3

Uber 的工程团队发布了其开源指标平台 M3，该平台已经在 Uber 内部使用多年。构建这个平台是为了取代基于 Graphite 的系统，M3 提供了集群管理、聚合、收集、存储管理、分布式时序数据库（TSDB）以及带有其查询语言 M3QL 的查询引擎。

Uber 之前的指标和监控系统是基于 Graphite 的，由一个共享的 Carbon 集群作为支撑，Nagios 负责告警，Grafana 负责提供仪表盘功能。这种方式的问题在于弹性和集群能力比较差、扩展 Carbon 集群的运维成本比较高以及缺少副本的功能，使得每个节点都面临单点故障的风险。新的 M3 指标系统就是为了应对这些问题而产生的。除了扩展性、全局性、跨数据中心的响应式查询之外，新系统的目标还包括标记指标、维持以 StatsD 和 Graphite 格式发送指标的服务的兼容性。 Rob Skillington 是 Uber 的软件工程师，在最近的文章中描述了M3 的架构。M3 目前存储了66 亿条时序数据，每秒收集5 亿个指标并且每秒存储2000 万个指标。

初始版本的M3 包含了一些开源的组件，包括用于聚合的 statsite 、用于存储的 Cassandra 以及用于索引的 Elasticsearch 。但是这些组件逐渐被内部实现替代了，这主要是因为不断增加的运维成本以及对新特性的需求。在 Uber，因为很多团队在广泛使用 Prometheus，M3 在构建的时候，集成 Prometheus 作为远程的存储后端。

Prometheus 的集成是通过一个 sidecar 组件实现的，该组件会向本地区域（regional）的 M3DB 实例写入数据，并将查询扩展至“区域间协调器（inter-regional coordinator），它会从本地区域的 M3DB （存储引擎）实例协调读取”。这种模型的运行方式类似于 Thanos ，Thanos 是 Prometheus 的一个扩展，提供了跨集群联合、无限制存储以及跨集群全局查询的功能。但是，Uber 团队基于各种原因并没有选择Thanos ，主要原因在于非本地存储的指标所带来的高延迟。Thanos 从AWS S3 中拉取并缓存指标数据，因此会带来相关的延迟和用于缓存的额外空间使用，鉴于Uber 在延迟方面的需求以及庞大的数据量，这种方式是不可行的。

M3 的查询引擎提供了所有指标数据的全局视图，无需跨区域的副本。指标写入到本地区域的 M3DB 实例中，副本对区域来讲是本地化的。查询既可以访问本地区域实例，也可以访问存储指标的远程区域中的协调器。结果是在本地聚合的，未来的工作计划是所有的查询都会在远程协调器中进行。

M3 允许用户指定每个指标存储的保存期限和粒度，就像 Carbon 一样。M3 的存储引擎会将每个指标在区域内生成三个副本。为了减少磁盘的使用，会采用自定义的压缩算法对数据进行压缩。大多数的时序数据库都具有压缩整理（compaction）的特性，较小的数据块会重写到较大的数据块中，并重新组织结构以便于提升查询性能。M3DB 尽可能地避免这种压缩整理，从而最大限度地利用主机资源进行更多的并发写入操作并实现稳定的写入和读取延迟。

Skillington 在文章中说到，“M3DB 只有在绝对必要的时候，才会将基于时间的数据压缩整理到一起，比如回填（backfilling）数据，或者将时间窗口索引文件联合在一起具有一定意义的时候”。指标使用一个流模型进行缩小采样（downsample），当指标进入的时候，缩小采样的流程就会执行。

因为PromQL 缺少了一些特性，所以 Uber 内部使用了M3 自己的查询语言 M3QL。在能够处理的指标基数方面会有一些限制，这主要指的是查询而并非存储。M3 通过采用 Bloom 过滤器和内存映射文件的索引，优化了对时间数据的访问。Bloom 过滤器用来确定集合中是否存在某些内容，在M3 中，它用来确定要查询的序列是否需要从硬盘中检索。团队目前正在致力于添加在 Kubernetes 上运行 M3 的功能。

M3 是使用 Go 语言编写的，可以通过 Github 获取。

查看英文原文： Uber Open Sources Its Large Scale Metrics Platform M3