Nginx 不直接暴露 max_fails 触发次数，但可通过错误日志分析、OpenResty+Lua 实时统计或 Nginx Plus/Prometheus 获取该指标；核心是监控后端被标记为 down 的时刻与频次，并按业务容忍度设定告警策略。
Nginx 本身不直接暴露“max_fails 触发次数”这类运行时指标，但可通过日志、状态接口或 Lua 扩展捕获其实际触发行为，并联动外部系统实现实时告警。关键不是监控参数本身，而是监控它何时真正生效——即后端节点被标记为 down 的时刻和频次。
从错误日志中提取 max_fails 实际触发信号
Nginx 在某个 upstream server 因达到 `max_fails` 被主动摘除时，会在 error log 中记录明确线索： - 出现 `upstream timed out` 或 `connect() failed` 等失败日志（需已配置 `proxy_next_upstream` 启用对应错误） - 后续请求不再打到该节点，且同一时间窗口内同类错误集中爆发
操作建议：
- 在
http块中开启带上下文的错误日志：error_log /var/log/nginx/upstream_error.log warn; - 自定义
log_format包含$upstream_addr和$upstream_status，便于定位具体 server - 用定时脚本（如每 30 秒）扫描日志，统计单位时间内某 IP:PORT 的失败行数
例如：awk '/192.168.1.10:8080.*502|connect failed/ {c++} END{print c+0}' /var/log/nginx/upstream_error.log - 若 60 秒内失败 ≥3 次，且伴随该节点后续无流量，可判定为
max_fails已触发，立即推送告警
用 OpenResty + Lua 实时感知并上报
开源 Nginx 缺少运行时状态 API，OpenResty 可弥补这一短板：
- 使用
lua-resty-upstream-healthcheck模块监听健康检查结果 - 配合
lua_shared_dict统计每个 server 最近 60 秒内的失败时间戳（滑动窗口） - 在
access_by_lua_block中判断：若某 server 的失败事件在窗口内 ≥max_fails，则写入 Redis 或调用 webhook
示例逻辑：
- 每次 upstream 失败时，记录
ngx.shared.fails:set("server_192.168.1.10", os.time(), 60) - 定期遍历字典，对每个 key 统计未过期条目数
- 达阈值即触发告警，精度可达秒级
借助 Nginx Plus 或 Prometheus 补全指标链
若使用 Nginx Plus，直接启用 status 模块： - 访问 `/status` 接口可获取每个 upstream server 的 `fails` 当前值、`unavailable` 状态及上次 down 时间 - 用 Prometheus 抓取该接口，配合 `nginxplus_upstream_server_fails` 指标设置告警规则 例如：`rate(nginxplus_upstream_server_fails{upstream="backend"}[5m]) > 0.1`（平均每分钟触发超 0.1 次）
若用开源版 + nginx-prometheus-exporter：
- 需自行扩展 exporter，或通过 stub_status 解析
Active connections和Accepted conn差值间接推断异常波动 - 更稳妥方式是结合 access log 中
$upstream_addr变化频率：单请求多次切换 upstream，说明有节点频繁触达max_fails边界
告警策略必须匹配业务容忍度
触发告警不等于立刻响应故障，要避免噪音： - 对支付类接口：`max_fails=1 fail_timeout=10s` 触发即告警，需人工介入核查 - 对报表类服务：连续 3 分钟内每分钟都触发 `max_fails` 才告警，过滤单次慢请求干扰 - 告警内容应包含：触发节点 IP、最近 5 条失败日志摘要、当前 upstream 总节点数、fail_timeout 剩余时间
不复杂但容易忽略
