3. 历史数据基础：告警时间序列数据的采集、清洗与存储格式

告警降噪阈值策略的 A/B 测试，其核心假设是“历史告警行为能够预测未来模式”。因此，历史数据的质量直接决定了阈值验证的可信度。本章聚焦于如何从生产环境中可靠地采集、清洗并格式化存储告警时间序列数据，为后续的统计分析和策略模拟打下坚实基础。

3.1 告警时间序列的数据特征与采集源

告警数据本质上是一种带有时间戳、状态和属性的离散事件流。与连续型监控指标（如 CPU 使用率）不同，告警事件具有突发性、稀疏性和多维度标签的特点。常见的采集源包括：

3.2 数据清洗：从原始事件到可用时间序列

原始告警数据通常包含大量噪声、重复和格式不一致问题。清洗流程分为以下四个核心步骤：

1. 去重与合并（Deduplication & Merging）：同一告警规则在短时间内可能多次触发。需根据 alertname + instance + fingerprint 进行分组，合并重叠的告警区间，保留最早开始时间和最晚结束时间。
2. 时间戳对齐（Timestamp Alignment）：不同采集源的时间戳精度可能不同（秒级 vs 毫秒级）。统一转换为 Unix 时间戳（秒级），并处理时区偏移，确保所有数据在同一时间轴上。
3. 异常值过滤（Outlier Filtering）：剔除明显异常的数据点，例如：开始时间晚于结束时间、时间戳为未来时间、持续时间超过 30 天（通常为误报或系统故障）。
4. 标签标准化（Label Normalization）：统一标签键名（如 host 与 instance 统一为 entity），去除无意义的标签（如 alert_id 自增 ID），保留用于分组和聚合的维度。

3.3 存储格式：面向分析的时间序列表设计

清洗后的数据需要以适合分析查询的格式存储。推荐使用列式存储（如 Parquet）或时序数据库（如 ClickHouse、InfluxDB）。以下是一个通用的告警事件表结构设计：

-- 告警事件明细表 (alert_events)
CREATE TABLE alert_events (
    event_id        UInt64,          -- 全局唯一事件 ID
    rule_name       String,          -- 告警规则名称
    entity          String,          -- 告警对象（主机、服务、容器）
    severity        String,          -- 严重级别 (critical, warning, info)
    status          String,          -- 当前状态 (firing, resolved)
    start_ts        DateTime,        -- 告警开始时间
    end_ts          DateTime,        -- 告警结束时间（NULL 表示未恢复）
    duration_sec    UInt32,          -- 持续时间（秒），由 end_ts - start_ts 计算
    labels          Map(String, String), -- 其他标签键值对
    annotations     String,          -- 告警注释信息
    ingestion_ts    DateTime,        -- 数据写入时间
    partition_date  Date             -- 分区字段，按天分区
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(partition_date)
ORDER BY (rule_name, entity, start_ts);

3.4 数据管道架构：从采集到存储的完整链路

为了支撑 A/B 测试的反复回放与验证，数据管道需要具备高吞吐、低延迟和可回溯的特性。下图展示了推荐的告警数据采集与存储架构：

3.5 数据质量校验清单

在将数据用于 A/B 测试之前，建议执行以下校验，确保数据集的完整性和一致性：