CNCF案例研究：Uber

时间 2020-02-06

标签 cncf 案例研究 uber 栏目硅谷繁體版

原文原文链接

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

公司：Uber
地点：加利福尼亚州旧金山
行业：运输技术linux

挑战

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

解决方法

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

影响

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

“Prometheus增长了大量高质量的库和常见的监控指标出口商（exporter），它导出指标的方式使咱们很容易继续引入现有软件并大规模使用。”后端

ROB SKILLINGTON，UBER指标和系统监测技术主管

在短短七年的时间里，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没法在堆栈复制和管理方面进行扩展的事实。它不那么动态，在咱们须要作出的任何改变中都须要大量的手动操做和停机时间。”微服务

“开放式治理和普遍的行业参与使咱们感到放心，Prometheus能够与咱们如今和将来须要监控的任何流行的开源软件兼容。”区块链

ROB SKILLINGTON，UBER指标和系统监测技术主管

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的一部分都是开源的。

“咱们并不是真正从事指标系统的写做或赚钱业务，所以咱们但愿社区可以使用咱们的M3平台并使用它。但愿它也有助于路线图。”

ROB SKILLINGTON，UBER指标和系统监测技术主管

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

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

“不要解决已经解决的问题，”他说。“大多数人都以彻底端到端的方式评估开源指标基础架构。状况再也不是如此。今天，系统之间存在不少互操做性，最好能真正解决你平台和设置所独有的部分。”

ROB SKILLINGTON，UBER指标和系统监测技术主管

为此，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多元化奖学金现正接受申请