静态阈值适用于磁盘使用率（85%）、CPU平均使用率（80%–90%，配合for: 5m）和主机存活状态（up == 0）等稳定底层资源指标；动态告警则适配请求延迟、内存波动等业务类指标，通过移动平均+偏移、均值+标准差或AI时序模型实现智能适配。
静态阈值适合稳定、可预测的指标，动态告警则应对周期性或基线漂移的场景。两者不是非此即彼，而是按指标特性分层使用：资源类（如磁盘空间）用静态，业务类（如请求延迟、内存波动）优先考虑动态。
哪些指标适合静态阈值
静态阈值配置简单、响应明确，适用于变化平缓、业务影响清晰的底层资源指标：
- 磁盘使用率：行业通用阈值为85%，预留15%空间用于日志写入和系统临时操作；若为只读挂载或归档盘，可放宽至95%。
-
CPU平均使用率：物理机或稳定服务建议设为80%–90%；需结合
for: 5m避免毛刺触发，例如：avg by(instance)(1 - rate(node_cpu_seconds_total{mode="idle"}[5m])) > 0.85 for: 5m。 -
主机存活状态：直接用
up == 0判断Exporter失联，配合for: 1m防瞬断，无需复杂计算。
动态告警怎么落地更可靠
动态告警不是“全自动免运维”，而是用数据规律替代经验拍板。关键在于选对算法+限定适用范围：
-
移动平均+偏移：适合有强周期性的指标，比如每小时整点批量任务导致的CPU尖峰。PromQL示例：
rate(http_requests_total[5m]) > (avg_over_time(rate(http_requests_total[7d])[1h:]) offset 1w) * 1.8，即对比上周同时间段均值的1.8倍。 -
均值+标准差：适合短期波动大但长期收敛的指标，如容器内存使用量。公式为
avg + 2 × stddev，对应PromQL：container_memory_usage_bytes > (avg_over_time(container_memory_usage_bytes[1h]) + 2 * stddev_over_time(container_memory_usage_bytes[1h]))。 - AI时序模型（如Prophet）：需额外部署训练服务，适合核心业务链路（如支付成功率、下单延迟）。它能识别节假日、促销等异常模式，但要求至少7天以上连续高质量历史数据。
静态与动态共存的配置技巧
一个告警组里可以混合多种规则，靠标签和路由分流，避免一刀切：
- 同一指标可设两级告警：静态阈值触发P1级预警（如磁盘>85%），动态阈值触发P0级中断（如磁盘增长速率突增3倍，预示日志爆炸）。
- 用
labels打标区分来源：threshold_type: "static"或threshold_type: "prophet"，便于Alertmanager按类型做静默或升级处理。 - 动态规则必须配
for——建议不低于3分钟，因为模型输出本身有滞后性；静态规则可更短（如1–2分钟），响应更快。
别忽略的三个执行细节
再好的策略，落地时卡在细节上就前功尽弃：
-
规则重载要生效：修改
alert.rules.yml后，必须调用curl -XPOST http://prometheus:9090/-/reload，或启动时加--web.enable-lifecycle参数。 -
时间窗口要对齐：动态计算中
[1h]、[7d]等区间必须覆盖完整周期，避免因采集延迟导致空值干扰均值计算。 -
避免跨集群误用：K8s中不同命名空间的Pod资源行为差异大，动态阈值不能全局复用，应按
namespace或service维度分别建模。
