Saydo Open Telemetry接收器

Saydo Open Telemetry 接收器是Saydo为OpenTelemetry Collector项目构建的软件插件。作为分布式追踪解决方案的一部分，接收器帮助您选择的后端解释与PubSub+事件代理发送和接收的事件消息相关的追踪数据。

接收器从事件代理的遥测队列中消费追踪消息，并将这些消息转换为OpenTelemetry跨度。然后，收集器将这些跨度转发到您首选的OpenTelemetry 后端（如 Jaeger、Prometheus、Zipkin、DataDog、DynaTrace 等）。

您可以使用Saydo Open Telemetry接收器收集基本统计数据，例如：

接收的追踪消息数量
连接状态
失败的连接尝试次数（对于 HA 备用事件代理特别有用）
任何其他监控或调试统计数据

作为 OpenTelemetry Collector 的一部分，Solace Open Telemetry 接收器在收集器支持的任何平台上运行。收集器和接收器不运行在事件代理上；而是分别部署，如下所示：

有关 OpenTelemetry Collector 和自定义接收器（如 Solace Open Telemetry 接收器）之间的关系的更多信息，请参阅 OpenTelemetry 文档中的收集器部分。

获取收集器

Solace Open Telemetry 接收器是 opentelemetry-collector-contrib 存储库的一部分。有关此存储库中收集器版本的详细信息，请参阅 https://github.com/open-telemetry/opentelemetry-collector-contrib/releases。要获取收集器的容器包，请运行以下 Docker 命令：

docker pull ghcr.io/open-telemetry/opentelemetry-collector-releases/opentelemetry-collector-contrib:<version>

其中 <version> 是收集器的版本，例如 0.79.0。

Solace 建议您使用最新的 OpenTelemetry Collector 版本。

有关收集器的最小和推荐版本信息，请参阅分布式追踪版本兼容性。

配置收集器

OpenTelemetry Collector 及其组件（接收器、处理器和导出器）使用 YAML 配置文件进行配置，该文件在启动时加载。

您必须在接收器中配置以下参数：

事件代理 URL（连接到事件代理）：此 URL 必须包含消息 VPN 的 AMQP 端口
认证机制（基本、TLS 客户端证书或 OAuth）
认证凭证
遥测队列名称

配置好收集器组件的配置键后，您必须通过 OpenTelemetry 服务部分中的管道启用它们（有关更多信息，请参见 OpenTelemetry 服务）。

有关如何实例化、配置和管理接收器的更多信息，请参见 GitHub 上的 Solace OpenTelemetry 接收器项目。

高可用性(HA)和灾难恢复(DR)

对于部署在高可用性 (HA) 或灾难恢复 (DR) 事件代理对中的事件代理，您可以在 OpenTelemetry Collector 中的单个管道上实例化和配置两个（或更多）接收器。一个接收器连接到主事件代理，另一个连接到备份事件代理。只有连接到活动事件代理的接收器才能成功接收追踪消息。在故障转移场景中，无法连接的接收器会频繁（无限）重试连接，以最小化接收器断开连接的时间。

以下示例显示了如何在 HA 或 DR 设置中配置多个接收器实例（使用 SASL plain 认证）：

receivers:
  solace/primary:
    broker: [myHost-primary:5671]
    auth:
      sasl_plain:
        username: otel
        password: otel01$
    queue: queue://#telemetry-profile123

  solace/backup:
    broker: [myHost-backup:5671]
    auth:
      sasl_plain:
        username: otel
        password: otel01$
    queue: queue://#telemetry-profile123

  service:
    pipelines:
      traces/solace:
        receivers: [solace/primary,solace/backup]

健康监控

您可以配置 OpenTelemetry Collector 在端口 8888 上暴露一个 OpenMetrics 端点，路径为 /metrics，如下所示：

service:
 pipelines:
  metrics:
   address: ":8888"

OpenTelemetry Collector 还有一个特殊的接收器可观测性 API，用于发出可观测性信号（obsreport.Receiver）。以下是一些 Solace 接收器可观测性指标键的表格：

键	类型	显示的接收器指标
`<br>solacereceiver/failed_reconnections<br>`	sum	事件代理重新连接失败的次数。
`<br>solacereceiver/recoverable_unmarshalling_errors<br>`	sum	消息解封装的可恢复错误次数（例如，缺少必需的事件属性、字段错误等）。
`<br>solacereceiver/fatal_unmarshalling_errors<br>`	sum	消息解封装的致命错误次数（例如，缺少预期的跨度属性）。
`<br>solacereceiver/dropped_span_messages<br>`	sum	丢弃的跨度消息数量。
`<br>solacereceiver/received_span_messages<br>`	sum	接收的跨度消息数量。
`<br>solacereceiver/need_upgrade<br>`	最新值	接收器的升级状态。如果值等于 1，则表示接收器需要升级，与从事件代理接收的消息不兼容。
`<br>solacereceiver/reported_spans<br>`	sum	报告给跟踪管道下一个组件的接收跨度数量。
`solacereceiver/receiver_connection_status`	最新值	接收器的连接状态如下：

无指标：接收器尚未启动
0：接收器正在启动
1：接收器正在连接
2：接收器已连接
3：接收器空闲（通常与 solacereceiver/need_upgrade ==1 结合）
4：接收器正在终止
5：接收器已终止 |

如果使用不同名称的多个接收器实例（例如，在 HA 设置中），完整的键名称将类似于 otelcol_receiver_solace_solacereceiver_primary_receiver_status（对于名为 "primary" 的接收器实例）。

调试

日志是 OpenTelemetry Collector 用于调试收集器和接收器问题的主要机制。日志显示：

事件代理连接问题
将跨度转发到 OpenTelemetry 收集器或后端的问题
从事件代理接收的追踪消息解析问题
接收器因任何原因丢弃的任何跨度或追踪消息

要了解有关接收器调试级别的更多信息以及如何更改它们，请参阅 OpenTelemetry 服务。

接收器性能

Solace Open Telemetry 接收器被设计为一个高性能实时模块，能够处理高跨度速率。当事件代理发布到大量端点时，这特别有用。性能、服务器资源和管理配置文件的条件可能导致需要多个接收器来服务事件代理上的所有消息 VPN。在 OpenTelemetry 收集器中实例化多少接收器没有固定限制。为了允许接收器和收集器的水平扩展（考虑到分布式追踪跨越多个微服务和代理的本质），遥测队列是非独占的。

流控制

OpenTelemetry 收集器可能会遇到无法跟上传入追踪消息速率的情况。如果没有适当的策略来管理追踪消息流（例如，使用内存限制器处理器），OpenTelemetry 收集器可能会因内存不足而崩溃。为了防止这种情况，Solace 接收器具有流控制策略，为同步和异步管道提供背压机制：

同步管道不应用任何追踪消息批处理或缓冲。这导致消息丢失的可能性降低，错误传播自由（因为问题可以同步报告），性能降低。这是数据完整性比追踪消息吞吐量更受重视的情况的首选选项。
异步管道应用追踪消息批处理和缓冲。这导致消息丢失的可能性增加，错误传播有限（因为问题不能同步报告），性能提高。这是追踪消息吞吐量比数据完整性更受重视的情况的首选选项。

在异步管道中，随着消息吞吐量的增加，追踪消息丢失的可能性增加，后端不可用，如果收集器因内存不足而崩溃，或者收集器进程被操作系统在没有优雅终止的情况下杀死。

为组件配置流控制

Solace 建议以下配置用于 OpenTelemetry 收集器组件（Jaeger 导出器、批处理器和内存限制器处理器）的同步和异步管道。

以 Jaeger 导出器为例。其他导出器可能需要类似的配置。

组件	同步管道	异步管道
Jaeger 导出器	- 禁用等待就绪时的批处理 gRPC 配置：

exporters:  
otlp/jaeger:  
wait_for_ready: false  

不要配置返回失败以立即返回后端错误：

retry_on_failure:  
enabled: false  

禁用发送队列：

otlp/jaeger:  
sending_queue:  
enabled: false  
``` | 保持启用（有关 Jaeger 导出器配置的异步和队列行为，请参见 OpenTelemetry 导出器助手）。 |
| 批处理器 | 不要启用（因为批处理器会掩盖下一个组件返回的所有错误）。 | 作为管道中的最后一个处理器启用，以提高性能（因为这种对齐方式会在将追踪消息转发到导出器之前将追踪消息放入批次中）。 |
| 内存限制器 | 可选择启用（因为任何时候只有一个追踪消息流动）。配置 `check_interval` 为 1 秒。 | 配置足够低以对 Solace 接收器施加背压（例如，将 `limit_percentage` 设置为小于 50%，并使用较短的 `check_interval`，通常小于 1 秒）。 |

实施的流控制策略应了解 Solace 接收器的生命周期。例如，接收器实例的终止必须中断重试计时器（如果它使用 `passed` 在 `context.Context` 中运行）。如果没有，接收器在终止后可能不会确认追踪消息，这些追踪消息将被传递给另一个可用的接收器实例。

有关 Jaeger 导出器的更多信息，请参见 Jaeger 文档。有关批处理器的更多信息，请参见 OpenTelemetry 批处理器。有关内存限制器的更多信息，请参见 OpenTelemetry 内存限制器。

#### 在接收器上配置流控制

默认情况下，Solace Open Telemetry 接收器具有延迟重试功能，单个超时值为 10 毫秒。每次由于内存不足或后端不可用而从管道返回非终端错误时，都会发生延迟重试。Solace 建议实现延迟，使用类似于内存限制器的 `check_interval` 配置。这允许使用有效的时间单位（"ns"、"us"、"ms"、"s"、"m"、"h"）。目前仅支持小于 1 的值。

以下示例显示了如何为 1 秒延迟配置 Solace Open Telemetry 接收器：

receivers: solace/primary: broker: [myHost-primary:5671] flow_control: delayed_retry: delay:1s ....

#### 流控制的可观测性

Solace Open Telemetry 接收器发出有关追踪消息流控制的以下统计数据。这些统计数据可以被监控以在重负载下调整接收器性能。

| 键 | 类型 | 显示的接收器指标 |
| --- | --- | --- |
| ```<br>solacereceiver/receiver_flow_control_status<br>``` | 最新值 | 当前流控制状态：<br>- 0：接收器当前不受流控制<br>  <br>- 1：接收器当前受流控制（延迟重试） |
| ```<br>solacereceiver/receiver_flow_control_recent_retries<br>``` | 最新值 | 接收器受流控制时最近（或当前）的重试次数。 |
| ```<br>solacereceiver/receiver_flow_control_total<br>``` | 总和 | 接收器被流控制的总次数。 |
| ```<br>solacereceiver/receiver_flow_control_with_single_successful_retry<br>``` | 总和 | 在第一次重试后解决流控制情况的次数。 |

以下是一些调整接收器性能的提示：

- 如果 `receiver_flow_control_recent_retries` 总是报告 1，则配置的延迟可能太高。为了提高性能，减少配置的延迟，以增加流控制情况下所需的重试次数。

- 如果 `receiver_flow_control_recent_retries` 总是报告一个高数字，则配置的延迟太低。为了提高性能，增加配置的延迟，以减少流控制情况下所需的重试次数。

- 使用尽可能小的重试间隔，使 `receiver_flow_control_total` 等于 `receiver_flow_control_with_single_successful_retry`。在这种情况下，接收器不需要重试超过一次就能将追踪数据推送到管道中。

### 安全

作为 OpenTelemetry 收集器的一部分，Solace Open Telemetry 接收器使用 OpenTelemetry 社区建立的配置实用工具和编码实践。默认情况下，接收器通过连接到事件代理并应用常见的认证机制（如 OAuth、客户端证书认证和基本用户名/密码认证）来强制执行 TLS。接收器通过接收器配置中提供的受信任存储区验证事件代理的服务器证书，包括主机名和到期日期。

有关收集器安全的更多信息，请参阅 OpenTelemetry 收集器安全最佳实践。

### Solace 对 OpenTelemetry 收集器的支持

自管理事件代理客户（不使用 PubSub+ Cloud 的客户）负责部署、升级和维护其 OpenTelemetry 收集器部署的安全性。

Solace 将在连接到具有分布式追踪许可的 PubSub+ 事件代理时，根据当前支持条款，为 OpenTelemetry 收集器提供支持，并将 OpenTelemetry 收集器问题视为与任何其他类似业务影响问题同等严重和优先级。需要对 OpenTelemetry 收集器或相应的 Solace 接收器进行更改的错误和/或修复将提交给 OpenTelemetry，并将仅在 OpenTelemetry 收集器的未来版本中提供。

Solace 可能会根据 PubSub+ 事件代理和整体遥测功能套件的战略方向，在我们的判断下提供商业上合理的进一步开发活动，以解决客户的问题、增强功能和功能请求。

获取收集器​

配置收集器​

高可用性(HA)和灾难恢复(DR)​

健康监控​

调试​

接收器性能​

流控制​

为组件配置流控制​