Uber的软件架构由成千上万的微服务组成，有赖于此，我们的团队可以快速的自主迭代并支撑公司的全球扩张。这一架构支撑了大量的上层解决方案，如移动应用，内部基础设施服务，以及拥有复杂配置的产品，相关配置会对产品在一、二线城市的表现产生不同的影响。

为了保障对业务扩张的支撑，以及维持架构的稳定性，Uber的可见性团队构建了一个健壮、可扩展的指标系统以及告警管道。这一系统可以监测相关服务， 以便在故障发生的第一时间延缓产生的影响并通知相关的工程师。

如图中所示，uMonitor和Neris利用一个共有的管道来发送通知并去重。稍后我们会深入了解这些系统，并探讨如何推动建立更多的缓冲措施，和我们新的告警去重平台Origami，以及在建立高“信噪比”的告警系统方面如何应对挑战。

信噪比，英文名称叫做SNR或S／N（SIGNAL－NOISE RATIO），又称为讯噪比。是指一个电子设备或者电子系统中信号与噪声的比例。

此外，我们还建立了一个黑盒系统，用于侦测内部系统失败或者数据中心整体当机所引发的更高一级的系统中断。后续的文章会有讨论。

1．Uber的告警系统

图表1：在我们的告警体系中，相关服务向M3发送指标数据，uMonitor会负责检查M3中的数据并产生基于指标的告警信息。主机检测信息会发送到Neris并产生聚合和告警信息。Uber外部可以对基础设施API进行黑盒测试。

在Uber的体量下，传统的现成解决方案无法满足监控和告警的要求。我们采用开源的Nagios，结合Graphite的阈值检测，以及后端的Carbon指标系统 ，辅以源码控制脚本来解决这个问题。基于对Carbon指标系统伸缩性的考量，我们决定建立一个自有的大规模度量平台，即M3。为了提升告警系统的可用性，我们自主研发了时序告警系统uMonitor，用于处理M3中存储的指标数据。对于M3以外存储的指标数据，我们建立了Neris来进行主机一级的告警检测。

在uMonitor的开发过程中，灵活性和用例差异性是两个重要的考虑因素。有些告警信息是基于标准指标自动生成的，如端点错误或者CPU／内存占用率过高等。还有些告警信息是由某个团队根据具体的需要所建立的指标生成的。uMonitor作为一个平台系统，会对这些不同种类的用例所产生的指标进行处理，诸如：

告警的易管理性：迭代产生适用于告警信息的功能和阈值。

弹性措施：利用寻呼、邮件和聊天系统发送通知。支持自动化的缓解措施，如部署和配置变更的回滚等。

处理海量信息：既可以响应小范围的关键事件，又不至于在大范围的中断情况下让工程团队被报警信息淹没。

2．基于指标的告警系统：uMonitor

uMonitor由三个独立组件组成：一个拥有告警管理API的存储服务，可以对Cassandra告警和状态信息进行打包存储；一个调度器，负责跟踪所有的告警信息，并时刻将报警检查任务分发到workers；一组workers用来基于告警信息自定义的指标执行检查任务。

workers会将告警检查的状态信息保存在Cassandra存储中，并通过激进的重试机制来确保相关的通知确实发送成功。只要告警信息持续产生，workers会负责进行不时的（通常是每小时1次的）重试告警。目前，uMonitor可以在1秒内使用125，000个告警配置来对140万笔时序数据的7亿个数据节点进行检查。

图表2：相关服务向M3发送指标数据，uMonitor的调度器安排相关的workers进行相关指标检查，如果检查结果超过一定阈值，就发送通知。

一条告警信息由M3查询（Graphite 或者M3QL）语句和阈值组成。阈值将决定告警是否触发。查询语句从M3返回时序数据，阈值会应用于对应的时序数据。一旦查询的结果超过了阈值，告警就会触发。借助Cassandra存储的状态信息，相关worker会维持一个状态机，以确保告警触发的状态下相关的通知成功发送，并在告警持续触发的情况下不时的重发通知，以及在事态缓解的情况下将相关通知标记为解决。

阈值一般分为两种：静态阈值和反常阈值。对于一些具备特定的、稳定状态的指标，或者我们可以构造查询来通过数值计算返回常量值的指标（如成功／失败比），通常使用静态阈值。对于一些周期性的指标，如客户在某市的行程次数或其他的业务指标，uMonitor使用Argos这个反常监测平台来生成动态的阈值，以表征基于历史数据的反常数值。

3．主机告警组件：Neris

Neris是一个基于主机的内部告警系统，用于解决M3指标系统以外的高精度的海量指标数据。将主机指标系统设置在M3之外，是基于两个原因。首先，要对每个数据中心的40，000个主机节点每分钟所产生的150万条主机指标数据进行检查，基于主机的机制相对于从中心指标存储库查询来说更加高效，严格意义上讲，相关指标的提取和存储是毫无意义的开销。其次，当前M3的保留策略是，10秒的指标数据会存储48小时，1分钟的指标数据会存储30天，对于主机指标来说，以如此的精度和保留策略存储相关数据并没无必要。开源的Nagios是以检查为单位来编码和部署的，这意味着基础设施扩张时，主机指标系统无法自动伸缩，因此我们决定自己开发一个系统来应付需要。

Neris的机制，是在数据中心的每个主机上部署一个代理，并基于单主机每分钟定时执行告警检测。随后，相关的检查结果会发送到一个聚合层，聚合层将聚合结果发送给Origami。Origami负责决定发送哪些告警信息，发送的优先级将视告警的失败次数以及潜在告警危急程度而定。基于Origami，Neris可以在每分钟对我们每一个数据中心的主机集团进行150万次检测。

主机上的代理启动时，Neris从一个名为Object Config的中心配置存储拉取主机的告警定义信息。Object Config这一机制广泛的应用于Uber的底层基础设施服务。哪些告警会被触发取决于其角色。例如，运行Cassandra的主机会运行与Cassandra状态、磁盘使用情况等指标相关的检查。绝大多数主机级别的检查由基础设施平台团队负责建立和维护。

图表3：在Neris的机制中，主机检查基于数据中心的每个主机进行，并通过Neris聚合器实现聚合，并由Origami发送告警通知。