云舟观测告警服务能力，智能护航业务安全-CSDN博客

本文链接：https://blog.csdn.net/ZVAyIVqt0UFji/article/details/145917028

在可观测性系统中，告警能力是保障业务系统稳定性和可靠性的重要支柱。通过及时发现业务系统中的异常或潜在风险，告警系统能够迅速通知管理员及运维人员，帮助其快速响应并采取修复或优化措施，从而有效防止问题升级，降低MTTR。本文将重点介绍360智汇云云舟观测产品中统一告警服务的架构设计与核心功能。

一、背景

1.1 告警服务的重要性

业务系统通常会重点确保系统的稳定运行，通过业务埋点、主动推送等方式采集监控数据，并以可视化形式展示。当用户发现监控数据出现异常时，会及时介入系统，定位问题并采取措施恢复，从而实现从“数据->人->行为”的完整闭环。然而，需要注意的是，要求高达 99% 的业务系统用户全天候 24 小时持续关注监控数据并不现实。在用户因工作、用餐、休息、下班或休假等原因未在线时，用户与监控数据之间难免会出现脱节。而告警服务能够在系统发生故障时及时通知用户，唤醒其对系统的干预能力，因此在监控体系中扮演着不可或缺的角色。

1.2 告警服务的痛点

在现代信息系统中，随着业务系统复杂性提升，告警系统以及系统用户经常会面临以下的问题和痛点。系统管理员和运维人员需要花费大量精力去处理告警，如果告警信息过多，运维人员可能无法及时响应关键告警，甚至被大量无效告警淹没，不仅影响工作效率和服务质量，还可能导致重要告警被忽视，导致严重故障。用一句话来概括，就是: 太多的告警就相当于没有告警。

因此，在可观测性体系中，设计一个高效的告警系统显得尤为重要。云舟观测产品基于海量业务数据的全方位业务场景设计研发了一套高效统一的告警系统。我们认为一个高效的告警系统应该是：及时通用、不漏报，不多报，报对人。

二、告警服务架构

数据采集：
数据是观测告警系统的基石，我们的监控数据来自于数万服务器、数十种云服务、各种业务埋点数据、以及用户上云服务等海量数据。采用自研的Arkit探针+开源Prometheus生态进行数据采集，并内置十几种开箱即用的采集器（如Exporters、Telegraf、Jmx、Prometheus、OpenTelemetry、脚本、日志、拨测、自定义等）。
数据存储：
云舟观测指标数据存储 Metric Store 基于开源时序存储进行二次研发，实现数据双写，定期老化删除历史数据，具备高可用性，并优化了读写性能。在 Metric Store 基础上，提供查询和分析功能（支持 WebUI、PromQL 语法）。
云舟观测针对日志、Trace 等日志类型数据，采用了360自研的Log Store数仓存储，实现存算分离，支持海量数据存储、实时数据入仓、实时数据分析、联邦查询等。在 Log Store 基础上，提供查询和分析功能（支持 SQL 语法）。
告警模块：
告警作为运维监控最后一公里，其产品功能和稳定性至关重要。虽然告警事件是监控系统产生的，但是监控系统通常不会着力解决告警事件的后续处理需求，因为监控系统的主要职责是收集、存储、展示监控数据。云舟观测开放用户在WEB端统一进行告警规则配置、告警策略配置、通知对象配置、告警屏蔽、告警回调、告警收敛、告警沉默、告警确认等。
事件中心：
告警事件中心是一个能够集中接收、处理和分析来自不同监控系统或应用的历史告警信息模块。具备历史告警明细检索、告警数统计、指标趋势分析、AI告警根因分析等。

三、告警核心能力

3.1 告警收敛

云舟观测告警平台每天会产生数以万计的告警，这些告警需要运维或开发人员进行分析、甄别优先级并处理故障。如果对这些告警不加收敛，每条异常都发送告警，势必会增大运维人员的工作压力，而且并非所有告警都需要且有必要发送给运维人员处理。因此，我们需要通过多种手段对告警进行收敛，以下从三个方面介绍如何进行告警收敛。

告警持续时长判定
为了减少偶发性、单次性波动或误报的告警，云舟观测支持用户配置告警持续时间，只有多次检测持续告警且持续时长大于等于配置的持续时间才会发送告警。持续时长的设置也能确保告警的准确性和可靠性。

需要特别说明的是，告警持续时长设置与告警检测周期、数据采集周期密切相关，共同影响告警的触发和发送时机，因此需要进行综合考虑和配置。

例如，假设 1 分钟采集一次主机 A 的 CPU 使用率指标，用户配置了告警规则：每 2 分钟检测一次 CPU 使用率，大于 90% 并且持续 3 分钟进行告警，09:00 开始检测。

（1）09:00 检测 CPU使用率 小于 90 %，不满足阈值，告警 状态 inactive
（2）09:02 检测 CPU使用率 大于 90 %，满足阈值，判断持续时长为 0（首次检测出告警，持续时长都是0），告警 状态由 inactive 置为 pending，并记录首次告警触发时间点（09:02）
（3）09:04 检测 CPU使用率 继续大于 90 %，满足阈值，判断持续时长为 2min（09:04 - 首次告警时间点 09:02），小于3min 持续时长条件，告警 状态继续为 pending
（4）09:06 检测 CPU使用率 继续大于 90 %，满足阈值，判断持续时长为 4min（09:06 - 首次告警时间点 09:02），大于3min 持续时长条件，告警 状态置为 firing，发出告警。

首次告警等待
当一个异常产生之后，我们不会立即发送告警，而是等待一段时间后再发送。这个等待时间一般可由系统自定义，若该值太大，会影响告警延迟；若太小，则不能有效提升告警合并效果。例如，首次告警等待时间为 5s，当一个服务下节点 1 出现 A 指标异常，5s 内节点 2 也出现了 A 指标异常，那么发送告警时节点 1 和节点 2 会被合并到一起发送告警通知。
告警间隔(沉默)
在告警没有恢复前，系统会根据告警间隔的配置每隔一段时间发送一条告警信息，防止用户未及时关注到重要的告警。告警间隔用于控制告警发送的频率。