GCP Pub/Sub触发的Cloud Function偶发无退出日志问题排查

可能的原因 #

• 未捕获异常+日志缓冲区未刷出：代码的异常捕获仅覆盖了进入while循环前的逻辑，循环内部的Slack调用、Firestore读写、Pub/Sub发布等操作没有异常捕获。一旦这些操作抛出未处理异常，Python进程直接退出，缓冲区的日志来不及发送到Cloud Logging，就会出现无错误、无退出日志的情况。
• 客户端无超时导致无限阻塞：Slack、Firestore、Pub/Sub的客户端如果没有配置超时，遇到网络波动或服务端限流时会无限等待，直到触发540s函数超时，GCF强制杀死进程时不会刷出剩余日志。
• 底层实例异常回收：GCF底层节点故障时会强制回收运行中的实例，这类情况不会产生用户可见的错误日志。
• 并发执行逻辑冲突：函数内部自触发Pub/Sub消息可能导致同一game_id对应多个函数实例并发运行，同时修改Firestore数据触发逻辑异常导致进程崩溃。

排查解决方法 #

• 补全全链路异常捕获和日志刷出逻辑：在整个函数外层增加try-catch捕获所有异常，捕获后立刻打印错误堆栈，调用logging.shutdown()强制刷出日志，再抛出异常。修改示例：

import logging
def vote_stage(event, context):
    try:
        # 原有所有业务代码
    except Exception as e:
        logger.exception(f"uncaught error, game_id={event.get('attributes', {}).get('game_id', 'unknown')}")
        logging.shutdown()
        raise e

• 给所有外部调用配置超时：给Slack API、Firestore读写、Pub/Sub发布操作都配置明确的超时时间（比如5-10s），避免无限阻塞。
• 增加详细埋点日志：在while循环每轮迭代开头添加debug日志，打印当前时间和已循环次数，缩小异常发生的范围；同时开启Cloud Trace跟踪函数执行的各个阶段耗时，定位阻塞点。
• 增加并发控制逻辑：在Firestore中为每个game_id添加分布式锁，函数启动后先抢占锁，抢占失败直接退出，避免同一game_id同时运行多个实例引发冲突。
• 验证超时日志采集逻辑：写测试函数主动sleep超过540s，确认是否能正常采集到超时错误日志，若无法采集则调整日志采集配置，开启DEBUG级别的日志采集。

内容的提问来源于stack exchange，提问作者augustin-barillec