排查标准主题问题

本文档提供了一些在将消息发布到标准 Pub/Sub 主题时常用的问题排查提示。

详细了解如何将消息发布到主题以及 不同的功能。

发布延迟时间较长

发布延迟时间是指完成发布者客户端发出的发布请求所需的时间。发布延迟时间与 端到端传送延迟时间不同， 后者是指将发布到 Pub/Sub 的消息传送给订阅者客户端所需的时间。您可能会观察到发布延迟时间或端到端延迟时间较长，即使另一种延迟时间的值较低也是如此。Pub/Sub 发布者客户端、客户端与 Pub/Sub 后端之间的传输过程或 Pub/Sub 后端可能会导致发布延迟时间较长。您可以使用 topic/send_request_latencies 指标检查 Pub/Sub 后端中产生的发布延迟时间。后端发布延迟时间较长可能与以下因素有关：

  • Pub/Sub 专为低延迟、高吞吐量传送而设计。如果主题的吞吐量较低，则与该主题关联的资源可能需要更长的时间才能初始化。

  • 如果您使用的是消息存储政策，则可能会影响对主题和订阅的请求的整体延迟时间。请查看使用此配置对 性能和可用性 的影响 。

如果您的发布者客户端观察到的发布延迟时间明显高于指标中反映的延迟时间，则可能是以下客户端因素之一：

  • 确保您不会为每次发布都创建一个新的发布者。建议每个应用针对每个主题使用一个发布者客户端来发布所有消息。启动新的发布者对象和添加新线程会产生延迟时间成本。如果您使用 Cloud Run functions 发布消息，请注意，调用也可能会影响发布延迟时间。

  • 如果您发现默认重试设置不适合您的使用情形，请进行相应的调整。不过，请验证新值是否过高。了解如何配置重试 请求。

请注意，发布延迟时间较长可能会导致 DEADLINE_EXCEEDED 错误，下一部分将对此进行讨论。

发布操作失败并显示 DEADLINE_EXCEEDED

发布请求期间出现 DEADLINE_EXCEEDED 错误表示请求未在分配的时间内完成。这可能是由多种因素造成的，例如请求未到达 Pub/Sub 服务或性能问题影响了请求。

如需验证发布请求是否到达 Pub/Sub 服务， 请使用 topic/send_request_count 指标（按 response_code 分组）监控主题。此指标有助于确定请求是否在到达 Pub/Sub 主题之前失败。如果该指标为空，则表示存在外部因素阻止消息到达 Pub/Sub 服务。此外，如需排除间歇性问题的可能性， 请使用前面提到的 topic/send_request_count 指标图表或控制台中的“API 和 服务” Google Cloud 页面检查错误率。如果错误率非常低，则可能是间歇性问题。

如果请求到达 Pub/Sub，则发布操作失败并显示 DEADLINE_EXCEEDED 错误的一些可能原因如下：

客户端瓶颈

发布失败很可能是由客户端瓶颈造成的，例如内存不足、CPU 压力过大、线程运行状况不佳或托管发布者客户端的虚拟机中存在网络拥塞。如果 Publish 调用返回 DEADLINE_EXCEEDED，则可能是异步 Publish 调用加入队列的速度比它们被发送到服务的速度更快，这会逐渐增加请求延迟时间。此外，请检查以下任何一项是否有助于确定系统中的可能瓶颈：

  • 检查发布消息的速度是否快于客户端发送消息的速度。通常，每个异步 Publish 调用都会返回一个 Future 对象。如需跟踪等待发送的消息数量，请存储要通过每个 Publish 调用发送的消息数量，并仅在 Future 对象的回调中将其删除。

  • 确保运行发布者的机器与 之间有足够的上传带宽 Google Cloud。开发 Wi-Fi 网络通常具有 1-10 MBps 的带宽，即每秒 1000-10000 条典型消息。在不限速的情况下循环发布消息可能会导致短时间内出现短暂的突发高带宽。为避免这种情况，您 可以在机器上运行发布者，或降低发布消息的速率以 Google Cloud 匹配可用带宽。

  • 检查您的主机和 Google Cloud 之间是否存在因启动网络拥塞或防火墙等原因造成的超长延迟时间。计算 网络 吞吐量 提供了在不同 场景下查找带宽和延迟时间的指南。

  • 最终，单台机器可以发布的的数据量是有限的。 您可能需要尝试横向扩展或在多个机器上运行发布者客户端的多个实例。测试 Cloud Pub/Sub 客户端以最大限度地提升流式传输 性能 展示了 Pub/Sub 如何通过增加 CPU 数量在单个 Google Cloud 虚拟机 上进行扩展。例如，对于 1KB 大小的消息，16 核 Compute Engine 实例可以达到 500 MBps 到 700 MBps 的传输速率。

发布超时时长不足

如需降低发布调用的超时率，请确保在发布者客户端的重试设置中定义了足够长的超时。对于重试设置，请将初始截止时间设置为 10 秒，并将总超时设置为 600 秒。即使您没有积累大量积压的未发送消息，请求延迟时间偶尔出现高峰也可能会导致发布调用超时。 不过，如果您的问题是由持续的瓶颈（而非偶尔的超时）造成的，则重试次数越多，错误就越多。

客户端库问题

您可能运行了某个具有已知问题的客户端库版本。以下列表包含所有客户端库的问题跟踪器。如果您发现已知问题影响了您使用的客户端库版本，请升级到最新版本的客户端库。这样可确保您安装了所有相关更新，包括修复程序和性能改进。

架构问题

如果您的发布开始返回 INVALID_ARGUMENT，则可能是 有人更新了主题以更改关联的 架构、删除了 架构或删除了与主题关联的架构修订版本。在这种情况下，请将主题的架构设置更新为与要发布的消息匹配的架构和修订版本集，或调整消息格式以匹配当前架构。

消息加密问题

如果您已将 Pub/Sub 主题配置为使用客户管理的加密密钥加密发布的消息，则发布可能会失败并显示 FAILED_PRECONDITION 错误。如果 Cloud KMS 密钥被停用，或者通过 Cloud EKM 外部管理的密钥不再可访问，则可能会发生此错误。如需恢复发布，请恢复对 密钥的访问权限。

单条消息转换 (SMT) 问题

如果您已在 Pub/Sub 主题上配置 SMT，则当转换无法应用于消息时，发布可能会失败并显示 INVALID_ARGUMENT 错误。如果发布批次中的任何消息转换失败，则整个批次都无法发布。返回的错误会指明失败原因，例如：

INVALID_ARGUMENT: Pub/Sub failed to apply a message transformation to one or
more messages in the publish request. Error: Failed to execute JavaScript UDF:
`my_function`. Return value is not an object.

监控 SMT

如需了解 SMT 对主题的性能和影响，请使用以下监控指标：

topic/message_transform_latencies 指标用于衡量将 SMT 应用于消息所需的时间。该指标仅衡量 SMT 延迟时间，不包括消息传送时间的其他部分。

该指标提供两个关键标签：

  • status：报告转换是成功还是遇到问题。

  • filtered：指示 SMT 是否导致消息被过滤掉。当 SMT 过滤主题上的消息时，Pub/Sub 会丢弃该消息，并且该消息永远不会发送给订阅者。仅当 SMT 执行过滤时，此 filtered 标签才为 true。使用 Pub/Sub 的 内置过滤 功能过滤的消息不会反映在 此特定指标中。

topic/byte_cost 指标用于标识被 SMT 过滤的消息或 SMT 失败的消息。查找以下特定值：

  • 当 SMT 过滤消息时，operation_type 为 smt_publish_filter_drop。

  • 如果 SMT 无法转换消息，您会看到一个不是 OK 的 response_code。

后续步骤

探索 OpenTelemetry 跟踪，以帮助您 调试发布延迟时间。