跳到主要内容

分布式追踪最佳实践

为了优化您的 PubSub+ 事件代理和 PubSub+ 事件代理服务的分布式追踪体验，请使用以下领域的建议和最佳实践：

  • 可追踪性
  • 性能
  • 操作增强

可追踪性​

分布式追踪的核心价值在于能够沿着数据路径追踪您感兴趣的消息（用于故障排除、调试、数据血统、交付证明等用例），并借助您选择的可观测工具分析这些追踪数据。

在后端访问追踪消息​

您可以在后端应用程序中查看或搜索追踪消息或追踪消息的跨度，以：

  • 了解其交付状态、交付时间或其他交付细节
  • 调试消息交付中是否存在任何错误

确保您发布的消息包含用户属性，以便于在后端应用程序中搜索。例如，如果您的应用程序是在线商店，订单号或客户ID可能是发布者插入到用户属性中的有用数据。

根据您使用的后端应用程序，查看和搜索追踪消息的方式不同。有关更多信息，请参见您后端应用程序的当前文档。

有关如何使用 Jaeger 配置追踪的示例，请参见 Solace 分布式追踪和上下文传播的代码实验室。这个代码实验室展示了如何使用自动仪器进行上下文传播，并在 Jaegar UI 中可视化。在 Jaegar UI 中，您可以：

  • 选择您的事件代理以查看 Solace 追踪消息，并根据需要查看更多详细信息。有关更多信息，请参见在 Jaeger UI 中查看追踪消息。

  • 使用 Tags 字段搜索具有特定用户属性（键值对）的消息。有关更多信息，请参见在 Jaeger UI 中搜索追踪消息。

要解释您后端追踪日志中的追踪消息，请参见分布式追踪 OpenTelemetry Span 字段。

性能​

当您为 PubSub+ 中的事件启用分布式追踪时，它会生成额外的追踪消息。本节描述了如何通过接收和发送跨度优化追踪，并管理您的数据路径变量，并提供一般性能指南。

使用接收和发送跨度优化追踪​

作为消息追踪的副产品，事件代理会生成接收跨度和发送跨度。事件代理会生成：

  • 每次从发布者接收并持久化被追踪主题的消息时，生成一个接收跨度。

  • 每次尝试向消费者交付消息时，生成一个发送跨度。

然后，接收和发送跨度从事件代理传输到 OpenTelemetry 收集器。

每个接收跨度生成一个追踪消息。这种追踪可能会影响 CPU 使用率，并可能影响接近其限制的事件代理上的磁盘空间或网络带宽。发送跨度也会影响代理性能，但它们被分组到更大的追踪消息中（每次事件代理尝试向消费者交付消息时生成一个发送跨度），这减少了事件代理生成的消息总数，并有助于限制对事件代理性能的影响。

要使用接收和发送跨度优化追踪，请考虑以下事项：

  • 最小化事件代理生成的接收和发送跨度数量。在启用分布式追踪时，一次只启用几个主题，以测量和管理其对性能的影响。

  • 当向事件代理发送包含追踪上下文的消息时，修改发布应用程序以减少传播的上下文大小。为了实现这一建议，您可以管理行李和追踪状态（这些是可选的，并且可能是追踪上下文的大块），并减少发布消息中用户属性数据的数量。

分布式追踪对延迟的影响很小（对于设备来说延迟增加 10-20%，对于软件事件代理来说不到 10%）。

管理您的数据路径​

您的架构中的一些方面在启用分布式追踪时可能会影响您的数据路径性能。您可以使用以下考虑因素来提高性能并管理您的架构：

  • 消息大小影响性能。如果您的平均发布消息大小为 10 KB 或更大，分布式追踪对您向事件代理发布消息的每秒最大数量的影响相对较低，但如果您的平均发布消息大小为 1 KB 或更小，则影响较大。

  • 当消息扇出较低时，性能影响较小。例如，1:1 比例是低扇出，意味着一个发布的消息被发送给一个消费者，这在追踪上成本较低。对于更高的消息扇出，性能影响会显著增加。例如，1:50 比例是高扇出，意味着一个发布的消息被发送给 50 个消费者。这个高比例对事件代理的性能产生负面影响，因为由于额外的消息传递产生了额外的发送跨度。

  • 通过禁用高可用性（HA）的 mate-link 加密可以获得显著更高的追踪（和保证消息传递）性能。然而，这通常不推荐用于生产部署。

如果您的事件代理运行在最大保证消息速率的 50% 以下，并且您的稳态磁盘使用量在 max-spool-usage 的 50% 以下，那么通常可以安全地启用分布式追踪，特别是如果您遵循使用接收和发送跨度优化追踪中的建议。如果您的事件代理运行接近其最大消息容量，您必须更加谨慎地选择启用禁用追踪的主题，并应联系 Solace 以评估您的用例和潜在的性能影响。

一般性能指南​

以下最佳实践帮助您最大化使用分布式追踪的好处，同时对您的数据路径性能影响最小。

  • 仅在需要的消息 VPN 上启用追踪。

  • 使用追踪过滤器控制哪些事件被追踪。

  • 部署多个 OpenTelemetry 收集器来服务分布式追踪的非独占队列（单个事件代理可能会以高于单个收集器可以消费的速率生成跨度）。

  • 选择并构建您的后端，以处理事件代理生成的追踪消息量。

  • 如果您使用追踪进行调试或故障排除，或者间歇性使用它，请预配置包含感兴趣的主题的追踪过滤器，每个追踪过滤器包含特定追踪用例的所有主题。仅在需要时启用特定的追踪过滤器。

追踪消息的传递可能不受 OpenTelemetry 收集器或追踪后端的保证。

操作增强​

为了保持您的分布式追踪基础设施的健康，我们推荐以下最佳实践：

  • 随着您使用分布式追踪的增加（追踪跨度的数量增加），存储在后端存储中的数据量也会增加。为了帮助您管理这些新要求：

    • 使用与您组织内部存储和保留政策相一致的策略管理您的存储使用。例如，您的保留政策可能要求您定期删除不需要的数据，以减少来自您的可观测性或存储供应商的保留费用。

    • 监控对最佳性能至关重要的指标（参见 OpenTelemetry 指标和健康监控）或日志（参见 OpenTelemetry 日志）。有关更多信息，请参阅性能。

  • 执行定期维护并管理您的存储扩展解决方案，如有必要。例如，您可以使用自动化工具、日志分析等来识别和解决瓶颈和性能变化。

  • 新的追踪事件代理功能可能需要 OpenTelemetry 收集器的新版本。在升级事件代理之前，请参见分布式追踪版本兼容性，确保您的 PubSub+ 事件代理、OpenTelemetry 收集器和 PubSub+ 消息 API 版本兼容。