为了促进优步全球业务的增长，我们需要能够在任何特定时间快速存储和访问后端系统上的数十亿个指标。作为我们健壮且可伸缩的度量基础设施的一部分，我们构建了M3这个衡量平台已经在优步使用了好几年了。
M3在长保留时间窗口内可靠地容纳大规模指标。为了向更广泛的社区中的其他人提供这些好处，我们决定开源M3平台作为远程存储后端普罗米修斯，一种流行的监控和报警解决方案。作为它的文档状态， Prometheus的可伸缩性和持久性受到单节点的限制。M3平台旨在为Prometheus指标提供一个交钥匙的、可伸缩的、可配置的多租户存储。
作为这项工作的一部分，我们最近发布了M3DBM3的可扩展存储后端。M3DB是一个分布式时间序列存储和反向索引，具有可配置的乱序写。
此外，我们是开源的M3协调员，一个Prometheus sidecar，在M3DB集群之上提供全局查询和存储接口。M3协调器还执行下采样，以及使用保留和汇总规则对度量进行临时保留和聚合。这允许我们使用存储的规则动态地对度量的子集应用特定的保留和聚合etcd，它嵌入在M3DB种子节点的二进制文件中运行。
M3之前的指标
到2014年底，优步的所有服务、基础设施和服务器都达到了一个标准石墨用于存储它们的堆栈Whisper文件格式在一个分片碳集群。我们使用Grafana对于仪表盘和Nagios用于警报，通过源代码控制的脚本发出石墨阈值检查。虽然这可以工作一段时间，但扩展Carbon集群需要手动重新分片过程，并且由于缺乏复制，任何单个节点的磁盘故障都会导致其相关指标的永久丢失。简而言之，随着公司的不断发展，这种解决方案无法满足我们的需求。
为了确保Uber指标后端的可伸缩性，我们决定构建一个系统，作为一个托管平台，提供容错的指标摄取、存储和查询。我们的目标有五个方面:
- 提高可靠性和可伸缩性:确保我们可以继续扩展业务，而不用担心失去可用性或警报的准确性和可观察性。
- 查询返回跨数据中心结果的能力:无缝地实现跨区域的服务和基础设施的全球可见性。
- 低延迟服务级别协议:确保仪表板和警报提供可靠的交互式和响应性的查询延迟。
- 一级维度“标记”指标:提供灵活的、有标签的数据模型，普罗米修斯的标签和其他系统使之流行起来。
- 向后兼容性:以保证数百个遗留服务发射StatsD石墨指标继续发挥作用，没有中断。
引入M3
在评估现有解决方案的开源替代方案后，我们发现没有一个能够满足我们的资源效率或规模目标，并且能够作为自助服务平台运行。最初，M3几乎完全利用开源组件来扮演重要角色，例如statsite聚合,卡珊德拉与数据分层压缩策略对于时间序列存储，和ElasticSearch索引。由于运营负担、成本效率和不断增长的功能集，我们逐渐地超越了每一个功能。
M3于2015年发布，现在包含了超过66亿个时间序列。M3每秒聚合5亿个度量值，并在全球存储中持续保存每秒生成的2000万个度量值M3DB)，使用quorum写入将每个指标持久化到一个区域中的三个副本。它还允许工程师编写度量策略，告诉M3以较短或较长的保留期(2天、1个月、6个月、1年、3年、5年等)和特定粒度(1秒、10秒、1分钟、10分钟等)存储某些度量。这允许工程师和数据科学家使用与定义的存储策略匹配的指标标签(标签)，以细粒度和粗粒度范围智能地存储时间序列。例如，工程师可以选择存储所有指标，其中“应用程序”标签是“mobile_api”，“端点”标签是“注册”，为期30天，粒度为10秒，五年，粒度为1小时。
对于Uber的M3用户来说，与Prometheus的集成仍然是一个越来越重要的优先级，无论是在为任何导出Prometheus指标的应用程序提供可观察性方面，还是在系统监控使用方面node_exporter或其他第三方普罗米修斯度量出口商。从历史上看，Uber的几个团队运行了重要的Prometheus部署，当团队的操作负担变得无法承受时，我们将集成到M3的Prometheus中，允许这些团队在M3持久的长期度量存储中的所有数据中心中以全局视图查询他们的度量。
基于我们之前运行越来越高的度量存储工作负载的经验，我们构建了M3，以:
- 优化度量管道的每个部分，以最少的硬件支出为工程师提供尽可能多的存储空间。
- 确保数据尽可能高度压缩，以减少我们的硬件占用，并在优化方面进行大量投资Gorilla的TSZ压缩进一步压缩float64值，我们称之为M3TSZ压缩。
- 保持存储的精简内存占用以避免内存成为瓶颈，因为每个数据点的很大一部分可以“写一次，永远不读”。而且，为了保持访问时间快速，我们维护了一个布隆过滤器和索引汇总每个碎片的时间窗口块mmap会内存，因为我们允许在一个查询中在很长的保留期内(在某些情况下，跨越数年的保留期)进行多达100,000个唯一时间序列的临时查询。
- 尽可能避免压缩(包括下行采样路径)，以提高主机资源的利用率，以实现更多并发写，并提供稳定的写/读延迟。
- 使用本地设计的时间序列存储，不需要警惕的操作注意以运行高写入量。(我们发现Cassandra在我们之前使用的其他组件之间需要大量的操作关注)。
接下来，我们将讨论M3通过其体系结构实现这些目标的几种方式。
M3提供了所有指标的单一全局视图，避免了上游消费者导航路由的需要，从而提高了指标可发现性的整体简单性。例如，集中式的一体化视图使我们能够避免为单个仪表板安装多个Grafana数据源。此外，对于在区域之间故障转移应用程序的工作负载或跨区域分片的工作负载，单个全局视图使在单个查询中汇总和查询所有区域的指标变得更加容易。这让用户可以在全局范围内看到特定类型的所有操作，并查看更长的留存率以查看单个地方的历史趋势。
为了在不需要跨区域复制成本的情况下实现这种单窗格视图，指标将以M3形式写入本地区域M3DB实例。在此设置中，复制是区域的本地复制，可以配置为按可用分区或机架隔离。查询扇形展开到本地区域的M3DB实例和存储指标的远程区域的协调器，尽可能为匹配的时间序列返回压缩的M3TSZ块。
在未来的迭代中，我们希望设计M3将查询聚合推到远程区域，以便在返回结果之前执行，以及在可能的情况下将查询聚合推到本地M3DB存储节点。虽然在存储指标之前汇总指标更为理想，但并非所有查询模式都是提前计划好的，而且指标越来越多地以一种特别的方式使用。
少件
我们发现Cassandra和其他将数据块压缩在一起的存储系统花费了大量的系统资源(CPU、内存和磁盘IO)来重写存储的数据。由于我们将度量视为不可变的，因此运行一个在压缩上浪费如此多资源的系统是没有意义的。M3DB本身仅在绝对必要时才将基于时间的数据压缩在一起，例如回填数据或在有必要将时间窗口索引文件合并在一起时。
这种减少压缩工作负载需求的策略在整个平台中非常普遍。例如，考虑下采样，这与紧化类似，通常需要读取之前写入的数据并计算聚合。这需要提取大量数据，这会对网络(对于云提供商来说可能很昂贵)、CPU(用于RPC和序列化/反序列化)和磁盘IO造成很大负担。相反，对于M3我们选择在收集时减少采样，从而在摄入时节省空间和资源。
存储策略、保留和下行采样
我们认为工程师不应该花很多时间思考他们的应用程序指标的生命周期。然而，这种行为会导致收集大量可能不需要长时间存储的遥测数据。根据我们开发M3的经验，有效的留存策略默认将所有指标保持在几个合理的、不同的留存期，并要求用户选择他们想要保留更长的时间的指标子集。
M3的度量存储策略定义了标记(标签)匹配器，以便在细粒度或粗粒度级别上关联保留和下采样聚合策略。M3允许工程师和数据科学家定义适用于所有指标的默认规则，例如:
- 保留期:2天，无下采样
- 保留期:30天，降低到一分钟分辨率
- (还有其他的……)
对于按照默认规则保持不同保留率或分辨率的指标，用户可以通过UI或源代码控制下的定义定义特定的存储策略，以明确选择特定的指标。例如，用户可以指定如下类型的映射规则:
—name:保留所有disk_used指标
过滤器:名称:disk_used*设备:sd*
政策:
分辨率:10s
保留:二维
-分辨率:1m
保留:30 d
-分辨率:1h
保留:5 y
rollup有助于减少特定查询访问模式的延迟，并在摄取时间而不是查询时间在跨维度聚合指标。普罗米修斯使用记录规则来汇总度量。类似地，M3具有可在摄取时应用的汇总规则，允许为结果汇总指标设置特定的保留存储策略。
从普罗米修斯和M3开始
要开始使用M3作为一个可伸缩的Prometheus存储，用户需要设置一个M3DB集群来存储和查询指标，并在他们的Prometheus实例上安装M3 Coordinator sidecar——就是这样!
要了解更多信息，请查看以下文档指南:
- 如何建立M3DB集群:
- 如何使用M3作为普罗米修斯远程存储后端:
Prometheus sidecar M3协调器写入本地区域M3DB实例，查询扇形扩散到区域间M3协调器，区域间M3协调器协调从其本地区域M3DB实例读取数据。
对于指标汇总，可能最简单的方法是继续使用Prometheus的记录规则，并利用M3的存储策略为您的指标选择不同的保留和下采样策略。
现在，下采样和匹配度量保留策略发生在M3协调器侧车中，这意味着用户不能在进入时跨多个Prometheus实例使用M3汇总规则将度量汇总在一起。相反，用户只能从单个Prometheus实例汇总指标。在未来，我们希望简化区域运营的过程M3聚合器集群允许用户跨多个Prometheus实例创建汇总，并在etcd上使用leader选举利用复制的下采样。这可能比典型的Prometheus高可用性设置更可取，在这种设置中，两个实例都运行active-active，因此将两个样例写入长期存储(例如M3DB)。
帮帮我们吧
M3DB而且M3协调员从一开始就被构建为开源项目。请提交拉请求，问题到M3 monorepo，以及向M3的提案库．
为了改进开源M3，我们正在积极地做一些事情:
- 将M3协调器和M3DB的新反向索引推出beta版
- 释放m3ctlUI更简单的创作保留和聚合下采样规则
- 在开源M3中添加对StatsD和Graphite的交钥匙支持
- 从社区征求反馈和贡献
我们希望您能在基于prometheus的度量基础设施中尝试M3DB，并给我们您的反馈!
如果你对大规模解决基础设施挑战感兴趣，可以考虑申请一个角色在我们队。一定要去参观Uber的官方开源页面查看有关M3和其他项目的更多信息。
订阅我们的通讯以跟上优步工程公司的最新创新。
