CNCF案例研究：Uber

Uber怎样使用其开源的Prometheus平台监控4,000个微服务

公司：Uber

地点：加利福尼亚州旧金山

行业：运输技术

挑战

由于需要监控4,000个专有微服务和越来越多的开源系统，到2014年底，Uber的指标使用量已超过了他们基于Graphite和Nagios所能提供的。“许多团队使用预先打包的Graphite监控软件，并尝试在Nagios中编写脚本来检查从这些软件包中收集的指标，这很难大规模维护。”指标和系统监控技术负责人Rob Skillington说道。“此外，所有这些额外服务生成的指标数量，以及Graphite无法在堆栈复制和管理方面进行扩展的事实。它不那么动态，在我们需要做出的任何改变中都需要大量的手动操作和停机时间。”

解决方法

Skillington的团队评估了几种技术，包括Atlas和OpenTSDB，但越来越多的开源系统为Prometheus Metrics Exporter格式添加原生支持这一事实，使得该方向的规模有所提升。“我们最终选择了Prometheus，因为客户端库和功能是Uber工程师想要使用的，”Skillington说。“很明显，使用标准的Prometheus exporter远比编写和维护自己的exporter好得多。总的来说，我们喜欢社区创建的生态系统和支持的基础设施。”他的团队还构建并开源了 M3 平台，这是一个针对Prometheus指标的可扩展和可配置的存储。M3目前在Uber拥有超过66亿个时间序列，每秒可累计达5亿个指标，并且于全球存储每秒2000万个指标。

影响

通过使用Prometheus和M3，Uber用于提取指标的存储成本效率提高了8.53倍。该团队估计，在Uber数据中心为其先进技术部门建立监控系统的速度比之前的流程快4倍。“对于那些支持Prometheus指标的系统，我们几乎不用花任何时间就能上，相对于我们自己进入和手工操作所需的固定时间。”Skillington说。此外，该团队现在减少了16.67倍的运营维护负担：每周的高/低紧急通知数量从Cassandra的25个到M3DB的1.5个。

在短短七年的时间里，Uber已成为全球700多个城市的日常便利。为了帮助管理其指数式增长和由此产生的规模 - 移动应用程序已将车友和司机连接超过十亿次 - 该公司开始将其单体分解为微服务。

但最初只有几十个，很快成为4,000个专有的后端微服务，需要进行监控、警报和异常检测。最重要的是，Uber希望可以观察到服务运行的系统，例如Ubuntu，以及 MySQL 、Cassandra、 Redis 、Etcd、ZooKeeper和Kafka等开源软件，它们都是在公司的数据中心、AWS和GCP的组合上运行。面对这种复杂性，“我们使用Graphite和Nagios构建我们自己的系统和组件进行监控”，指标和系统监控技术主管Rob Skillington说。

到2014年底，已经很明显地Uber已经超过了这个DIY设置。“许多团队使用预先打包的Graphite监控软件，并尝试在Nagios中编写脚本来检查从这些软件包中收集的指标，这很难大规模维护。”指标和系统监控技术负责人Rob Skillington说道。“此外，所有这些额外服务生成的指标数量，以及Graphite无法在堆栈复制和管理方面进行扩展的事实。它不那么动态，在我们需要做出的任何改变中都需要大量的手动操作和停机时间。”

Skillington的团队评估了几种技术，包括Atlas和OpenTSDB，但越来越多的开源系统为Prometheus Metrics Exporter格式添加原生支持这一事实使得该方向的规模有所提升。“我们最终选择了Prometheus，因为客户端库和功能是Uber工程师想要使用的，”Skillington说。“很明显，使用标准的Prometheus exporter远比编写和维护自己的exporter好得多。总的来说，我们喜欢社区创建的生态系统和支持的基础设施。”

此外，他补充说，“项目在CNCF上托管非常重要，因为这意味着我们相信在一段时间内会有一个强大的社区。开放式治理和广泛的行业参与使我们感到放心，Prometheus将与我们现在和将来需要监控的几乎任何流行的开源软件兼容。”

根据该决定，该团队寻找公司现有指标平台的开源替代方案。发现没有任何可以作为自助服务平台运行，或者无法满足公司的资源效率或规模目标，该团队构建并开源了M3平台，这是一个可扩展且可配置的Prometheus指标存储。“刚开始，M3利用几乎完全开源的组件来完成基本功能，例如用于聚合的statsite，带有日期分层压缩策略的Cassandra用于时间序列存储，以及用于索引的Elasticsearch。”Skillington说。 “由于运营负担，成本效率和不断增长的功能集，我们逐渐超出了每一个。”随着时间的推移，Uber开发了替换组件：M3DB、M3 Query、M3 Coordinator和M3 Aggregator，这些作为M3的一部分都是开源的。

Uber的M3平台目前拥有超过66亿个时间序列，每秒可累计5亿个指标，并且于全球存储每秒2000万个指标。

通过使用Prometheus和M3，Uber用于提取指标的存储成本效率提高了8.53倍。该团队估计，在Uber数据中心为其先进技术部门建立监控系统的速度比之前的流程快4倍。“对于那些支持Prometheus指标的系统，我们几乎不用花任何时间就能上，相对于我们自己进入和手工操作所需的固定时间。”Skillington说。此外，该团队现在减少了16.67倍的运营维护负担：每周的高/低紧急通知数量从Cassandra的25个到M3DB的1.5个。

鉴于这些结果，Skillington的团队正致力于加速在Uber采用Prometheus和M3。所有指标都已存储在M3中，任何在本地或云中运行的开源软件主要由Prometheus Metrics Exporters监控。高达10％的Uber专有服务正在使用Prometheus指标客户端库。Skillington希望看到Prometheus和刚刚成为CNCF沙箱项目的 OpenMetrics 提供两种格式的单个客户端库融合。随着时间的推移，Skillington表示，“我们希望将所有专有服务以及我们尚未使用Prometheus/OpenMetrics监控的任何剩余开源软件转换为使用它。”

为此，Skillington表示，与Prometheus的集成增加是一个优先事项，“无论是为任何导出Prometheus指标的应用程序提供可观察性，还是使用node_exporter或其他第三方Prometheus指标出口商进行系统监控。”他的团队也确保任何在Uber产品之外运行的环境都会暴露Prometheus指标，并具有标准的Prometheus设置。此外，“我们希望让没有经验的团队更容易自己运行Prometheus或M3。这种类型的软件不需要复杂操作。”Skillington说。

对于开始这条监控路径的其他组织，Skillington提出了一些简单的建议：“不要解决已经解决过的问题，”他说。“大多数人都以完全端到端的方式评估开源指标基础架构。情况不再是如此。今天，系统之间存在很多互操作性，最好能真正解决你平台和设置所独有的部分。”

这是Uber对M3的使命，现在团队很乐意与其他人分享。“就像其他人所说的那样，我们并非真正从事指标系统的写作或赚钱业务，因此我们希望社区能够采用我们的M3平台并使用它。希望它也有助于路线图。”

KubeCon + CloudNativeCon中国论坛提案征集（CFP）2月22日截止

KubeCon + CloudNativeCon 论坛让用户、开发人员、从业人员汇聚一堂，面对面进行交流合作。与会人员有 Kubernetes、Prometheus 及其他云原生计算基金会 (CNCF) 主办项目的领导，和我们一同探讨云原生生态系统发展方向。

中国开源峰会提案征集（CFP）2月22日截止

在中国开源峰会上，与会者将共同合作及共享信息，了解最新和最有趣的开源技术，包括 Linux 、IoT、区块链、AI、网络等；并获得如何在开源社区中导向和引领的信息。

大会日期：

• 提案征集截止日期：太平洋标准时间 2 月 22 日，星期五，晚上 11:59
• 提案征集通知日期：2019 年 4 月 8 日
• 会议日程通告日期：2019 年 4 月 10 日
• 会议活动举办日期：2019 年 6 月 24 至 26 日

提醒：这是一场社区会议。因此，让我们尽量避开公然推销产品和/或供应商销售宣传。

KubeCon + CloudNativeCon + Open Source Summit赞助方案出炉啦

KubeCon + CloudNativeCon + Open Source Summit多元化奖学金现正接受申请