想象一下，你随时待命，凌晨4点就被叫醒了。半睡半醒时，你抓起手机，迅速静音恼人的铃声。你对自己说，这个警报最好是紧急情况。如果不这样做，警报疲劳就会出现，而真正的警报可能不会引起注意，这是一个叫停机的指示器的情况。的发展阿哥斯讲述了Uber Engineering如何在快节奏的Uber环境中，为数百万系统和业务指标提供高度准确、实时的警报。
背景
Uber利用用户自定义的静态阈值¹（Nagios)与分页系统相结合，以提醒当值人员监视其系统运行状况²通过数以千万计的参数。许多其他科技公司也在手机和他们的后端上这么做。然而，我们也必须使用动态阈值，因为考虑到Uber的妈妈~ 20%增长在美国，数百万个指标的阈值需要定期更新。我们的需求相关指标也遵循很强的每日和每周周期性- - - - - -做好准备星期六晚上山峰- - - - - -静态阈值是远远不够的。静态阈值往往会导致两种情况:
1）假阴性:像鹅一样宽松的阈值，设置得太宽以至于无法考虑潜在增长(每日变化和短期波动)，会在很长一段时间内导致未被发现的问题。
2）假阳性:严格设置的阈值会导致呼叫停机的警报。当真正的停电到来时，随叫随到的工程师每天(和晚上!)都会收到成百上千的假警报，造成警惕疲劳。
此外，在Uber，任何服务原则上都可以调用任何其他服务(这就跟你问声好！)．这在工程上有很多优势，但要想知道它们是如何协同工作的是不可能在头脑中做到的。将服务的交互映射为人工解释并没有帮助，因为生成的依赖关系图就像一碗意大利面和肉丸。
了解各种服务如何使用和相互依赖，以及它们对应的度量- - - - - -根本原因分析的前提条件- - - - - -需要大量的知识，这些知识会随着所监视的系统而扩展。
随着这一切的进行，从2014年9月开始，我们决定建立一个全知的内部监控系统，以跟踪我们日益增加的工程生态系统相互依赖的数量，Argos。只使用静态阈值和跨许多仪表板手动监视指标的时代已经过去了。毕竟，即使我们像狗一样工作，最好的工程团队只有人类．
构建异常检测算法
流异常检测算法有以下几个要求:
快速做出决定．我们需要确定一个数据点是否指示在下一个连续数据点到达之前的更短时间内出现故障。该规范极大地限制了离群点检测算法在线部分的算法复杂度。为了实现较低的评估时间，同时保持较高的可操作性，我们将系统分为两部分:离群检测器和停机检测器:
离群点检测器会根据预先计算的阈值(每小时更新一次)比较流内数据是离群点还是离群点。这使得离群点检测系统的在线部分非常快速和可扩展。在这个阶段之后，很大一部分指标将被标记为inlier;他们的评估已经完成。被分类为异常值的少量剩余指标随后由中断检测器进行分析。
中断检测器在计算上更加复杂，因此不能应用于所有具有高频率的指标。然而，异常值和停机检测器的组合确保了高频率和高可操作性。
是可操作的．我们只需要在系统性能下降时发出警报，以尽量减少工程师的警报疲劳。另一方面，我们不能太过宽泛地发布促销和极端天气提醒，这对优步的指标有很大影响。
把它看作熊宝宝粥理念:我们的停机警报触发灵敏度已经调整刚刚好．来到这里很有挑战性- - - - - -首先涉及到触发过多和过少- - - - - -因为我们对影响我们指标的外部事件没有完整的实时图像，如突然的局部雷暴:
可操作的停机检测系统不能对这些高需求事件发出警报，尽管它们是异常值。为了克服信息不足的问题，我们开发了一个多元非线性的方法。它从多个实时数据流的组合中推断出一个事件是指示中断还是其他(例如，高需求)，并相应地调整我们的算法。我们目前的算法实现了90%的可操作性:十页中有九页是真实停机的指示，比许多同时代的实时异常值检测系统高出许多倍。
是有选择性的．根据定义，数据流的长度是无限的。在给定内存限制的情况下，需要选择历史数据点的最小数量，以保持较高的准确性。我们使用大约730个精心挑选的数据点来预测下一个小时的情况。尽管采用了这种积极的数据选择，但我们的预测精度与输入数据多10 - 100倍的方法相当。
从来不盲目飞行。我们的算法必须具有计算上的鲁棒性，总是能给我们一个答案。例如，可能不收敛的子空间搜索算法是不可取的。SARIMA(季节性自回归综合移动平均)需要一个预定义的最大子空间大小，这对于我们的目的来说通常太小了。
过去的就让它过去吧。过去的中断和异常值不能影响流内数据点的异常值评分。例如，在2015年6月芝加哥的一场雷雨期间(见上图)，乘车需求增加了300%。下周，我们不希望我们的离群值算法适应它。我们利用一个中位数考虑统计稳健性的方法。
是动态的．我们的离群值检测算法必须考虑到每日和每周的季节性。每周都有一个周末，早高峰时间和午餐休息时间也是原因之一世界各地城市的脉搏．我们需要解释反复出现的现象，而忽略随机发生的情况。
从瞥见的真理中学习。异常值很罕见，有点像独角兽的创业公司就像创业风险投资家一样，我们迫切希望在它们还小的时候就把它们识别出来。可用的标记数据很少，所以离群点检测算法不需要标记数据来跟踪每个时间序列。由于我们的快速增长和许多新市场，有时我们知道未来的高需求活动，但我们没有足够的历史数据来量化它们的影响:2015年只是我们在中国的第二个农历新年。
不要错过任何东西．到目前为止，监控系统健康状况的系统最重要的标准是永远不要错过停机，即使以虚假警报为代价。这是FoMO一个极端。
现在我们已经概述了它的规范，让我们看看如何在Uber的操作环境中实现Argos。
异常检测算法
首先，让我们检查一些上下限动态每小时更新阈值(红色和黄色)，这些阈值是由我们的离群值检测算法生成的，我们将其与流内数据进行比较。我们将每分钟的实际数据添加到一个图(蓝色)中以供参考，这当然是事先未知的:
阈值很好地遵循潜在增长、需求模式和内在波动;我们可以保持较紧的阈值，并在不引起大量虚假警报的情况下检测停机。生成这些阈值的唯一用户定义输入是要跟踪的指标列表和通知所有者的通道(寻呼机、电子邮件、自动Phabricator票代等)
几个小时后，下限阈值最大值超过了上限阈值最小值，静态阈值无法实现:
为了保持较高的计算速度，离群点检测器分别考虑每个时间序列。接下来，我们想把这些整合到一个大的图片中。
停机检测、根本原因探索和系统运行状况
一旦异常异常值被识别出来，我们的系统必须决定如何处理它们，这就是指定指标的服务的依赖性发挥重要作用的地方。为了了解Uber的服务依赖，我们基于时间序列的相似性进行聚类。结果输出可以在图形框架中可视化:
我们根据对应的时间序列当前处于异常状态的概率给图中的每个节点上色。这允许快速视觉识别一个特定(子)系统是否以一致的方式受到影响。
随着系统中度量指标数量的增长，识别此类网络中的异常热点及其起源的汇总统计信息变得至关重要。我们已经开发了一个系统健康指数(SHI)，它为我们量化和确定优先级。我们的SHI由三个主要组件组成。第一项考虑的是每个时间序列异常程度的相加效应。第二个术语考虑了每个度量的成对交互作用:与您密切相关的度量是否也显示出问题?最后，我们要特别注意图中连接其他集群的中心节点。这些节点的中断指示性度量将特别麻烦，因为它可能意味着显著的级联服务故障。
了解我们服务的(子)系统健康状况，使我们能够自动判断在随叫随到的升级链中要向哪个人发出警报。例如，单个指标的问题应该引起随叫随到的工程师的注意，但不需要通知工程总监。然而，如果Argos检测到整个子系统受到影响(例如，移动)，问题可以迅速升级。
总结
在一大早抓起你的笔记本电脑，从你的寻呼机提示中调查可能的中断之前，你想知道:
- 系统的哪一部分受到影响?
- 这个指标恶化的速度有多快?
- 考虑到您的工程经验，这种类型的警报首先是值得关注的合理原因吗?
Argos用异常检测完全自动化的算法，令人尴尬的是平行的线性缩放，统计和计算的鲁棒性．答案会出现在警报中，一旦你唤醒正在睡觉的电脑，就可以在仪表板上轻松访问答案。
就像一个忠实的伙伴和毛茸茸的朋友，阿尔戈斯总是保持警惕。阿尔戈斯有时会发作，导致我们醒来。但它学得很快;它使用了一年，已经足够精确，可以自动触发寻呼机警报。多亏了Argos和Uber Engineering对它的持续开发，我们不再频繁地遇到各种各样的不明故障。
脚注
¹静态阈值包括上阈值和下阈值，通常由服务所有者手动设置，并在整个时间内保持不变。
²系统健康意味着响应时间不会下降，即后端系统和产品特性的正常运行时间。
遵循@UberEng在Twitter上获取优步工程公司的最新消息。
