使用Nginx实现Pinpoint Collector的负载均衡方案

背景介绍

在分布式追踪系统Pinpoint的部署架构中，Collector组件负责接收来自Agent的数据并进行处理。随着业务规模的增长，单个Collector节点可能无法承受高并发的数据上报压力，这时就需要通过负载均衡技术将请求分发到多个Collector节点上。

方案概述

本文介绍如何使用Nginx的gRPC模块(ngx_http_grpc_module)和HTTP/2模块(ngx_http_v2_module)来实现Pinpoint Collector的负载均衡。该方案能够有效分配Agent上报的三种数据类型(Agent数据、统计数据和Span数据)到不同的Collector节点上。

核心配置详解

1. 基础日志格式配置

首先在Nginx的主配置文件中定义gRPC请求的日志格式，便于后续监控和分析：

http {
    log_format grpc_json escape=json '{"timestamp":"$time_iso8601","client":"$remote_addr","uri":"$uri","http-status":$status,"upstream":"$upstream_addr","rx-bytes":$request_length,"tx-bytes":$bytes_sent}';
}

这种JSON格式的日志记录包含了请求时间、客户端IP、请求URI、HTTP状态码、上游服务器地址以及收发字节数等关键信息。

2. 三种数据类型的负载均衡配置

Pinpoint Agent会向Collector发送三种不同类型的数据，分别对应不同的端口：

• Agent数据(9991端口)
• 统计数据(9992端口)
• Span数据(9993端口)

为每种数据类型创建独立的Nginx配置：

Agent数据配置(/etc/nginx/sites-enabled/ppc-agent.conf)

upstream agent {
    server col1:9991 max_fails=3 fail_timeout=5s;
    server col2:9991 max_fails=3 fail_timeout=5s;
    server col3:9991 max_fails=3 fail_timeout=5s;
    ip_hash;
    keepalive 1024;
}

server {
    listen 0.0.0.0:9991 http2;
    access_log /var/log/ppc-agent-access.log grpc_json;

    include snippets/grpc-pass.conf;
    include snippets/grpc-error.conf;

    location / {
        grpc_pass grpc://agent;
    }
}

统计数据配置(/etc/nginx/sites-enabled/ppc-stat.conf)

upstream stat {
    server col1:9992 max_fails=3 fail_timeout=5s;
    server col2:9992 max_fails=3 fail_timeout=5s;
    server col3:9992 max_fails=3 fail_timeout=5s;
    ip_hash;
    keepalive 1024;
}

server {
    listen 0.0.0.0:9992 http2;
    access_log /var/log/ppc-stat-access.log grpc_json;

    include snippets/grpc-pass.conf;
    include snippets/grpc-error.conf;

    location / {
        grpc_pass grpc://stat;
    }
}

Span数据配置(/etc/nginx/sites-enabled/ppc-span.conf)

upstream span {
    server col1:9993 max_fails=3 fail_timeout=5s;
    server col2:9993 max_fails=3 fail_timeout=5s;
    server col3:9993 max_fails=3 fail_timeout=5s;
    ip_hash;
    keepalive 1024;
}

server {
    listen 0.0.0.0:9993 http2;
    include snippets/grpc-pass.conf;
    include snippets/grpc-error.conf;

    location / {
        grpc_pass grpc://span;
    }
}

3. gRPC专用配置

连接参数配置(/etc/nginx/snippets/grpc-pass.conf)

grpc_connect_timeout 2s;
grpc_buffer_size 8k;
grpc_next_upstream_timeout 3s;
grpc_next_upstream_tries 10;
grpc_read_timeout 60s;
grpc_send_timeout 60s;
grpc_socket_keepalive on;

这些参数控制了gRPC连接的各种超时和缓冲区设置，确保在高并发情况下的稳定性和性能。

错误处理配置(/etc/nginx/snippets/grpc-error.conf)

error_page 400 = @grpc_internal;
error_page 401 = @grpc_unauthenticated;
error_page 403 = @grpc_permission_denied;
error_page 404 = @grpc_unimplemented;
error_page 429 = @grpc_unavailable;
error_page 502 = @grpc_unavailable;
error_page 503 = @grpc_unavailable;
error_page 504 = @grpc_unavailable;

error_page 405 = @grpc_internal;
error_page 408 = @grpc_deadline_exceeded;
error_page 413 = @grpc_resource_exhausted;
error_page 414 = @grpc_resource_exhausted;
error_page 415 = @grpc_internal;
error_page 426 = @grpc_internal;
error_page 495 = @grpc_unauthenticated;
error_page 496 = @grpc_unauthenticated;
error_page 497 = @grpc_internal;
error_page 500 = @grpc_internal;
error_page 501 = @grpc_internal;

location @grpc_deadline_exceeded {
    add_header grpc-status 4;
    add_header grpc-message 'deadline exceeded';
    return 204;
}

location @grpc_permission_denied {
    add_header grpc-status 7;
    add_header grpc-message 'permission denied';
    return 204;
}

location @grpc_resource_exhausted {
    add_header grpc-status 8;
    add_header grpc-message 'resource exhausted';
    return 204;
}

location @grpc_unimplemented {
    add_header grpc-status 12;
    add_header grpc-message unimplemented;
    return 204;
}

location @grpc_internal {
    add_header grpc-status 13;
    add_header grpc-message 'internal error';
    return 204;
}

location @grpc_unavailable {
    add_header grpc-status 14;
    add_header grpc-message unavailable;
    return 204;
}

location @grpc_unauthenticated {
    add_header grpc-status 16;
    add_header grpc-message unauthenticated;
    return 204;
}

default_type application/grpc;

这部分配置实现了HTTP状态码到gRPC状态码的映射，确保客户端能够正确理解服务端返回的错误信息。

关键技术点解析

1. HTTP/2支持：必须启用HTTP/2协议(listen指令中的http2参数)，因为gRPC构建在HTTP/2协议之上。

2. 会话保持：使用ip_hash负载均衡算法确保来自同一客户端的请求总是被转发到同一后端服务器，这对于Pinpoint的数据一致性非常重要。

3. 连接复用：keepalive 1024指令允许保持大量后端连接，减少频繁建立连接的开销。

4. 健康检查：max_fails和fail_timeout参数实现了简单的健康检查机制，自动将故障节点从负载均衡池中移除。

5. gRPC超时控制：通过grpc_connect_timeout、grpc_read_timeout等参数精细控制各个阶段的超时行为。

版本兼容性注意事项

在使用此方案时，需要注意Nginx版本的兼容性问题：

• Ubuntu 22.04默认提供的Nginx 1.18.0版本可能会导致Agent报告"INTERNAL: RST_STREAM closed stream. HTTP/2 error code: PROTOCOL_ERROR"错误
• 推荐使用以下版本：
  • Ubuntu 24.04 LTS中的Nginx 1.24
  • Debian bookworm中的Nginx 1.22.1

性能优化建议

1. 根据实际负载情况调整keepalive连接数
2. 监控grpc_buffer_size的使用情况，适当调整缓冲区大小
3. 根据网络延迟情况优化各种超时参数
4. 考虑使用Nginx的共享内存区域来存储上游服务器状态，提高性能

总结

通过Nginx实现Pinpoint Collector的负载均衡，可以有效提高系统的可扩展性和可用性。本文提供的配置方案经过实践验证，能够稳定处理Pinpoint Agent上报的各种数据类型。在实际部署时，可以根据具体环境调整相关参数，以达到最佳性能。