应区分采集链路异常与nginx服务异常：抓取超时设为5s，p95耗时>3s持续2分钟触发延迟告警；up==0且多实例同时失败优先排查网络或prometheus自身；结合活跃连接突增、5xx率>5%、upstream 500错误率>10/3m等指标交叉验证根因；alertmanager中按job/instance分组合并告警，并抑制失联期间的业务指标告警。
配置 Prometheus 对 Nginx 的抓取超时与重试告警策略，关键不在调大 timeout 参数，而在于区分“采集链路异常”和“Nginx 服务异常”两类问题，并为它们设置不同响应逻辑。抓取失败本身不是故障信号，持续失败、伴随指标突变才是告警依据。
调整 Prometheus 抓取参数防误报
Prometheus 默认抓取超时是 10s，对 Nginx exporter 或 vts 模块的 /metrics 接口来说偏长——若后端 Nginx 已卡死，等待 10 秒才失败会拖慢整体采集节奏，还可能掩盖真实延迟问题。
- 在
prometheus.yml的 job 配置中显式设scrape_timeout: 5s，略高于 Nginx 指标接口正常响应时间（通常 - 搭配
scrape_interval: 15s，避免高频探测加重 Nginx 负载；若用 nginx-module-vts，建议不低于 10s - 不建议启用
sample_limit或target_limit，Nginx 指标量级稳定，限制反而导致关键指标丢失
识别真实采集失败并触发告警
单纯 “up{job="nginx"} == 0” 不够精准：可能是网络抖动、临时高负载或 exporter 进程卡住。需叠加状态与趋势判断。
- 定义告警规则，要求连续 3 次抓取失败：
count_over_time(up{job="nginx"} == 0[3m]) >= 3 - 补充延迟异常维度：当抓取耗时 P95 > 3s 且持续 2 分钟，说明指标接口响应恶化，非瞬时抖动：
histogram_quantile(0.95, sum(rate(prometheus_target_scrapes_duration_seconds_bucket{job="nginx"}[2m])) by (le)) > 3 - 避免单点误判：若多个 Nginx 实例同时触发 up==0，优先告警网络或 Prometheus 自身问题，而非某台 Nginx
关联 Nginx 服务层指标做根因告警
抓取失败只是表象。真正要告警的是 Nginx 本身已不可用或严重过载，这时需结合它暴露的核心指标交叉验证。
- 活跃连接数突增 + 抓取失败：可能是连接队列打满，
nginx_http_connections_active > 1000且 1m 内上涨 300% - 5xx 错误率飙升 + 抓取延迟升高：说明 upstream 失败引发 Nginx 响应变慢，
rate(nginx_http_requests_total{code=~"5.."}[2m]) / rate(nginx_http_requests_total[2m]) > 0.05 - upstream 失败次数持续增长：
rate(nginx_http_upstream_requests_total{upstream=~".*",status="500"}[3m]) > 10，表明后端大面积不可达
Alertmanager 中做分层收敛与通知
上述指标可能同时触发，但应归为同一事件处理，避免邮件刷屏。
- 在
alertmanager.yml中配置 grouping：按job和instance分组，把同一 Nginx 实例的 up=0、5xx 上升、连接数超限合并为一条告警 - 设置抑制规则：当
up == 0触发时，暂时抑制所有该实例的业务指标告警（如请求错误率），防止“失联期间乱报错” - 严重等级区分：up=0 持续 5 分钟标记为 critical，发送短信；仅延迟升高标记为 warning，仅发邮件
