目前，Cloudflare Radar 在 Outage Center 中发布了观察到的互联网中断列表（可能包括部分或完全中断）。只要我们能够通过检查 ISP 的状态更新和相关发布，或者查找与电缆切断、政府命令、停电或自然灾害相关的新闻报道，找到与观察到的流量下降相关联的背景信息，我们就会记录这些中断。
然而，我们观察到的中断情况要多于我们目前在 Outage Center 报告的情况，因为在有些情况下，尽管我们仍然能够通过外部数据源（如 Georgia Tech 的 IODA）进行验证，但我们无法找到任何信息源为我们观察到的情况提供可能的原因。这一整理过程需要人工操作，并由内部工具提供支持，使我们能够分析流量并自动检测异常，从而触发工作流程，找到相关的根本原因。虽然 Cloudflare Radar Outage Center 是一个宝贵的资源，但其中一个主要缺点是我们没有报告所有的中断情况，而且当前的整理流程并不像我们希望的那样及时，因为我们仍需要找到背景情况。
正如我们今天在相关博客文章中宣布的那样，Cloudflare Radar 将发布有关国家/地区和自治系统 (AS) 的异常流量事件。这些事件与上面提到的事件相同，它们触发了我们用于验证和确认中断的内部工作流程。（请注意，这里的“异常流量事件”与流量下降相关，而不是意外的流量峰值。）除了将流量异常信息添加到 Outage Center 外，我们还推出了用户可以在位置或网络（自治系统）级别订阅通知的功能：每当检测到新的异常事件，或服务中断表格中添加了新的条目，都会收到通知。有关如何订阅的更多详细信息，请参阅相关博客文章。
每个检测到的异常的当前状态将显示在 Outage Center 页面上新的“流量异常”表中：
自动检测到异常时，其初始状态为
未验证尝试验证“未验证”条目后：
如果我们能确认异常情况出现在多个内部数据源中，以及出现在外部数据源中，我们将把状态更改为“已验证”。如果我们找到了相关的背景信息，我们也将创建一个服务中断条目。
如果无法通过多个数据源确认，我们将把状态更改为“误报”。这将把它从“流量异常”表中删除。（如果已发送通知，但该异常不再显示在 Radar 中，则表示我们已将其标记为“误报”）。
我们也可以手动添加“已验证”状态的条目。如果我们观察到流量的明显下降并已经过验证，但下降幅度不足以让算法捕捉到，就可能出现这种情况。
互联网流量一览
在 Cloudflare，我们拥有多个内部数据源，可以让我们深入了解特定实体的流量情况。我们根据 IP 地址地理位置（对于位置）和 IP 地址分配（对于 AS）来识别实体，并且可以分析来自不同来源的流量，例如 DNS、HTTP、NetFlow 和网络错误日志 (NEL)。下图中使用的所有信号都来自这些数据源之一，在这篇博文中，我们将其视为单变量时间序列问题——在当前的算法中，我们使用多个信号只是为了增加冗余并以更高的置信度识别异常。在下面的讨论中，我们有意选择各种示例，以涵盖广泛的潜在互联网流量场景。
1. 理想情况下，澳大利亚 (AU) 的信号类似于下面所示的模式：稳定的周模式，有轻微的正趋势，这意味着趋势平均值随着时间的推移而上升（我们看到来自澳大利亚用户的流量随着时间的推移而增加）。
当我们执行时间序列分解时，可以清楚地看到这些陈述，这使我们能够将时间序列分解为其组成部分，以更好地理解和分析其底层模式。使用 Seasonal-Trend decomposition using LOESS (STL) 假设一个每周模式并分解澳大利亚的流量，我们得到以下结果：
我们所说的每周模式是指信号的季节性部分，由于我们关注的是人类互联网流量，这是一个预计会观察到的信号。如上图所示，与信号水平相比，趋势分量预计会缓慢移动，残差部分理想情况下类似于白噪声，这意味着信号中所有现有的模式都由季节和趋势分量表示。
2. 下面我们列出了 AS15964 (CAMNET-AS) 的流量，该流量似乎更多的是每日模式，而不是每周。
我们还观察到，信号值在前四天后出现了偏移（蓝色虚线），红色背景显示了一次服务中断，除了在我们的数据和其他互联网数据提供商的数据中看到了这次服务中断外，我们没有找到任何相关报告——我们的目的是开发一种算法，在遇到这种或类似模式时触发事件。
3. 下面是法属圭亚那 (GF) 的类似示例。我们观察到一些数据偏移（8 月 9 日至 23 日）、幅度变化（8 月 15 日至 23 日之间），以及我们在 Cloudflare Radar 中观察到的另一次服务中断，对于此次中断，我们获得了相关背景信息。
4. 另一个示例是 AS203214 (HulumTele) 的几次计划中断，我们也获得了相关背景信息。这些异常是最容易检测到的，因为流量值仅会在发生服务中断时出现（不会被误认为是正常流量），但这也带来了另一个挑战：如果我们的计划只是检查每周模式，由于这些政府指令的中断以相同的频率发生，在某些时候，算法会将其视为预期流量。
5. 肯尼亚的这次服务中断可以看作与上述事件类似：流量下降到几乎看不见。我们还观察到数据中存在一些不遵循任何特定模式的向上峰值（可能是异常值），我们应该根据我们用于建模时间序列的方法来清理这些峰值。
6. 最后，下面是本文中全篇将使用的数据，作为我们如何解决此问题的示例。对于马达加斯加 (MG)，我们观察到明显的周末模式（蓝色背景）。还有一个节日（圣母蒙召升天节），以绿色背景突出显示，以及一次服务中断，以红色背景突出显示。在此示例中，周末、节假日和服务中断的流量似乎都大致相同。幸运的是，这次服务中断显示出了它自己的信息，即本来打算像正常工作日一样上升，但随后却突然下降——我们将在后文中更详细地介绍这一点。
总之，在这里，我们查看了约 700 个实体（这是我们目前自动检测异常的实体数量）中的 6 个实例，我们看到了广泛的可变性。这意味着，为了有效地对时间序列进行建模，我们必须在建模之前执行大量的预处理步骤。这些步骤包括移除异常值，检测短期和长期数据偏移并重新调整，以及检测方差、平均值或幅度的变化。时间也是预处理中的一个因素，因为我们还需要提前知道何时会有活动/节假日（这会导致流量下降）、何时应用夏令时调整（这会导致数据时间转移），并能够为每个实体应用本地时区，包括处理有多个时区的地点和跨时区共享的 AS 流量。
更为棘手的是，其中一些步骤甚至无法以接近实时的方式进行（例如：我们只能在观察新模式一段时间后才能说发生了季节性变化）。考虑到前面提到的挑战，我们选择了一种将基本预处理和统计相结合的算法。这种方法符合我们对数据特征的预期，易于解释，允许我们控制误报率，并确保快速执行，同时减少对前面讨论的许多预处理步骤的需求。
在上文中，我们注意到我们在启动时检测到了大约 700 个实体（地点和自治系统）的异常。这显然不能代表所有国家和网络，而这一数据也有其充分的理由。正如我们在这篇文章中讨论的那样，我们需要看到来自特定实体的足够多的流量（有足够强的信号），才能建立相关模型并随后检测到异常。对于一些较小或人口稀少的国家/地区来说，流量信号的强度根本不够，而对于许多自治系统来说，我们几乎看不到来自它们的流量，这同样导致信号太弱而无法发挥作用。我们最初将重点放在流量信号足够强和/或可能出现流量异常的地点，以及主要或值得注意的自治系统——这些自治系统在一个地点的人口中占有相当大的比例，和/或已知过去曾受到流量异常的影响。
检测异常情况
我们解决这个问题的方法是创建一个预测，即根据我们在历史数据中看到的情况，创建一组与我们的预期相对应的数据点。这将在“创建预测”一节中解释。我们将这一预测与我们实际观测到的情况进行比较，如果我们观测到的情况与我们的预期大相径庭，我们就称之为异常。在这里，由于我们关注的是流量下降，因此异常始终是指流量低于预测/预期的情况。这种比较将在“预测与实际流量的比较”一节中详细阐述。
为了计算预测，我们需要满足以下业务要求：
我们主要关注与人类活动有关的流量。
异常情况发现得越及时，就越有用。这需要考虑到数据摄取和数据处理时间等限制因素，但一旦数据可用，我们就应该能够使用最新的数据点，并检测其是否异常。
低假阳性 (FP) 率比高真阳性 (TP) 率更重要。作为一个内部工具，这不一定正确，但作为一个公开可见的通知服务，我们希望以不报告某些异常情况为代价来限制虚假条目。
选择要观察的实体
除了上面给出的示例之外，数据的质量很大程度上取决于数据量，这意味着根据我们正在考虑的实体（位置/AS），我们具有不同级别的数据质量。举一个极端的例子，我们没有足够的来自南极洲的数据来可靠地检测服务中断情况。下面是我们用来选择哪些实体有资格被观察的流程。
对于 AS，由于我们主要对代表人类活动的互联网流量感兴趣，因此我们使用 APNIC 提供的用户估计数量。然后，我们通过汇总该位置中每个 AS 的用户数来计算每个位置的用户总数，然后计算该位置的 AS 的用户百分比（这一数据也由 APNIC 表格中“国家/地区百分比”列提供）。我们过滤掉该位置用户数量少于 1% 的 AS。葡萄牙的列表如下：AS15525 (MEO-EMPRESAS) 被排除在外，因为它的用户数量不到葡萄牙互联网用户总数（估计值）的 1%。
此时，我们有一个 AS 子集和一组位置（我们不会_先验_地排除任何位置，因为我们希望覆盖尽可能多的位置），但我们必须根据数据的质量缩小范围，以便能够可靠地自动检测异常。在测试了多个指标并对结果进行可视化分析后，我们得出的结论是，稳定信号的最佳预测因素与数据量有关，因此我们删除了不满足两周内每日唯一 IP 最低数量标准的实体——该阈值基于直观检查。
创建预测
为了及时检测异常，我们决定采用每十五分钟聚合一次的流量，并预测一小时的数据（四个数据点/十五分钟的数据块），与实际数据进行比较。
选定要检测异常的实体后，方法就非常简单了：
1. 我们查看预测窗口之前的最后 24 小时，并使用该时间间隔作为参照物。我们的假设是，过去 24 小时将包含有关后续走势的信息。在下图中，过去 24 小时（蓝色）对应的是从周五过渡到周六的数据。通过使用欧几里德距离，我们得到了与该参照物（橙色）最相似的六个匹配——这六个匹配中的四个对应于从周五到周六的其他过渡。它还捕捉了周一（2023 年 8 月 14 日）到周二的假期，我们还看到了一个与参照物最不相似的匹配，即从周三到周四的正常工作日。捕捉到一个不能正确代表参照物的数据应该不成问题，因为预测结果是与参照物最相似的 24 小时的中位数，因此，这一天的数据最终会被舍弃。
要使这种方法奏效，我们需要使用两个重要参数：
我们考虑的是最近 28 天（加上参照日等于 29 天）。这样，我们就能确保每周的季节性至少能看到 4 次，控制了趋势随时间变化而变化的风险，并为我们需要处理的数据量设定了上限。从上面的例子来看，第一天是与参照物相似度最高的一天，因为它对应着从周五到周六的过渡。
另一个参数是最相似天数。我们使用六天是基于经验知识：考虑到每周的季节性，当使用六天时，我们预计最多有四天与同一工作日相吻合，然后还有两天可能完全不同。由于我们使用中位数来创建预测，因此大多数天数仍然是 4 天，这些额外的天数最终没有被用作参照。另一种情况是节假日，例如下面的例子：
在这种情况下，位于一个星期中间的节日就像是从周五到周六的过渡。由于我们使用的是最近 28 天的数据，而节日从周二开始，因此我们只能看到三个匹配的过渡（橙色），然后是另外三个正常工作日，因为在时间序列的其他地方没有发现这种模式，这些是最接近的匹配。这就是为什么在计算偶数值的中位数时，我们使用下四分位数（这意味着我们将数据舍入到较低值），并将结果作为预测值。这也使我们能够更加保守，并在真阳性/假阳性的权衡中发挥作用。
最后，让我们看看服务中断的例子：
在这种情况下，匹配总是与低流量相关，因为最后 24 小时（参照）对应于从周日到周一的过渡，并且由于流量低，最低欧几里得距离（最相似的 24 小时）要么是周六（两次），要么是周日（四次）。因此，预测值是我们期望在正常星期一看到的情况，这就是预测（红色）呈上升趋势的原因，但由于发生了服务中断，实际流量（黑色）远低于预测。
与其他几种建模方法一样，这种方法也适用于常规的季节性模式，而且在节假日和其他移动事件（如每年不在同一天举行的庆典活动）中也能发挥作用，无需主动添加相关信息。尽管如此，在某些用例下，特别是当数据有偏移时，还是会出现失败。这也是我们使用多种数据源来减少算法受数据伪造影响的原因之一。
下面我们举例说明算法随时间变化的情况。
预测流量与实际流量的比较
获得预测和实际流量后，我们将采取以下步骤。
我们计算相对变化，衡量一个值相对于另一个值的变化程度。由于我们是根据流量下降来检测异常情况，因此_实际_流量总是低于_预测值。_
计算这一指标后，我们应用以下规则：
实际值与预测值之间的差值必须至少为信号幅度的 10%。这个幅度是使用所选数据的第 95 个百分位数和第 5 个百分位数之差计算得出的。这样做的目的是避免出现流量较低的情况（尤其是在一天中的非高峰时段），以及微小的实际流量变化对应于较大的相对变化的情况（因为预测值也较低）。举个例子：
预测值 100 Gbps 与实际值 80 Gbps 相比，相对变化为 -0.20 (-20%)。
如果预测值为 20 Mbps，而实际值为 10 Mbps，则总流量的下降幅度要比前一个例子小得多，但相对变化为 -0.50 (50%)。
然后，我们有两条规则来检测相当低的流量：
持续异常：在整个预测窗口中（所有四个数据点），相对变化都低于给定的阈值 α。这样，我们就能发现延续时间较长的较弱异常（相对变化较小）。
点异常：预测窗口最后一个数据点的相对变化低于给定阈值 β（其中 β < α——这些阈值为负；例如，β 和 α 可能分别为 -0.6 和 -0.4）。在这种情况下，我们需要 β< α 来避免因数据的随机性而触发异常，但仍能检测到突然和短暂的流量下降。
α 和 β 的值是根据经验选择的，目的是最大限度地提高检测率，同时将误报率保持在可接受的水平。
关闭异常事件
虽然我们要传达的最重要信息是异常开始的时间，但出于两个主要原因，检测互联网流量何时恢复正常也至关重要：
我们需要有_活动异常_的概念，这意味着我们检测到了异常，而这一异常仍在持续。这样，当异常仍在活动时，我们就可以停止考虑新的参照数据。考虑这些数据会影响参照值和 24 小时内最相似数据集的选择。
一旦流量恢复正常，了解了异常的持续时间，我们就可以将这些数据点标记为异常值并进行替换，这样我们就不会最终将其作为参照或作为参照的最佳匹配。虽然我们使用中位数来计算预测值，而且在大多数情况下，这足以解决异常数据的问题，但在某些情况下，例如用作示例四的 AS203214 (HulumTele)，由于经常在一天的同一时间发生服务中断，这将使异常数据在几天后成为预期数据。
每当检测到异常时，我们都会保持相同的参照，直到数据恢复正常，否则我们的参照就会开始包含异常数据。为了确定流量何时恢复正常，我们使用比 α 更低的阈值，并给它设定一个时间段（目前为四小时），在该时间段内不出现异常，它才会关闭。这是为了避免出现流量下降后又恢复正常并再次下降的情况。在这种情况下，我们希望检测单个异常并将其聚合以避免发送多个通知，并且就语义而言，它很可能与同一异常相关。
总结
互联网流量数据通常是可预测的，这在理论上允许我们建立一个非常简单的异常检测算法来检测互联网中断。然而，由于时间序列的异质性取决于我们观察的实体（位置或 AS），以及数据中人工痕迹的存在，如果我们想要实时跟踪，还需要大量的背景信息，这给我们带来了一些挑战。在这里，我们举例说明了这一问题的挑战性所在，并解释了我们是如何解决这一问题以克服大部分障碍的。事实证明，这种方法可以非常有效地检测流量异常，同时保持较低的误报率，这也是我们的工作重点之一。由于这是一种静态阈值方法，其缺点之一是我们无法检测到不像示例那样大幅度的异常。
我们将继续努力，增加更多的实体并改进算法，以便能够覆盖更广泛的异常情况。
如需了解有关（互联网中断、路由问题、互联网流量趋势、攻击、互联网质量等）的更多信息，请访问 Cloudflare Radar。在以下社交媒体上关注我们：@CloudflareRadar (Twitter)、cloudflare.social/@radar (Mastodon)，以及 radar.cloudflare.com (Bluesky)，或通过电子邮件联系我们。