Uber开源其大规模指标平台M3
Uber的工程团队发布了其开源指标平台M3，该平台已经在Uber内部使用多年。构建这个平台是为了取代基于Graphite的系统，M3提供了集群管理、聚合、收集、存储管理、分布式时序数据库（TSDB）以及带有其查询语言M3QL的查询引擎。
\u0026#xD;\n\u0026#xD;\nUber之前的指标和监控系统是基于Graphite的，由一个共享的Carbon集群作为支撑，Nagios负责告警，Grafana负责提供仪表盘功能。这种方式的问题在于弹性和集群能力比较差、扩展Carbon集群的运维成本比较高以及缺少副本的功能，使得每个节点都面临单点故障的风险。新的M3指标系统就是为了应对这些问题而产生的。除了扩展性、全局性、跨数据中心的响应式查询之外，新系统的目标还包括标记指标、维持以StatsD和Graphite格式发送指标的服务的兼容性。Rob Skillington是Uber的软件工程师，在最近的文章中描述了M3的架构。M3目前存储了66亿条时序数据，每秒收集5亿个指标并且每秒存储2000万个指标。
\u0026#xD;\n\u0026#xD;\n初始版本的M3包含了一些开源的组件，包括用于聚合的statsite、用于存储的Cassandra以及用于索引的Elasticsearch。但是这些组件逐渐被内部实现替代了，这主要是因为不断增加的运维成本以及对新特性的需求。在Uber，因为很多团队在广泛使用Prometheus，M3在构建的时候，集成Prometheus作为远程的存储后端。
\u0026#xD;\n\u0026#xD;\nPrometheus的集成是通过一个sidecar组件实现的，该组件会向本地区域（regional）的M3DB实例写入数据，并将查询扩展至“区域间协调器（inter-regional coordinator），它会从本地区域的M3DB（存储引擎）实例协调读取”。这种模型的运行方式类似于Thanos，Thanos是Prometheus的一个扩展，提供了跨集群联合、无限制存储以及跨集群全局查询的功能。但是，Uber团队基于各种原因并没有选择Thanos，主要原因在于非本地存储的指标所带来的高延迟。Thanos从AWS S3中拉取并缓存指标数据，因此会带来相关的延迟和用于缓存的额外空间使用，鉴于Uber在延迟方面的需求以及庞大的数据量，这种方式是不可行的。
\u0026#xD;\n\u0026#xD;\nM3的查询引擎提供了所有指标数据的全局视图，无需跨区域的副本。指标写入到本地区域的M3DB实例中，副本对区域来讲是本地化的。查询既可以访问本地区域实例，也可以访问存储指标的远程区域中的协调器。结果是在本地聚合的，未来的工作计划是所有的查询都会在远程协调器中进行。
\u0026#xD;\n\u0026#xD;\nM3允许用户指定每个指标存储的保存期限和粒度，就像Carbon一样。M3的存储引擎会将每个指标在区域内生成三个副本。为了减少磁盘的使用，会采用自定义的压缩算法对数据进行压缩。大多数的时序数据库都具有压缩整理（compaction）的特性，较小的数据块会重写到较大的数据块中，并重新组织结构以便于提升查询性能。M3DB尽可能地避免这种压缩整理，从而最大限度地利用主机资源进行更多的并发写入操作并实现稳定的写入和读取延迟。
\u0026#xD;\n\u0026#xD;\nSkillington在文章中说到，“M3DB只有在绝对必要的时候，才会将基于时间的数据压缩整理到一起，比如回填（backfilling）数据，或者将时间窗口索引文件联合在一起具有一定意义的时候”。指标使用一个流模型进行缩小采样（downsample），当指标进入的时候，缩小采样的流程就会执行。
\u0026#xD;\n\u0026#xD;\n因为PromQL缺少了一些特性，所以Uber内部使用了M3自己的查询语言M3QL。在能够处理的指标基数方面会有一些限制，这主要指的是查询而并非存储。M3通过采用Bloom过滤器和内存映射文件的索引，优化了对时间数据的访问。Bloom过滤器用来确定集合中是否存在某些内容，在M3中，它用来确定要查询的序列是否需要从硬盘中检索。团队目前正在致力于添加在Kubernetes上运行M3的功能。
\u0026#xD;\n\u0026#xD;\nM3是使用Go语言编写的，可以通过Github获取。
\u0026#xD;\n\u0026#xD;\n查看英文原文：Uber Open Sources Its Large Scale Metrics Platform M3