ClickStack 内置 z-score 异常检测并扩展告警调度

简介

今年五月，我们推出了SQL 图表与告警，以回应那些需要更复杂告警条件的客户。用户可以用任意 ClickHouse SQL 来表达这些条件，包括检查错误相对于滚动基线的激增。这种灵活性也意味着需要编写和维护 SQL 来计算基线并决定何时触发告警。

这些需求中有许多归根结底是要检测与近期历史相比的异常值。用户希望将这些检查应用于现有的查询构建器可视化，因此我们在 Managed ClickStack 中使用 z 分数添加了内置的异常检测。用户可以调整灵敏度，并预览告警在选定的历史范围（例如过去两小时或前一天）内会在何时触发。每个 z 分数都会将一个值与之前最长 24 小时的窗口中的数据进行比较。我们特别关注避免因原本稳定的指标出现微小波动而产生误报。

采用 Managed ClickStack 的团队，包括从 Grafana 迁移过来的团队，也带来了数以万计的现有告警。我们改进了调度器，并引入了分片，将评估分布到多个工作进程，以处理大规模的告警工作负载。

为了让这些规模更大的告警集合便于管理，我们还改进了告警 UI 中的搜索和过滤，添加了显示告警活动的图表，并扩展了评估历史，以帮助用户调查告警触发或失败的原因。

在本文中，我们将探讨这些变更，以及它们如何支持团队将更多告警工作负载迁移到 Managed ClickStack。

在您已经在使用的图表上进行异常检测

ClickStack 已支持静态阈值告警有一段时间了。当您有明确的、想要强制执行的限制时，这些告警效果很好。但当您要寻找行为变化时，它们就变得更难配置，尤其是在正常运行范围各不相同的服务之间。

例如，假设有一个服务的错误率通常徘徊在 0.1%。上升到 0.9% 是一个相当大的变化，但设置为 1% 的静态告警仍会保持静默。降低该阈值对这个服务可能有效，但另一个背景错误率更高的服务则需要不同的设置。

将每个服务与其自身的历史进行比较，为我们提供了一种无需为每个服务维护单独阈值就能检测这些变化的方法。我们最初的异常检测实现使用 z 分数，这是一种常见的统计方法，用于将一个值与其近期历史进行比较。这允许每个服务针对其自身的基线进行评估，不过决定如何计算该基线存在一些微妙之处。

z 分数衡量一个值偏离其基线均值的程度，以标准差表示。因此，其灵敏度取决于该指标通常的变化幅度：对一个稳定服务而言不寻常的变化，对一个波动较大的服务来说可能是常态。这给告警带来了挑战，因为统计上不寻常的变化并不总是大到值得关注。

我们在开发过程中遇到了这一点。我们最初的尝试是从评估窗口之前的一个短时间段内估算基线均值和标准差。当我们在一个几乎不动的内存指标上测试它时，标准差接近零。于是即使微小的波动也会产生很高的 z 分数，并反复触发检测器，尽管内存使用几乎没有有意义的变化。

我们通过在不同时间段计算期望值和标准差来解决这个问题。期望值来自七个历史一分钟桶的移动平均，取自早一个评估间隔。我们在更长的基线上计算标准差——默认两小时。短平均确定了我们进行比较的水平，而更长的历史告诉我们多少变化是正常的。然后我们将观测值与期望值之间的差除以该标准差，以计算 z 分数。

我们还要求相对于期望值至少变化 5%。这可以防止稳定指标中的微小变动仅仅因为产生很大的 z 分数而生成告警。对于我们的错误率示例，从 0.1% 上升到 0.9% 轻松满足该要求，即使它还不到一个百分点。

我们还发现，不完整的数据可能看起来像异常。采集器通常会批量发送，因此在一个分钟结束后立即评估它，可能会让稳定的数据流看起来像是下降了。因此，异常评估允许 30 秒的数据到达时间，然后再检查该窗口。

配置异常检测

您可以通过将告警类型改为异常检测，直接从现有的查询构建器图表配置异常告警。除了灵敏度之外，您还可以选择使用多少历史作为基线，以及哪个方向的变化应触发告警。默认值为 z 分数阈值 3 和两小时基线。

对于错误率示例，您会选择高于预期范围，因为我们关注的是错误的不寻常增加。吞吐量告警可以使用低于预期范围来检测请求的意外下降。如果任一方向的变化都值得调查，请选择超出预期范围。这适用于请求量告警，因为突然激增和突然下降都可能表明存在问题。

在每种情况下，预期范围都是使用该指标的近期历史和配置的灵敏度计算得出的。如果图表按服务对值进行分组，则每个服务都会根据其自身的历史独立评估，因此流量水平不同的服务可以共享相同的告警配置。

选择合适的灵敏度仍然取决于数据。我们希望用户在保存配置之前就能看到配置会产生什么效果，因此编辑器包含了一个覆盖过去 24 小时的预览。图表显示了预期范围，并标记了本应发送通知的位置。当你调整灵敏度时，预览会更新，让你可以检查该告警是否能捕捉到你关心的尖峰，以及在原本正常的行为期间它会触发多少次。

这个初始实现旨在捕捉与近期行为的突然偏差。逐渐恶化的情况可能无法被检测到，因为基线会跟随它变化。持续存在的问题也可能成为预期范围的一部分，使告警在问题仍然存在时就被解决。每日和每周的周期性模式也需要不同的处理方式。我们打算在后续版本中解决这些限制，包括增加对季节性的支持。最后，我们仍然建议对持续性限制使用静态阈值告警，例如错误率必须保持在 1% 以下。

在 ClickStack 中扩展告警

在过去几个月中，我们看到 Managed ClickStack 获得了广泛采用，尤其是在寻求大规模可观测性最低单位成本的团队中。这些大型部署通常带来数万个现有告警。支持这些客户意味着确保告警框架能够跟上告警数量和评估频率的增长。

当客户拥有大量告警时，调度器评估所有告警所需的时间可能超过下一次计划运行之前的可用时间。之后的回填机制会检查任何被跳过的评估窗口，但这意味着问题可能被延迟发现。这些工作负载帮助我们确定了调度器需要改进的地方。

告警查询本身在 ClickHouse 中执行得很快。大部分时间花在加载告警配置和等待连接上。在评估甚至开始之前，调度器必须查找已保存的搜索、仪表板图块及其关联的数据源。这些查找是顺序运行的，而且常常为共享同一仪表板或数据源的告警重复获取相同的信息。

为了解决这个问题，我们改变了调度器，使其只加载到期告警的完整配置，并发执行这些查找，并在每次运行中重用共享的元数据。

写入结果也有类似的问题。每个告警都会产生单独的数据库写入，增加了不必要的写入。我们现在批量写入这些结果，减少了数据库操作次数。我们还增加了 ClickHouse 连接池并限制了评估队列，这样调度器就能控制它一次提交多少工作。

通知引入了另一个延迟来源。以前，评估会等待 webhook 投递完成，因此一个缓慢的通知端点可能会拖住调度器。为了解决这个问题，我们将投递移到了后台队列。给定告警的通知保持其顺序，而评估可以继续，无需等待 Slack 或其他目标响应。

这些更改增加了单个告警工作器可以处理的工作量。为了支持这一点，我们需要将工作分布到多个工作器上。这促使我们引入了告警评估的分片。

每个告警通过其 ID 的哈希被分配到一个分片。每个工作器使用相同的分配规则，并评估属于其分片的告警。在分片数量稳定的情况下，每个告警只有一个所有者。增加工作器会将告警重新分布到更多分片上，使评估容量能够随工作负载增长。分片数量会根据评估需求自动确定。

频率在这里很重要：每 30 秒检查一次的告警所需的评估次数是每分钟检查一次的两倍。当分片数量变化时，所有权会在工作器之间转移，回填会覆盖过渡期间错过的评估窗口。

有了这些改进，我们相信 Managed ClickStack 能够支持即使是最苛刻的告警工作负载。

大规模管理告警

有了大规模评估告警的基础设施后，我们还需要让这些集合便于管理。用户需要找到与其服务相关的告警，并了解哪些告警一直在触发。在过去几个月中，我们为告警 UI 发布了一系列增量改进，以支持这些工作流。

第一个要求是在集合增长时保持告警页面响应迅速。该页面现在以 100 个为一批获取告警，并且只渲染当前屏幕上可见的行。这使用户能够浏览大型集合，而无需一次性加载和显示所有告警。

当有数万个告警可供选择时，找到特定的告警也变得更加困难。告警现在有自己的名称和标签，你可以使用它们来独立于其所属的已保存搜索或仪表板图表来组织和搜索告警。你可以按状态、源类型，或告警使用的是静态阈值还是异常检测来筛选。还有一个用于筛选你创建的告警的过滤器。

例如，一个团队可以按服务和环境为其告警打标签，然后筛选列表，仅显示某个特定生产服务的触发中告警。筛选条件存储在 URL 中，因此该视图可以被收藏或与另一位团队成员共享。

找到告警后，其操作菜单提供编辑、打开底层源、导出到 Terraform 以及删除的入口。每一行还会显示所有已配置的通知渠道，使检查通知发送到哪里变得更加容易。如果你已经在调查某个事件，你可以确认该告警并将其静默 30 分钟到 24 小时不等的一段时间。

我们还扩展了单个告警可查看的信息。每个告警都有一个详情页，其图表上标注了告警触发和恢复的时间。图表旁有一条近期评估结果记录，提供历史记录，帮助用户了解某个告警是一直持续触发，还是在不同状态之间反复切换。

当你需要排查问题时，评估表提供了更多细节。它记录了观测值和触发告警的序列数量，以及查询和通知的持续时间。它还显示错误信息，以及错过的评估窗口是否已被回填。如果预期的通知没有到达，你可以检查是查询失败或超时，还是评估成功但通知投递失败。

接下来是什么

由于告警框架现在能够支持数万个告警，我们有信心承担更多团队通常通过 Grafana 等工具处理的复杂告警需求。

继我们宣布支持 PromQL 和 TimeSeries之后，对 Prometheus 指标进行告警是另一个优先事项。私有预览涵盖指标的存储和查询，包括在 ClickStack 中绘制图表。支持对 PromQL 查询进行告警是朝着让用户将其主要指标告警工作负载迁移到 Managed ClickStack 迈出的重要下一步。

季节性是对异常检测的下一步。一个服务在周一早上的正常行为可能与周末的行为大不相同。我们计划通过将数值与一天中对应时段或一周中对应日期的基线进行比较，来考虑这些重复出现的模式。我们还会缓存历史计算结果，以限制这些比较带来的额外查询成本。

更长远来看，我们将探索改进对噪声数据和低流量服务的检测、简化配置，并在连接遥测数据时自动创建初始异常告警。这可能包括在能够解决具体客户需求的地方使用机器学习技术。

请继续关注未来几个月的更多公告。