nginx开源版可通过第三方模块实现语义级健康检查、状态页暴露、精细化日志采集及prometheus+告警闭环。需配置nginx_upstream_check_module、vhost_traffic_status_display或stub_status+自定义日志，结合$upstream_status和$upstream_response_time字段，设定rise/fall阈值与告警规则，确保健康检查路径真实反映业务可用性。
要让 Nginx 负载均衡真正“看得见”后端健康状况，不能只靠连接通断，得结合主动探测、日志指标和外部告警闭环——开源版完全能做到，关键在配置逻辑是否闭环。
启用主动健康检查（非连接级，是语义级）
Nginx 开源版不支持 health_check 指令（Plus 专属），但可通过第三方模块实现更精准的判断：
- 推荐使用
nginx_upstream_check_module（淘宝开源，OpenResty 默认集成），它能定期发 HTTP 请求到/health或/actuator/health等真实状态接口 - 配置中必须指定
check_http_send和check_http_expect_alive，例如只把2xx和3xx视为健康，避免将503或404误判为可用 -
rise=2 fall=3是合理起点：连续 2 次成功才恢复服务，连续 3 次失败才下线，兼顾灵敏与稳定
暴露可读的上游状态页
运维和脚本需要统一入口获取实时状态，不必依赖商业模块：
- 用
vhost_traffic_status_display（来自nginx-module-vts）可直接渲染 HTML 表格，显示每个 server 的active、fails、down及最近响应码 - 若不想加模块，复用原生
stub_status+ 自定义日志格式也能间接推断：开启stub_status查活跃连接趋势，再结合 access.log 中的$upstream_status和$upstream_response_time字段做聚合分析 - 访问路径建议设为
/status/upstream，并严格限制 IP 白名单（如仅允许内网监控系统访问）
从日志提取关键性能指标
每条请求日志都是诊断线索，只需显式记录上游细节：
- 在
http块中定义日志格式：log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent $upstream_response_time $upstream_addr $upstream_status'; -
$upstream_response_time是毫秒级真实耗时（含小数），可用于计算 P95/P99 延迟；$upstream_status能识别后端返回的 500、502、504 等错误码 - 配合
awk或nginxlog-exporter推送至 Prometheus，就能按后端节点维度统计错误率、平均延迟、超时次数
对接告警系统形成闭环
监控数据本身没有价值，触发动作才有意义：
- 在 Prometheus 中设置规则：例如
rate(nginx_upstream_request_seconds_sum{upstream="app_backend"}[5m]) / rate(nginx_upstream_request_seconds_count{upstream="app_backend"}[5m]) > 2表示平均延迟超 2 秒 - 对
upstream_status中 5xx 出现频率设阈值，或当某节点fails持续上升时触发告警 - 告警通知建议接入企业微信/钉钉机器人，附带直接跳转链接（如
http://nginx-host/status/upstream），缩短故障定位时间
不复杂但容易忽略：健康检查路径必须是应用真正校验业务可用性的接口，而不是只返回 200 的假心跳；日志字段没开启就等于丢了最基础的可观测性。
