网关

网关收集器部署模式包括应用程序（或其他收集器）将遥测信号发送到由一个或多个作为独立服务运行的收集器实例提供的单个 OTLP 端点，通常是每个集群、每个数据中心或每个地区。

在一般情况下，您可以使用现成的负载均衡器来分配收集器之间的负载：

对于需要在特定收集器中处理遥测数据的用例，您可以使用两层设置，第一层是配置了Trace ID/Service 名称感知负载平衡导出器的收集器，并且第二层是用于处理扩展的收集器。例如，当使用尾采样处理器时，您需要使用负载平衡导出器，以便所有属于给定追踪的跨度都到达应用了尾采样策略的同一个收集器实例。

让我们来看一个使用负载平衡导出器的示例：

1. 在应用程序中，SDK 被配置为将 OTLP 数据发送到一个中心位置。
2. 配置了使用负载平衡导出器的收集器，用于将信号分发给一组收集器。
3. 收集器被配置为将遥测数据发送到一个或多个后端。

示例

NGINX 作为“现成的”负载均衡器

假设您配置了三个收集器（collector1、collector2 和 collector3），并希望使用 NGINX 在它们之间实现负载均衡，您可以使用以下配置：

server {
    listen 4317 http2;
    server_name _;

    location / {
            grpc_pass      grpc://collector4317;
            grpc_next_upstream     error timeout invalid_header http_500;
            grpc_connect_timeout   2;
            grpc_set_header        Host            $host;
            grpc_set_header        X-Real-IP       $remote_addr;
            grpc_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

server {
    listen 4318;
    server_name _;

    location / {
            proxy_pass      http://collector4318;
            proxy_redirect  off;
            proxy_next_upstream     error timeout invalid_header http_500;
            proxy_connect_timeout   2;
            proxy_set_header        Host            $host;
            proxy_set_header        X-Real-IP       $remote_addr;
            proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

upstream collector4317 {
    server collector1:4317;
    server collector2:4317;
}

upstream collector4318 {
    server collector1:4318;
    server collector2:4318;
}

负载平衡导出器

为了对集中式收集器部署模式进行具体的示例，首先我们需要更详细地了解负载平衡导出器。它有两个主要的配置字段：

• resolver，用于确定下游收集器（或后端）的位置。如果在此处使用 static 子键，您将必须手动枚举收集器的URL。另一个受支持的解析器是 DNS 解析器，它将定期检查更新并解析 IP 地址。对于此解析器类型，hostname 子键指定要查询以获取 IP 地址列表的主机名。
• 使用 routing_key 字段，您可以告诉负载平衡导出器将跨度路由到特定的下游收集器。如果将此字段设置为 traceID（默认值），则负载平衡导出器将根据它们的 traceID 导出跨度。否则，如果将 service 用作 routing_key 的值，它将根据服务名称导出跨度，这在使用跨度度量连接器时非常有用，以便所有属于某个服务的跨度都发送到同一个下游收集器进行度量收集，从而保证准确的聚合。

配置用于服务 OTLP 端点的第一层收集器如下所示：

• Static
• DNS
• 带服务的 DNS

receivers:
  otlp:
    protocols:
      grpc:

exporters:
  loadbalancing:
    protocol:
      otlp:
        tls:
          insecure: true
    resolver:
      static:
        hostnames:
          - collector-1.example.com:4317
          - collector-2.example.com:5317
          - collector-3.example.com

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [loadbalancing]

receivers:
  otlp:
    protocols:
      grpc:

exporters:
  loadbalancing:
    protocol:
      otlp:
        insecure: true
    resolver:
      dns:
        hostname: collectors.example.com

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [loadbalancing]

receivers:
  otlp:
    protocols:
      grpc:

exporters:
  loadbalancing:
    routing_key: service
    protocol:
      otlp:
        insecure: true
    resolver:
      dns:
        hostname: collectors.example.com
        port: 5317

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [loadbalancing]

负载平衡导出器会生成包括 otelcol_loadbalancer_num_backends 和 otelcol_loadbalancer_backend_latency 在内的指标，您可以用于监视 OTLP 端点收集器的健康状况和性能。

权衡

优点：

• 分离关注点，例如集中管理的凭据
• 集中策略管理（例如，过滤某些日志或采样）

缺点：

• 需要维护的额外事物，并且可能会发生故障（复杂性）
• 级联收集器会添加延迟
• 整体资源使用更高（成本）