4．处理规模数据

我们的告警平台在处理海量数据方面一直面临着巨大的挑战。传统的解决方案是，通过一条告警查询返回多条时序数据，并且只有在一定比例的数据超过阈值的时候，才使用简单的规则来触发告警通知。uMonitor同样允许用户基于告警来设置告警。如果一条告警依赖于更大范畴的告警，则一旦上一级告警触发的情况下，下级告警将被阻塞。

当查询结果返回的是既定数量的时序数据，且依赖关系可清晰定义的时候，上述方法可以工作的很好。然而，急速扩张中的Uber需要在数以百计的城市运营多条产品线，数量级的挑战需要更通用的解决方案。我们使用Origami来处理海量的任务。Neris将Origami作为主要的去重器和通知引擎，从而，uMonitor告警系统有了稳固的通知系统。

对于业务指标来说，Origami对于单城市／单产品／单应用版本的告警是用处巨大的。Origami允许用户基于城市、产品和应用版本的组合来建立潜在的告警和检查，并基于聚合策略来触发告警，来接收某个城市、产品或者应用的通知。在更大范围的系统中断的情形下（如多个城市同时发生故障），Origami会发送累积通知，用以表征已触发的告警列表。

在主机告警的场景下，Origami使我们可以基于告警的聚合状态发送不同严重程度的通知。以Cassandra集群的磁盘使用率为例，此情形下的Origami通知策略如下：

当磁盘利用率超过70％的主机数小于3，则发送邮件通知。

当磁盘利用率超过70％的主机数大于3，则发送寻呼通知。

当磁盘利用率超过90％的主机数大于1，也发送寻呼通知。

5．告警通知

处理告警系统的伸缩问题，最主要的挑战来自于如何产生有用的告警通知。对于高优先级的事件，告警行为一般采用的通知方式是寻呼待命的工程师，而对于一般的告知类事件，是通过邮件或者聊天工具来进行通知。我们关注的重点在于构建一些缓解行为来减轻事件的影响。绝大多数的系统中断或者其他问题来源于配置变更或者部署问题。有些团队需要处理非常复杂的缓解行为运行手册，对此我们支持以webhook的方式发送POST调用，并附加告警信息完整的上下文信息，来自动化对运行手册的落地。此外，在更大范围的系统问题发生时，利用Origami的去重管道，我们可以阻塞一些细粒度的通知，以免工程团队被信息也淹没。

除了上述的手段以外，我们也致力于让通知的相关性更高，并且匹配到正确的处理者。最新的成果是，当某个服务发生变更并产生告警时，我们可以定位到配置或部署变更的所有者，并直接通知他们相关事项。并且，通过把Jaeger的追踪信息与告警信息进行结合绑定，我们可以为相关的服务失败提供更多的上下文信息。

6．告警管理

上面也讲到，之所以花大力气将uMonitor平台化，是为了让不同的团队可以基于这个平台，来处理特有的用例场景。对于不同的团队，尤其对于需要维护专有硬件的团队，以及需要为公司构建基础设施平台的团队来说，在处理诸如存储、指标管理、计算解决方案等场景的告警问题时，相关的设置和管理往往是特定的和专业化的。相关的告警设置存储在团队自有的Git库中，并向Object Config进行同步。

从更宏观的视角，uMonitor有三类告警：
－ 针对所有服务来说，CPU、磁盘利用率和RPC状态这些标准的指标，会自动生成告警信息。
－ 针对特定事件，经由UI产生一次性的告警信息。
－ 在uMonitor之上的一层，告警信息的生成和管理通过脚本和外部配置系统完成。

当团队致力于侦测尽可能细粒度的告警事件的时候，一些初级的告警信息就会产生爆发式增长。随着Uber的全球扩张，如此细粒度的告警信息的重要性随之下降。对于支撑Uber移动应用的相关服务来说，相关的代码变更可以在几小时内，就覆盖到一部分城市的某些特定群体。在城市一级对平台的健康度进行监测，发现问题并避免问题扩散，对我们来说尤其重要。此外，工程团队和本地的运维团队所需要管理的配置参数，也因城市而异。例如，某个城市的某条街道的游行队伍，或者其他事件导致的交通情况的变化，都会影响Uber骑手的匹配。

很多的团队已经基于uMonitor构建了告警信息的发生方案，以处理类似上述的这种场景。已经解决的挑战包括：
－ 迭代和生成多维告警信息
－ 基于特定的业务信息（如某个国家和城市的节日）调度告警任务，并在uMonitor中存储相关的配置，以避免产生错误的告警信息
－ 当静态或者反常的阈值失效的时候，可以基于历史数据，或者基于特定的业务线的潜在指标进行的复杂查询，来生成新的阈值。

此外，上述的解决方案可以生成仪表盘。相关的信息与产生的告警信息同步。

uMonitor还提供了一个强有力的编辑界面，可以展示相关的因果联系。UI的编辑和验证的功能十分重要，因为差异性以及峰值的存在，大部分的指标并不能用于告警。对于如何为告警建立更理想的查询，可见性团队会给出一些指导建议。

7．告警查询

为了允许更加定制化的解决方案，Graphite查询以及M3QL查询语言所提供的功能很多，甚至有些过犹不及。下我们举了一些示例，来展示如何让查询返回更多的常量，以使得相关指标更可用于告警：

－ 使用一段时间内的移动均线指标，可以平滑掉指标中的峰值
－ 在上一点的基础上，结合采用维持策略，仅当超过阈值的状况持续了一段时间之后，才发送告警通知。
－ 对于一些遵循升降模型的指标，采用导数函数确保无论是上升或者下降，相关指标不会太突兀。

－ 使用比率或者百分比来进行告警，以使得指标不会因绝对值的变化而受到影响。

8．未来计划

如何让系统扩展的同时具备分钟级的问题侦测能力，并且仅暴露合适的信息给到用户，避免不必要的告警信息，在这方面的工作我们还只是刚刚起步。为了达成这样的目标，告警管道的方方面面都进行着大量的工作，包括：更有效的指标收集，扩展和提升告警执行基础设施的效能，构建更有效的UI和接口以处理不同来源信息的相关性等等。

如果本文的一些内容让你产生了对规模级可见性挑战的兴趣，欢迎来我的团队与我并肩作战。