请求失败时如何观察Pub/Sub推送窗口变化及排查负载异常

一、可能遗漏的关键配置 #

• NACK返回格式校验：Pub/Sub仅识别HTTP 4xx/5xx状态码为NACK信号，若Cloud Run在第三方服务超时后仍返回200（仅在响应体标记失败），Pub/Sub会判定消息已处理，不会调整推送速率。确保业务失败时返回504（超时）或503（服务不可用）这类标准错误码。
• AckDeadline与Cloud Run超时匹配：你设置Cloud Run超时10秒，订阅的ackDeadline需大于等于该值（建议设为15秒），避免Pub/Sub在Cloud Run未完成处理时就重推消息，加剧负载。若启用了自动扩展AckDeadline，需确认逻辑符合业务处理时长。
• 未限制未确认消息阈值：订阅的maxOutstandingMessages和maxOutstandingBytes直接控制Push Window大小（即未确认消息的数量/字节数）。你的场景是单实例并发1，需将maxOutstandingMessages设为1或2，否则Pub/Sub会推送超出Cloud Run处理能力的消息，导致NACK堆积但速率调整滞后。
• 推送并发未适配Cloud Run能力：若订阅pushConfig未设置maxConcurrency，默认值可能高于Cloud Run的并发数（你设为1），导致推送过载，触发Cloud Run限流后，Pub/Sub的慢启动逻辑会被打断。

二、慢启动未生效的原因排查 #

你的复现场景中send_request_count先升后平稳，不符合慢启动预期，可能的触发点：

• 初始推送触发Cloud Run限流：Pub/Sub初始推送速率超过Cloud Run并发1的限制，Cloud Run返回429，此时Pub/Sub会暂停推送并调整速率，但如果maxOutstandingMessages过高，已推送的消息会堆积，后续速率调整变慢。
• NACK退避优先于慢启动：大量NACK出现时，Pub/Sub会进入退避模式，暂停速率增长，直到成功率回升，此时send_request_count会保持平稳甚至下降。
• 监控指标延迟：send_request_count指标存在1-2分钟的统计延迟，看似平稳可能是速率调整还未在指标中体现。

三、Push Window与推送速率监控方案 #

1. 利用GCP内置指标 #

• outstanding_messages：核心指标，直接反映当前未确认的消息数（即Push Window大小），若持续高于Cloud Run并发能力，说明速率控制未生效。
• push_request_failure_count：统计推送失败（NACK、超时、不可达）的请求数，可关联第三方服务超时的触发频率。
• delivery_attempts_per_message：每条消息的投递次数，次数过多说明NACK频繁，速率调整不及时。
• Cloud Run的request_count与response_latencies：对比Pub/Sub的send_request_count，确认请求是否正常到达；响应延迟飙升时，对应第三方服务超时的场景。

2. 自定义日志与告警 #

• 在Cloud Run代码中添加NACK原因日志（如"Redis超时"、"Firestore超时"），通过Cloud Logging过滤这些日志，定位失败根源。
• 在Cloud Monitoring创建自定义仪表盘，关联outstanding_messages、send_request_count和Cloud Run的response_latencies，直观查看Push Window的动态变化。
• 设置告警规则：当outstanding_messages超过2，或push_request_failure_count5分钟内持续上升时触发告警。

四、修复步骤 #

1. 将订阅的maxOutstandingMessages设为1，maxOutstandingBytes设为单条消息平均大小的2倍，严格控制未确认消息数。
2. 调整订阅ackDeadline为15秒（Cloud Run超时+5秒），避免提前重推。
3. 确保Cloud Run在第三方服务超时返回504/503状态码，而非200。
4. 若无需有序消息，关闭订阅的enableMessageOrdering，让慢启动逻辑正常运行。
5. 配置订阅pushConfig的maxConcurrency为1，匹配Cloud Run的并发能力。

内容的提问来源于stack exchange，提问作者Sambit Kumar Panda