nginx 做负载均衡、vector 采集分发日志的组合适用于中高流量场景，需统一由 nginx 记录 access/error 日志并规范字段，vector 通过 tags 区分日志流，用 remap 解析、按条件分流至 kafka/es/s3，避免耗时操作与单点瓶颈，并联动 nginx 的 keepalive、slow_start、consistent hash 等策略优化日志质量与链路追踪。
直接用 Nginx 做负载均衡，再让 Vector 采集日志并分发到不同后端（比如 Kafka、ES、S3），这种组合在中高流量场景下非常实用。关键是把 Nginx 的流量分发能力与 Vector 的轻量、低延迟、多协议输出能力结合起来，避免日志堆积、格式错乱或单点瓶颈。
明确日志来源与采集位置
Nginx 负载均衡层本身不处理业务逻辑，但它的 access_log 和 error_log 是真实请求流的“第一手镜像”。必须确保：
- 所有上游服务器（如应用节点）的响应日志统一由 Nginx 主动记录，而不是各节点自行写本地日志——否则无法反映真实转发路径和时延
- log_format 中至少包含 $upstream_addr、$upstream_response_time、$request_id，这些字段对链路追踪和故障定位至关重要
- access.log 和 error.log 分开存储，且权限设为 640，Vector 进程需有读取权限
Vector 配置要点：解析 + 分类 + 分发
Vector 不只是“搬运工”，它能实时解析、过滤、丰富字段，再按规则路由。典型配置逻辑如下：
- 输入（inputs）用 file 类型监听两个日志路径，通过 tags 区分 access / error 流
- 处理（transforms）阶段用 remap 解析 Nginx 日志：提取 IP 归属地、时间转 ISO8601 格式、状态码分类（2xx/4xx/5xx）、标记是否为 CDN 回源请求
- 输出（sinks）按 tag 和条件分流：4xx 日志 → Kafka topic=nginx_alerts；error.log 全量 → S3 归档桶；access.log 中 request_time > 2.0 的慢请求 → ES 索引 nginx-slow-log
规避常见性能陷阱
即使 Vector 很快，配置不当也会拖慢整个链路：
- 不要在 Vector 中做耗时操作，比如调用外部 HTTP 接口查 IP 归属——改用离线 GeoIP 数据库（如 maxmind db）+ lookup_table
- 避免将所有日志打到同一个 Kafka partition，应基于 $host 或 $upstream_addr 做 hash 分区，提升消费并行度
- 启用 Vector 的 internal_metrics，并监控 component_received_events_total 和 component_sent_events_total 差值，及时发现积压
与负载均衡策略联动优化
Nginx 的 upstream 配置可反向影响日志质量。例如：
- 开启 keepalive 32 并设置 proxy_http_version 1.1，减少连接重建，使 $request_time 更真实反映处理耗时
- 在 upstream 中配置 slow_start=30s，新节点上线后逐步导流，Vector 就不会突然收到某台机器爆发的错误日志洪峰
- 使用 hash $request_id consistent 实现会话保持，配合 Vector 中的 trace_id 提取，方便全链路日志聚合
