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的状态，磁盘使用情况和其他指标有关的检查。大多数此类主机级别检查是由基础架构平台团队创建和维护的。
