关键在于打通全链路观测能力，采集请求（RPS、成功率、错误率、响应时间）、连接（活跃数、CPS、SSL耗时）、后端健康（状态、失败计数、权重生效值）、资源（CPU、内存、文件描述符）四类指标，并通过原生exporter统一接入Prometheus+Alertmanager+Grafana实现可归因、可分层、可告警的轻量闭环。
负载均衡接入监控系统，关键不是“连上就行”，而是让指标可归因、可分层、可告警。重点在于打通从请求入口到后端节点的全链路观测能力，避免只看到“流量进来了”，却不知道“发给了谁、谁慢了、谁挂了”。
明确要采集的四类核心指标
- 请求维度：每秒请求数（RPS）、成功率（2xx/3xx占比）、错误率（5xx/超时占比）、响应时间（TTFB、upstream_response_time、P90/P95）
- 连接维度：活跃连接数、新建连接速率（CPS）、最大连接使用率、SSL握手耗时（若启用TLS卸载）
- 后端健康维度：各 upstream server 状态（up/down）、失败计数、健康检查结果（HTTP 200 / TCP connect / 自定义探针）、权重实际生效值
- 资源维度：负载均衡进程 CPU 和内存占用、文件描述符使用率（尤其 Nginx/HAProxy 易受此限制）、日志写入延迟（影响故障回溯）
按组件启用原生指标暴露能力
Nginx 推荐组合使用：
- 开启
stub_status获取基础连接状态（需配置location /nginx_status） - 集成
nginx-module-vts暴露结构化 JSON 接口（含 upstream 级别 requestCounter、respCode、response_time_msec） - 添加自定义日志格式，记录
$upstream_addr $upstream_response_time $upstream_status $request_time，用于离线分析或补采
HAProxy 直接启用内置能力：
- 配置
stats uri /haproxy?stats并设访问控制，供人工核查 - 在 global 或 defaults 段添加
stats prometheus-exporter（2.2+ 版本），通过/metrics输出标准 Prometheus 格式指标
Keepalived 本身无 HTTP 接口，必须借助外部 exporter：
- 部署
keepalived_exporter，它通过读取/proc/vrrp或 vrrp stats socket 获取 VIP 状态、主备切换事件、实例存活情况 - 配合
vrrp_script脚本输出业务级健康信号（如检查本地 Nginx 是否响应），再由 exporter 抓取
统一采集与数据对齐要点
- Prometheus 的
scrape_interval必须 ≤ 健康检查间隔（例如健康检查 3 秒一次，scrape 至少设为 5s），否则会漏掉瞬时抖动 - 所有 exporter 应部署在负载均衡器本机或同机房低延迟网络内，避免跨区域采集引入延迟失真
- 在 Prometheus 中为每个 job 设置
relabel_configs，注入环境标签（如env=prod,cluster=web），便于后续按业务维度聚合 - Grafana 仪表盘中必须包含“后端偏差热力图”：用
sum by (upstream) (rate(nginx_vts_upstream_request_counter_total[5m])) / sum(rate(nginx_vts_upstream_request_counter_total[5m]))计算各节点流量占比，比单纯看“是否 up”更能发现权重错配或自动剔除异常
不依赖日志的轻量闭环建议
- 用 Blackbox Exporter 主动探测 LB VIP 的 HTTP 健康端点，验证对外服务能力是否可达（独立于内部指标）
- 对关键 upstream 设置
check interval=5 rise=2 fall=3 timeout=1（需 nginx_upstream_check_module），并将探测结果同步到监控视图 - Alertmanager 告警规则应区分层级：底层资源（CPU > 90%）、连接瓶颈（fd_used_percent > 95%）、业务异常（5xx_rate{job="nginx"} > 1% for 2m）、后端失效（upstream_fails_total > 0 for 5m）
本质上，负载均衡不是监控的终点，而是可观测性的枢纽。它的指标价值，在于把“不可见的转发决策”变成“可量化、可对比、可定位”的数据流。
