如何利用nginx日志做负载均衡 - 问答

总体思路

Nginx 的负载均衡由反向代理与 upstream 模块完成，日志本身不负责分发请求。正确做法是：在日志中输出足够多的字段（如 $upstream_addr、$upstream_response_time、$request_time 等），用日志分析来观察流量与后端性能，再据此选择合适的负载均衡策略（如 least_conn、ip_hash、加权轮询）并调整权重、摘除异常节点，实现“用日志驱动优化”。

步骤一输出可观测的负载均衡日志

在 http 块定义包含上游信息的日志格式，并在 server/location 中按需启用；若涉及四层转发（TCP/UDP），在 stream 块中同样可输出上游与连接时延字段。
推荐字段说明：
- $upstream_addr：实际处理请求的 upstream 主机:端口
- $upstream_response_time：上游响应耗时（秒）
- $request_time：完整请求耗时（秒）
- $status / $upstream_status：HTTP 状态（含上游）
- 传输层可选：$upstream_connect_time、$session_time（stream 模块）

示例配置

http {
  # 带上游指标的访问日志
  log_format lb '$remote_addr - $remote_user [$time_local] '
                '"$request" $status $body_bytes_sent '
                '"$http_referer" "$http_user_agent" '
                '"$http_x_forwarded_for" '
                'upstream=$upstream_addr '
                'rt=$request_time u_rt=$upstream_response_time '
                'u_status=$upstream_status';

  access_log /var/log/nginx/access_lb.log lb;

  upstream backend {
    least_conn;                 # 动态策略示例：最少连接
    server 10.0.1.11:8080 weight=3 max_fails=2 fail_timeout=30s;
    server 10.0.1.12:8080 weight=1 max_fails=2 fail_timeout=30s;
    server 10.0.1.13:8080 backup;
  }

  server {
    listen 80;
    location / {
      proxy_pass http://backend;
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
  }
}

# 四层转发（如 TCP）日志示例
stream {
  log_format stream_lb_json escape=json
    '{'
    '"timestamp":"$time_iso8601",'
    '"remote_addr":"$remote_addr",'
    '"protocol":"$protocol",'
    '"status":"$status",'
    '"bytes_sent":"$bytes_sent",'
    '"bytes_received":"$bytes_received",'
    '"session_time":"$session_time",'
    '"upstream_addr":"$upstream_addr",'
    '"upstream_connect_time":"$upstream_connect_time"'
    '}';

  access_log /var/log/nginx/stream_access.log stream_lb_json;

  upstream graylog_servers {
    server 10.10.253.101:9000;
    server 10.10.253.102:9000 backup;
    server 10.10.253.103:9000 backup;
  }

  server {
    listen 9000;
    proxy_pass graylog_servers;
  }
}

要点：

通过 log_format 输出 upstream 地址与耗时，才能判断各后端负载与性能差异。
在 upstream 中使用 least_conn / ip_hash / 加权轮询 等策略，日志用于验证策略是否生效与是否需要调整。

步骤二用日志分析评估与决策

目标：从日志中快速洞察流量分布、错误率、慢请求与后端健康度，从而决定“是否调整权重、切换策略、临时摘除节点”。
常用命令示例（假设使用上节的空格分隔日志；JSON 日志请用 jq）：
- 统计各后端命中次数
  - awk ‘{print $NF}’ access_lb.log | sort | uniq -c | sort -nr
- Top 10 客户端 IP
  - awk ‘{print $1}’ access_lb.log | sort | uniq -c | sort -nr | head
- 5xx 错误比例
  - awk ‘$9 ~ /^5/ {cnt++;} END {print “5xx_ratio=” cnt/NR}’
- 平均响应时间与 P95（按上游维度）
  - awk ‘{sum+=$13; count++; vals[NR]=$13} END {asort(vals); p95=vals[int(NR*0.95)]; print “avg=”$sum/count, "p95="p95}’ access_lb.log
- 慢请求 TopN（例如 >1s）
  - awk ‘$13 > 1 {print $0}’ access_lb.log | sort -k13 -nr | head
可视化与告警：将日志送入 ELK/EFK（Elasticsearch+Logstash/Fluentd+Kibana） 或 GrayLog，配置面板与阈值告警，持续观测 upstream 响应时间分布、错误率、各后端 QPS/连接数 等指标。

步骤三基于日志洞察进行负载均衡优化

何时调整
- 某后端 P95/错误率 明显高于同组：降低其 weight，必要时临时摘除（max_fails/fail_timeout 触发也会自动隔离）。
- 请求多为长连接或会话保持敏感：优先 ip_hash 或一致性哈希，减少会话漂移。
- 请求时长差异大、连接占用不均衡：使用 least_conn 或提高短任务后端权重，缩短排队与排队时间。
变更方式
- 动态调权：修改 upstream 的 weight，执行 nginx -s reload（零停机）。
- 摘除/恢复：临时注释节点或降低权重；故障恢复后恢复原配置并 reload。
闭环验证
- 变更后在日志面板观察：目标后端的 QPS、rt、5xx 是否按预期改善，确认无异常回退再固化配置。

步骤四在容器平台的落地

Kubernetes 中常用 Nginx Ingress Controller 作为入口，结合 Fluentd/Elasticsearch/Kibana 收集与分析访问日志，按命名空间/服务/路由维度观测与优化负载均衡效果。
实践要点
- 启用 Ingress Controller 访问日志，输出到 /var/log/nginx/access.log。
- 部署 Fluentd DaemonSet 采集日志并发送至 Elasticsearch，在 Kibana 建立指标面板与阈值告警（如 5xx、P95、各后端命中占比）。

0 赞

0 踩