如何构建Uber的预警生态系统

这篇文章主要介绍“如何构建Uber的预警生态系统”，在日常操作中，相信很多人在如何构建Uber的预警生态系统问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”如何构建Uber的预警生态系统”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！

创新互联建站服务项目包括喀左网站建设、喀左网站制作、喀左网页制作以及喀左网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，喀左网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到喀左省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！

Uber的软件架构包含数千种微服务，这些微服务使团队能够快速迭代并支持我们公司的全球增长。这些微服务支持各种解决方案，例如移动应用程序，内部和基础结构服务以及产品，以及会影响城市和郊区的这些产品的复杂配置。

为了维持我们的增长和架构，Uber的Observability团队建立了一个强大的，可扩展的指标和警报管道，负责在服务出现问题时立即检测，缓解并通知工程师。具体来说，我们构建了两个数据中心警报系统，分别称为uMonitor和Neris，它们流入同一通知和警报管道。uMonitor是我们基于指标的警报系统，它针对指标数据库M3运行检查，而Neris主要在主机级基础架构中寻找警报。

Neris和uMonitor都利用公共管道发送通知和重复数据删除。我们将深入研究这些系统，并讨论如何采取更多的缓解措施，新的警报重复数据删除平台Origami，以及在创建高信噪比警报方面的挑战。

此外，我们还开发了黑匣子警报系统，可以在内部系统出现故障或数据中心完全中断的情况下检测数据中心外部的高级别中断。未来的博客文章将讨论此设置。

报警系统

在我们的警报体系结构中，服务将指标发送到M3。uMonitor检查M3是否存在基于指标的警报。主机检查将发送到Neris进行汇总和警报。Blackbox从Uber外部测试API基础结构。

在Uber的规模上，监视和警报需要在传统的现成解决方案之外进行思考。Uber的警报始于Nagios，使用源代码控制脚本针对指标发布Graphite阈值检查。由于我们的Carbon指标集群存在可扩展性问题，我们决定构建自己的大型指标平台M3。为了提高警报系统的可用性，我们开发了uMonitor，这是我们自己开发的基于时间序列指标的警报系统，用于存储在M3中的指标。对于未存储在M3中的指标，我们构建了Neris以执行主机级警报检查。

uMonitor的构建考虑了灵活性和用例多样性。某些警报是根据标准指标自动生成的，例如端点错误和CPU /内存消耗。其他警报由各个团队创建，这些警报与特定于其需求的指标有关。我们将uMonitor构建为处理这些不同用例的平台，特别是：

• 轻松管理警报：迭代确定警报的适当功能和阈值

• 灵活的操作：诸如寻呼，电子邮件和聊天之类的通知。支持自动缓解措施，例如回滚部署和配置更改

• 处理高基数：能够在最小范围内的关键问题上发出警报，但不能为团队提供大量中断通知

使用uMonitor处理基于metrics的报警

uMonitor具有三个独立的组件：具有警报管理API并封装我们的Cassandra警报和状态存储的存储服务；以及调度程序，用于跟踪所有警报，并为每个警报每分钟将警报检查任务分派给工作人员；以及根据警报定义的基础指标执行警报检查的工作人员。

工作人员在Cassandra存储中维护警报检查状态，并确保通过主动重试机制至少发送一次通知。工人还负责每隔一段时间（通常每小时一次）重新发出警报，以继续发出警报。目前，uMonitor具有125,000个警报配置，每秒可在140万个时间序列中检查7亿个数据点。

警报定义具有M3查询（Graphite或M3QL）和阈值，这些阈值确定警报是否违反阈值。查询从M3返回一个或多个时间序列，并且将阈值应用于每个基础序列。如果查询违反阈值，则发送警报操作。工作人员在存储在Cassandra中的状态的帮助下维护着一个状态机，该状态机确保至少在触发警报后发送通知，在触发警报时定期重新发送，并在问题缓解后解决。

阈值有两种类型：静态阈值和异常阈值。对于具有特定稳态的指标，或者我们可以通过计算成功/失败百分比等值来构造返回一致值的查询，通常使用静态阈值。对于诸如每个城市的旅行计数和其他业务指标之类的周期性指标，uMonitor利用我们的异常检测平台Argos来生成动态阈值，用于根据历史数据来代表指标的异常值。

利用Neris处理主机报警

Neris是我们的基于主机的内部警报系统，旨在为我们的M3指标系统中不提供的高分辨率的每个主机高基数指标。主机指标不在M3中的原因有两个。首先，检查每个数据中心每40,000个主机每分钟生成的150万个主机指标中的每个指标，在主机上执行效率比在中央指标存储中查询要高。这样，就不需要摄取和存储指标的开销。其次，直到最近，M3的保留策略导致10秒钟的度量标准被存储48小时，而一分钟的度量标准被存储30天，并且不需要使用该保留和解决方案来存储主机度量标准。由于Nagios要求为每张支票编写和部署代码，但随着我们基础架构的增长而无法扩展，因此我们决定在内部构建一个系统。

Neris的代理可在我们数据中心的每台主机上运行，并定期（每分钟）对主机本身执行警报检查。然后，代理将检查结果发送到聚合层，聚合层又将聚合结果发送到Origami。Origami负责根据查看失败警报数量和基础警报的严重性的规则来决定要发送什么警报。利用Origami，Neris在每个数据中心的主机主机中每分钟运行约150万个检查。

在每台主机上启动代理时，Neris会从名为Object Config的中央配置存储中提取主机的警报定义信息，该存储被Uber的低级基础架构服务广泛使用。确定哪些警报将在给定主机上运行取决于其角色。例如，运行Cassandra的主机将进行与Cassandra的状态，磁盘使用情况和其他指标有关的检查。大多数此类主机级别检查是由基础架构平台团队创建和维护的。

处理高基数

高基数一直是我们警报平台的最大挑战。传统上，这是通过使警报查询返回多个序列并仅在序列的某个百分比以上违反阈值时才触发警报周围的简单规则来处理的。uMonitor还允许用户将警报设置为依赖于其他警报-跟踪更大范围问题的警报取决于更大范围的警报，并且如果触发更大范围的警报，则从属警报将被抑制。

只要查询返回有限数量的序列，上述技术就可以很好地工作，并且可以轻松定义依赖项。但是，随着Uber越来越多地在数百个城市中运营许多不同的产品线，基数挑战已要求一种更通用的解决方案。我们使用Origami来协助处理高基数。Neris将Origami用作其主要的重复数据删除和通知引擎，并启用了uMonitor警报的合并通知。

对于业务指标，当我们需要针对每个城市，每个产品，每个应用版本发出警报时，Origami非常有用。Origami允许用户为城市，产品和应用程序版本的组合创建基础的警报/检查，并在汇总策略上发出警报，以基于每个城市/产品/应用程序的版本接收通知。在停电较大的情况下（例如，当许多城市同时出现问题时），Origami将发送汇总通知，指示触发的底层警报列表。

在主机警报方案中，Origami使我们能够基于警报的汇总状态发送各种严重性的通知。我们来看一个有关Cassandra群集上磁盘空间使用情况的示例。在这种情况下，对此的Origami通知政策可能类似于：

• 如果少于三台的主机使用了70％的磁盘，则发送电子邮件通知

• 如果三个以上的主机有70％的磁盘使用率，则发送页面

• 如果一个或多个主机磁盘使用率达到90％，则发送页面

报警通知

有用的警报通知是扩展警报系统的主要挑战。警报操作主要从通知开始，例如针对高优先级问题呼叫工程师，以及针对信息性问题使用聊天或电子邮件。现在，我们的重点已转向制定缓解措施。大多数事件和中断都是由于配置更改或部署而发生的。uMonitor为缓解操作提供了一流的支持，这些操作可以回滚最近的配置更改和部署。对于具有更复杂的缓解运行手册的团队，我们支持webhooks，这些Webhooks可针对具有警报完整上下文的端点进行POST调用，从而可以运行缓解运行手册。此外，通过利用Origami中的重复数据删除管道，我们可以在发生较大故障时抑制更精细的粒度通知。

除上述内容外，我们一直在努力使通知更加相关，并使通知针对合适的个人。最近的工作涉及识别配置/部署变更所有者，并在警报触发他们已修改的服务时触发他们。通过结合来自Jaeger的跟踪信息和警报信息，我们在围绕相关服务故障的警报通知中提供更多上下文方面做出了额外的努力。

报警管理

如前所述，我们一直致力于将uMonitor构建为其他团队可以针对特定用例建立的平台。主机警报的设置和管理通常是专门的，主要用于维护自己专用硬件的团队，以及正在为公司构建基础架构平台（包括存储，指标和计算解决方案）的团队。警报是在团队的单独git存储库中配置的，这些存储库已同步到Object Config。

从较高的角度来看，uMonitor具有三类警报：

• 根据所有服务的CPU，磁盘使用率和RPC统计信息的标准指标自动生成警报

• 通过UI创建的一次性警报以检测特定问题

• 通过uMonitor之上的脚本和外部配置系统创建和管理警报

随着团队努力以可能的最佳粒度检测可警报的问题，我们在最后一类警报中看到了最大的增长。对这种粒度的需求归结于Uber的全球增长。支持Uber移动应用程序的服务的代码更改通常会在几个小时内推广到特定的城市群体。我们非常重要的一点是，我们必须在城市一级监视平台的运行状况，以便在问题广泛传播之前找出问题所在。此外，每个城市的工程和本地操作团队控制的配置参数也不同。例如，由于游行等正在进行的事件，城市中的骑手接送可能会被阻塞在街道上，或者其他事件可能会导致交通变化。

许多团队已经在uMonitor上构建了警报生成解决方案来解决此类用例。这些工具解决的一些挑战是：

• 遍历各个维度迭代并生成警报

• 根据特定的业务信息（例如特定国家/城市的假期）确定警报时间表，并在uMonitor中配置该信息以防止虚假警报

• 如果静态或当前异常阈值不起作用，请基于过去的数据或对适用于特定业务线的基础指标的复杂查询来确定阈值（更多有关以下警报查询）

此外，这些解决方案中的许多解决方案都会生成与所生成的警报同步的仪表板。

uMonitor还提供了功能强大的编辑和根本原因UI。UI的编辑和实验方面至关重要，因为由于变化和峰值，大多数指标无法按原样用于警报。可观察性团队为如何创建更适合警报的查询提供了指导。

报警查询

Graphite查询语言和M3QL提供了大量功能，可提供更多定制解决方案。下面，我们概述了一些示例，这些示例说明了如何使查询返回更一致的值以使指标更易于警惕：

• 提醒您说几分钟内移动指标的平均值，以消除指标的任何峰值

• 将以上内容与维持期结合使用，仅在阈值违例持续了一定时间后才发送通知

• 对于具有上下模式的指标，请使用导数函数以确保任一方向的峰值都不会太突然

• 发出百分比/比率警报，以使度量标准不易受到度量标准大小变化的影响

到此，关于“如何构建Uber的预警生态系统”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！