Gateway

网关 Collector 部署模式由应用程序或其他 Collector 组成，它们将遥测信号发送到单个 OTLP 端点。此端点由一个或多个作为独立服务运行的 Collector 实例提供，例如，在 Kubernetes 部署中。通常，每个集群、每个数据中心或每个区域提供一个端点。

通常，您可以使用开箱即用的负载均衡器来分发 Collector 之间的负载

对于必须在特定 Collector 中处理遥测数据的用例，请使用两层设置。第一层 Collector 具有一个配置了 Trace ID/service-name-aware load-balancing exporter 的管道。在第二层，每个 Collector 接收并处理可以专门定向到它的遥测数据。例如，您可以在第一层中使用负载均衡导出器将数据发送到配置了 尾部采样导出器 的第二层 Collector，以便给定跟踪的所有 span 到达应用了尾部采样策略的同一 Collector 实例。

下图显示了使用负载均衡导出器的此设置

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

示例

以下示例显示了如何使用常见组件配置网关 Collector。

NGINX 作为“开箱即用”的负载均衡器

假设您配置了三个 Collector（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;
    server collector3:4317;
}

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

负载均衡导出器

对于集中式 Collector 部署模式的具体示例，首先看一下负载均衡导出器。它有两个主要配置字段

• resolver 确定在哪里找到下游 Collector 或后端。如果在此处使用 static 子键，则必须手动列出 Collector URL。支持的另一个解析器是 DNS 解析器，它会定期检查更新并解析 IP 地址。对于此解析器类型，hostname 子键指定要查询以获取 IP 地址列表的主机名。
• routing_key 字段将 span 路由到特定的下游 Collector。如果将此字段设置为 traceID，则负载均衡导出器将根据其 traceID 导出 span。否则，如果为 routing_key 使用 service，则它将根据服务名称导出 span。使用类似 span metrics connector 的连接器时，此路由很有用，因为同一服务的 span 都会发送到同一个下游 Collector 进行指标收集，从而确保准确的聚合。

提供 OTLP 端点的第一层 Collector 配置如下

• 静态
• DNS
• DNS 与服务

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

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:
        endpoint: 0.0.0.0:4317

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

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

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

exporters:
  loadbalancing:
    routing_key: service
    protocol:
      otlp:
        tls:
          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 端点的 Collector 的运行状况和性能。

Collector 作为代理和网关的组合部署

通常，多个 OpenTelemetry Collector 的部署会同时运行作为网关的 Collector 和作为 代理 的 Collector。

下图显示了这种组合部署的架构

• 使用代理部署模式下的 Collector（运行在每个主机上，类似于 Kubernetes DaemonSets）来收集主机上运行的服务以及主机自身的遥测数据，例如主机指标和抓取的日志。
• 使用网关部署模式下的 Collector 来处理数据，例如过滤、采样和导出到后端。

当您在 Collector 中使用需要每个主机唯一或消耗仅在应用程序运行的同一主机上可用信息的组件时，此组合部署模式是必需的。

• 像 hostmetricsreceiver 或 filelogreceiver 这样的接收器需要每个主机实例唯一。在同一主机上运行这些接收器的多个实例会导致数据重复。

• 像 resourcedetectionprocessor 这样的处理器会添加有关 Collector 和应用程序运行所在主机的​​信息。在与应用程序分离的机器上运行处理器会导致数据不正确。

权衡

优点

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

缺点

• 需要维护的额外项目，且可能失败（复杂性）
• 级联 Collector 时的附加延迟
• 更高的总体资源使用率（成本）

多个 Collector 和单写入者原则

OTLP 中的所有指标数据流都必须有一个 单写入者。在网关配置中部署多个 Collector 时，请确保所有指标数据流都有一个单写入者和一个全局唯一标识。

潜在问题

来自多个修改或报告相同数据的应用程序的并发访问可能导致数据丢失或数据质量下降。例如，您可能会看到同一资源上来自多个源的不一致数据，其中不同的源可能会相互覆盖，因为资源没有被唯一标识。

数据中存在一些模式，可能可以洞察这种情况是否发生。例如，通过目视检查，具有无法解释的间隙或跳跃的同一个序列可能表明多个 Collector 正在发送相同的样本。您也可能在后端看到错误。例如，使用 Prometheus 后端

处理乱序样本时出错

此错误可能表示两个作业中存在相同的目标，并且时间戳的顺序不正确。例如

• 指标 M1 在 T1 收到，时间戳为 13:56:04，值为 100
• 指标 M1 在 T2 收到，时间戳为 13:56:24，值为 120
• 指标 M1 在 T3 收到，时间戳为 13:56:04，值为 110
• 指标 M1 在 13:56:24 时间收到，值为 120
• 指标 M1 在 13:56:04 时间收到，值为 110

最佳实践

• 使用 Kubernetes 属性处理器 为不同的 Kubernetes 资源添加标签。
• 使用 资源检测器处理器 从主机检测资源信息并收集资源元数据。