AIOps 容量异常检测：趋势预测之外还要识别突变

AIOps 容量异常检测趋势预测之外还要识别突变一、容量问题不总是慢慢发生容量预测常常关注趋势磁盘每天增长多少QPS 每周上升多少Pod 数量是否接近上限。但生产系统里的容量风险不总是线性增长。一次批处理失控、日志级别误开、缓存击穿、队列消费停滞都可能让容量在短时间内突变。AIOps 容量检测既要看长期趋势也要识别短期突变。只做趋势预测会错过很多真正危险的容量事故。二、指标要按资源类型建模flowchart TD A[容量指标] -- B[CPU/内存] A -- C[磁盘/对象存储] A -- D[连接池] A -- E[队列积压] A -- F[配额限制] B -- G[异常检测] C -- G D -- G E -- G不同资源的异常模式不同。磁盘更适合看增长速度连接池更适合看占用率和等待时间队列要看 lag 和消费速度第三方配额要看剩余量和重置周期。容量检测不能只看单点指标。例如 CPU 不高但连接池等待很长说明瓶颈可能在下游磁盘占用不高但增长斜率突然变大也需要提前处理。三、异常检测要输出动作type CapacityAnomaly { resource: string service: string anomalyType: trend | spike | quota | stall confidence: number nextAction: string }报告里只写“磁盘异常增长”不够。更有用的是告诉运维下一步检查日志级别、清理临时文件、扩容卷、暂停任务还是联系业务确认流量。capacity_rules: disk_growth_spike: window_minutes: 30 growth_ratio: 3 action: check_log_volume queue_stall: lag_minutes: 15 action: check_consumer_health规则和模型可以结合。规则负责确定底线模型负责解释上下文和排序。四、预测要和变更日历联动容量异常很多时候和变更有关。新版本打开 debug 日志活动流量开始数据回填任务启动都会改变资源曲线。AIOps 系统应该把变更日历、任务计划和容量指标放在一起看。当检测到异常时还要判断是否处于可预期窗口。如果活动已知会让流量上涨告警内容就应该提示“符合预期但接近阈值”如果没有任何计划变更优先级就要提高。容量检测还要有“剩余时间”概念。磁盘 80% 不一定危险如果增长很慢可能还有两个月队列 lag 不高也不一定安全如果消费速率已经低于生产速率几分钟后就会爆。AIOps 报告应给出按当前速度估算的耗尽时间。capacity_prediction: disk_full_warning_hours: 24 queue_lag_warning_minutes: 15 quota_exhaust_warning_hours: 6 require_growth_rate: true对于容量建议也要展示约束条件。扩容磁盘可能需要停机增加消费者可能打穿下游提高配额可能要走采购。模型只建议“扩容”是不够的必须说明扩容的前提和副作用。最终容量异常检测要进入变更评审。每次大促、迁移、回填任务上线前都应该先看容量预测而不是等告警响起再补资源。五、总结AIOps 容量异常检测不能只做长期趋势预测还要识别突变、停滞、配额耗尽和下游瓶颈。容量报告最终要落到动作。能指导下一步处理的预测才真正对运维有价值。