排查标准主题问题

本文档提供了一些在向标准 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 指标图表或 Google Cloud 控制台中的 API 和服务页面检查错误率。如果错误率非常低，则可能是间歇性问题。

如果请求到达了 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 跟踪，以帮助您调试发布延迟时间。