完善V2V产量监控系统

产量监控系统架流程：数据采集、存储、分析、告警、可视化

现有报警系统逻辑

检查爱奇艺生产环境中“拆条任务”在过去30小时内的数据，判断是否存在异常情况，并通过机器人发送报警通知。详细分解如下：

1. 数据查询：

   1. 查询过去31小时的数据，分为三部分：

      • enterRes：进入任务的数量（GroupByHourEnter）。

      • waitRes：等待任务的数量（GroupByHourWait）。

      • pubRes：发布任务的数量（GroupByHourPub）。

   2. 通过这些查询结果，构造一个时间序列，从当前时间往前推30小时，每小时一个节点。

2. 数据处理：

   1. 初始化stdCount列表，每个元素代表一小时的数据，默认计数为0。

   2. 根据查询结果填充stdCount，分别计算每小时的EnterCount、WaitCount和PubCount，并计算30小时的总数（sumEnter、sumWait、sumPub）。

3. 异常检测：

   1. 计算过去30小时的平均值（avgEnter、avgWait、avgPub）。

   2. 重点检查最近6小时的数据（checkNum = 6）：

      • 如果“识别拆条量”或“拆条完成量”或“拆条发布量”为0，标记为异常。

      • 如果“识别拆条量”比平均值低35%以上，标记为异常。

      • 如果“拆条完成量”比平均值低20%以上，标记为异常。

      • 和前一天同一时段对比，如果减少35%（识别量）或20%（完成量），也标记为异常。

4. 报警通知：

   1. 如果发现异常（flag > 0），通过机器人发送报警信息，包含具体的异常数据。

   2. 生成一个HTML报告，展示详细。

5. 收尾：

   1. 通过defer捕获异常，如果出错则发送错误通知。

\

问题

1. 瞬时异常容易触发误报：使用了简单均值作为比较基准，单次波动可能会导致异常判断。

   1. 滞后生产：算子处理不稳定，导致产量滞后增加

2. 未考虑趋势变化：没有考虑最近的增长或下降趋势，对中长期变化不敏感。

3. 未平滑时间序列：直接使用过去30小时数据，没有使用平滑方法来减少噪声影响。

\

初步优化

优化查询逻辑

细化不同 type_enum，区分不同来源

• 爱奇艺影视高光拆条 —— type_enum = 2,3

• 爱奇艺影视解说 —— type_enum = 6

• 乐视影视拆条 —— type_enum = 5

• 海外影视高光拆条 —— type_enum = 7,8

• 短剧拆条 —— type_enum = 0

• 短剧解说 —— type_enum = 4

\

报警规则判断

规则1：连续异常检测 —— 减少瞬时波动干扰

• 基准：近30h均值。

• (低于 30h均值 15% || 同比昨日同时间段减少 15%） && (持续 2 小时 || 6 小时内 3 次)

• 对 识别拆条数量 进行判断

• 对 拆条/发布质量 进行判断

  • 拆条质量 = 拆条完成量/识别拆条量

  • 发布质量 = 拆条发布量/拆条完成量

• 当数据恢复正常时，计数器清零，避免历史异常影响后续判断。

改进后的报警规则：

• 3小时汇报一次，重点检查最近6小时的数据（checkNum = 6）：

  • 如果“识别拆条量”或“拆条完成量”或“拆条发布量”为0，标记为异常。

  • 如果“识别拆条量” (当前小时产量 / 基准 < 75% || 和前一天同一时段对比减少25%)，且 (持续 2 小时 || 6 小时内 3 次)标记为异常。

  • 如果 拆条质量 和 发布质量 (当前小时质量 / 基准 < 80% 或者 和前一天同一时段对比减少20%)，且 (持续 2 小时 || 6 小时内 3 次)标记为异常。

\

结合异常趋势分析

当前逻辑是绝对数值判断（低于平均值一定比例就报警），可以改成趋势分析，如果下降趋势明显且持续，则触发报警。实现方式

• 计算过去 N 小时的 变化率（增/减幅）。

• 如果变化率连续下降 X% 以上才触发报警，而不是一次下降就报警。

\

报警机制智能

不同异常程度触发不同级别的告警（预警、严重告警）。

• 夜间发布质量不报警

• 低于阈值 15% → INFO（轻微波动）

• 低于阈值 25% → WARNING（需要关注）

• 低于阈值 35% → CRITICAL（严重问题）

• 如果 异常持续时间较长，则提升等级

  • INFO 级别持续 3 次 → 升级为 WARNING

  • WARNING 级别持续 4 次 → 升级为 CRITICAL

综上，改进后的报警规则：3小时汇报一次，重点检查最近6小时的数据（checkNum = 6）：方案一：

• 如果“识别拆条量”或“拆条完成量”或“拆条发布量”为0，标记为异常。

• 如果“识别拆条量” (当前小时产量 / 基准 < 75% || 和前一天同一时段对比减少25%)，且 (持续 2 小时 || 6 小时内 3 次)标记为异常。

• 如果 拆条质量 和 发布质量 (当前小时质量 / 基准 < 80% 或者 和前一天同一时段对比减少20%)，且 (持续 2 小时 || 6 小时内 3 次)标记为异常。

方案二：使用滑动窗口记录不同级别的报警次数：INFO、WARNING、CRITICAL。动态累积计数

• 如果“识别拆条量”或“拆条完成量”或“拆条发布量”为0，标记为 CRITICAL。

• 如果“识别拆条量” (当前小时产量 / 基准 < 75% || 和前一天同一时段对比减少25%)，标记为 WARNING

• 如果 拆条质量 和 发布质量 (当前小时质量 / 基准 < 80% 或者 和前一天同一时段对比减少20%)，标记为 WARNING

• WARNING 级别持续 2 次 || 6 小时内 3 次 → 升级为 CRITICAL\

如果需求简单，只需要快速发现异常，方案一 更直观易实现。

如果需要区分严重程度，并且希望控制报警频率，方案二 更有优势。

最后决定采用方案二。

前端页面展示

各监控线条分开统计，加上折线图展示\

再次优化

生产线配置参数说明

由于不同类型的生产线在速度和产量上存在差异，因此需对各产线进行参数化配置，纬度为每天产线的拆条识别、拆条完成、发布完成。目前考虑的关键参数包括：

1. Skip（跳过报警）：是否忽略整条产线的报警，适用于产线暂停或无需监控的情况。

2. RateThreshold（比例阈值）：相对于均值或同期数据的比值阈值，用于异常检测。

3. CountThreshold（总量阈值）：固定阈值，适用于设定了日生产上限（Day Limit）的产线。

4. WhitelistHours（白名单时段）：指定时间段内可忽略报警，适用于特殊生产安排。

举例分析：短剧拆条业务当前产出量极低，发布频率不稳定，且数据波动较大，导致异常检测的参考基数不足。因此，可考虑暂时Skip停用该业务的报警，以避免误报影响整体监控效果。

短剧拆条业务产量

爱奇艺拆条的发布从每天凌晨 5 点开始，到 9 点后因账号每日发布限制（Day Limit）进入 3 小时的骤降期。由于这一阶段的产量下降是预期行为，若不加以处理，可能会导致误报。针对这一情况，可以采用两种优化方案：

一是将 9:00 - 11:00 设为 WhitelistHours，在此时段不触发异常报警；

二是调整 CountThreshold，将其设定为 总产量的 80%，一旦达到该值，即可判断部分账号已触及 Day Limit，产量下降属于正常情况，从而避免误报。

这两种方案可以结合使用，确保在 正常骤降期 内不过度触发异常报警，同时仍能监控 异常的下降趋势，如提前骤降或持续低迷等情况。

爱奇艺拆条产量业务

异常判断顺序优化

考虑到 不同产线的生产节奏、数据稳定性以及特定业务的特殊性，需优化判断逻辑，确保异常检测的准确性和合理性。调整后的判断顺序如下：

1. 时间段过滤：

   1. 处理特定夜间发布时间段的特殊情况，避免非正常生产时间导致误报

   2. 适用白名单时段的特殊处理，允许特定时段的数据波动不触发报警

2. 总量阈值判断：

   1. 若已配置总量阈值且当前产量达到上限，则跳过异常检查，避免重复报警

3. 小时产量判断：

   1. 检查当前小时产量是否为 0，若为 0 表示生产异常

4. 比例偏差检查：

   1. 计算当前产量与历史均值的偏差，识别异常增长或下降情况

   2. 比对前一天同期数据，判断是否存在异常波动，避免短期波动影响报警策略

\

添加报警判断规则：动态阈值【暂未实现，先放个思路】

问题：当前的 “当前小时产量 / 全局均值” 计算方式容易受历史数据影响，导致在生产环境变化时存在滞后性，可能无法及时捕捉近期生产趋势，影响异常检测的准确性。优化方案：引入 动态阈值调整 机制，通过 实时生产速率 预测近期产量，并动态调整 CountThreshold（总量阈值），提高适应性。规则调整：

• 实时速率计算：基于当前生产速率，预测未来时段的产量。

• 动态调整总量阈值：结合预测产量，动态修改 CountThreshold，确保阈值随生产情况变化。

• 趋势偏差监控：若实际产量与预测产量偏差过大，触发预警，提升异常检测的敏感度。

• 历史权重优化：降低远期历史数据的影响，提高近期生产数据的权重，以增强对生产趋势变化的响应速度。\

Hireboot 消息发送策略优化

测试过程中发现，Hireboot 单次最多支持发送 2000 字符，超出部分将不会被发送。为确保消息完整传输，采用分批发送策略，并在两段消息之间增加 1 秒间隔，以避免发送速率过快导致的数据丢失或异常。\

最终效果

监控系统数据展示

群聊机器人监控通知

设计架构图

其他：模型/时间序列【暂不考虑】

1. Z-Score异常检测：

衡量数据点与均值的偏离程度：$Z=(X−μ)/σ$

• X：当前值

• μ：历史均值

• σ：标准差

  • 优点：计算简单，适合平稳数据。

  • 缺点：需要数据接近正态分布。

1. EWMA（指数加权移动平均）：

是平滑时间序列的有效方法，能够减少噪声对异常判断的影响：$$EWMAt​=αXt​+(1−α)EWMAt−$$

• 优点：处理噪音好，平滑波动，适用于每小时时间序列。

• 缺点：需要选择合适的alpha参数。

1. ARIMA：

   1. 优点：适合时间序列预测，对季节性数据有效。

   2. 缺点：可能需要模型训练，实时检测效果较差。

为什么不用EllipticEnvelopeEllipticEnvelope 主要通过拟合数据的椭圆包络来识别离群点，适用于数据服从高斯分布且相对连续的多维场景。对于按小时采集的计数型指标，存在以下几个问题：

1. 数据分布问题小时计数数据通常为离散数据，且可能不符合正态分布假设，尤其在存在周期性波动（如夜间低活跃）时，数据分布会受到影响，椭圆模型可能难以准确描述真实分布。

2. 周期性影响由于数据存在自然周期性波动，EllipticEnvelope 在静态模型下可能会把正常的周期性低值当作异常，从而导致误报。

3. 检测目标差异EllipticEnvelope 更擅长检测单个数据点的异常，而我们的的场景关注的是“持续异常”（连续多个小时表现异常），需要捕捉时间序列的趋势变化，静态模型在这方面较难表现出连续性判断。

产量数据特点：

• 数据特性：数据为计数型时间序列，存在周期性和随机波动。简单的均值比较容易受到瞬时异常干扰。

• 目标需求：需要捕捉持续性异常，而非偶发波动，以减少误报。

• 模型选择：复杂模型（如ARIMA、Isolation Forest或XGBoost）虽然能捕捉复杂模式，但需要较多数据、训练过程和额外运维，对于当前相对简单的场景来说反而增加系统复杂度；而基于规则的滑动窗口虽然简单，但容易设定不当。

• 综合考量：EWMA既能平滑数据，又能反映近期趋势变化，同时实现简单、资源消耗低，因此更适合本场景。

\