可通过Nginx的max_fails/fail_timeout机制结合日志分析、OpenResty/Lua状态监控、proxy_next_upstream重试统计及Prometheus指标采集，实现后端节点故障频次感知与告警。
可以通过 Nginx 的 max_fails 和 fail_timeout 机制结合外部监控手段，间接感知后端节点故障频次，并触发告警。Nginx 本身不直接暴露“触发次数”指标，但可通过日志、共享内存状态或上游健康检查模块提取关键信号。
利用 Nginx 日志统计失败连接频次
Nginx 在 upstream 失败时会记录 upstream connect failed 或 upstream timed out 等错误（取决于 error_log 级别）。开启详细错误日志后，可按时间窗口统计特定 upstream server 的失败行数：
- 在
http块中配置：error_log /var/log/nginx/upstream_error.log warn; - 使用
log_format添加 upstream 相关变量（如$upstream_addr,$upstream_status），便于结构化解析 - 用脚本（如 awk + grep）每分钟扫描日志，匹配含目标 server 地址且状态为 “502/503/504” 或错误信息含 “connect failed” 的行数
- 若单位时间内失败次数超过阈值（例如 5 次/分钟），调用 webhook 或写入 Prometheus Pushgateway 触发告警
借助 nginx-plus 或 openresty 获取实时 upstream 状态
开源版 Nginx 不提供运行时 upstream 状态 API，但以下方式可补足：
- 升级至 Nginx Plus：启用
status模块（stub_status增强版），访问/status可获取每个 upstream server 的fails计数器、unavailable状态、health_checks结果等 - 使用 OpenResty + lua-resty-upstream-healthcheck：通过 Lua 动态读取健康检查状态，在 handler 中判断
fails >= max_fails是否频繁发生，并上报到 Redis 或 Kafka - 配合
lua_shared_dict统计每台 server 的失败事件时间戳，实现滑动窗口计数（如最近 60 秒内 fail 达 3 次即告警）
基于 proxy_next_upstream 和自定义响应头反推故障频率
当配置了 proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504 时，Nginx 会在失败后尝试下一个节点。此时可在后端响应中注入唯一 trace-id，并在日志中记录重试次数：
- 添加
log_format包含$upstream_http_x_retry_count或自定义 header（需后端配合返回） - 统计单个请求链路中
upstream_addr切换次数，高频切换说明某节点反复触达max_fails边界 - 结合 access log 中的
$request_time和$upstream_response_time，识别因超时导致的连续失败场景
集成 Prometheus + Alertmanager 实现闭环告警
将上述任一数据源接入可观测体系：
- 用 nginx-lua-prometheus 导出自定义指标（如
nginx_upstream_server_failures_total{server="10.0.1.10:8080"}） - PromQL 示例：统计过去 5 分钟每台 server 的失败增量 > 10 次 →
rate(nginx_upstream_server_failures_total[5m]) > 10 - 配置 Alertmanager 路由规则，按 service 标签分派给不同值班组，支持静默、抑制与企业微信/钉钉通知
- 告警内容应包含：触发 server、失败速率、最近三次失败时间、当前是否已标记 unavailable
