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

Uber 发布开源指标平台 M3

Uber 的工程团队将其内部使用多年的指标平台 M3 开源。M3 旨在替代基于 Graphite 的系统,提供集群管理、聚合、收集、存储管理、分布式时间序列数据库(TSDB)以及使用 M3QL 查询语言的查询引擎。

M3 的背景与动机

Uber 之前的指标收集和监控系统基于 Graphite,使用分片的 Carbon 集群,Nagios 用于告警,Grafana 用于仪表盘。该系统存在弹性差、集群扩展成本高、缺乏复制机制等问题,导致每个节点成为单点故障。M3 正是为了解决这些问题而开发的。新系统的目标包括可扩展性、跨数据中心的全局响应查询、支持指标标记,以及与 StatsD 和 Graphite 格式的向后兼容性。

M3 的架构与性能

M3 由 Uber 的软件工程师 Rob Skillington 详细描述。目前,M3 存储了 66 亿个时间序列,每秒聚合 5 亿个指标,并每秒存储 2000 万个指标。M3 的初始版本使用了开源组件,如 statsite 用于聚合,Cassandra 用于存储,Elasticsearch 用于索引。由于操作开销增加和对新功能的需求,这些组件逐渐被内部实现替代。

Prometheus 集成

由于 Uber 多个团队广泛使用 Prometheus,M3 被设计为与 Prometheus 集成,作为远程存储后端。集成通过一个 sidecar 组件实现,该组件将数据写入本地区域的 M3DB 实例,并将查询分发到跨区域的协调器,协调器从其本地区域的 M3DB 实例读取数据。这种模型类似于 Thanos 的工作方式,但 Uber 团队未选择 Thanos,主要是因为非本地存储指标的高延迟问题。

M3 的查询与存储

M3 的查询引擎提供所有指标的全局视图,无需跨区域复制。指标写入本地区域的 M3DB 实例,复制仅限于区域内部。查询同时发送到本地区域实例和存储指标的远程区域协调器。结果在本地聚合,未来计划在远程协调器进行查询聚合。

存储优化

M3 允许用户为每个指标指定保留期和存储粒度,类似于 Carbon。M3 的存储引擎将每个指标复制到区域内的三个副本。为减少磁盘使用,数据使用自定义压缩算法进行压缩。M3DB 尽可能避免压缩,以最大化主机资源的利用率,提供稳定的写入/读取延迟。

M3QL 与其他特性

M3 的查询语言 M3QL 在 Uber 内部使用,因为其具备 PromQL 不具备的功能。M3 的存储通过使用 Bloom 过滤器和内存映射文件优化访问时间。团队正在为 M3 添加 Kubernetes 支持。

开源与未来

M3 使用 Go 编写,已在 GitHub 上开源。

阅读 10
0 条评论