CloudWatch未显示AWS Lambda数据库连接故障日志排查咨询

问题现象 #

• 正常场景下Python Lambda函数的所有运行日志都会写入CloudWatch，但部分触发Internal Server Error的场景中，CloudWatch仅记录START、END两个框架级日志条目，无任何错误详情输出，无法定位故障根因。
• 复现规律：注释掉代码中psycopg2.connect连接PostgreSQL的逻辑时，函数可正常向CloudWatch写入started日志、异常捕获信息，最终正常返回200 OK响应；保留数据库连接代码时，函数直接抛出Internal server error，CloudWatch无对应错误日志输出。

故障复现代码 #

import json
import psycopg2

def lambda_handler(event, context):

    try:
    
        print('started')
        s = psycopg2.__version__
        print(s)
        
        conn = psycopg2.connect(
            user='pg_user',
            password='*********',
            host='pg_host',
            port='5432',
            database='dev_db'
        )

        cur = conn.cursor()
        cur.execute("select count(1) q from keywords_to_scrape")
        for q in cur:
            print(f'q = {q}')
        
    except Exception as e:
        print(f'exception: {e} ')
    finally:
        print('returning result')

        return {
                'statusCode' : 200,
                'body' : json.dumps(f'{s}')
        }

排查与解决方法 #

这类仅显示START/END、无业务日志的Lambda故障，核心原因都是进程在标准输出日志缓冲区刷新前被强制终止，日志还没来得及上传到CloudWatch进程就退出了。结合psycopg2连接数据库的场景，按以下优先级从高到低排查：

• 优先排查psycopg2二进制兼容性问题
  这是该场景最高概率的根因：psycopg2是带C扩展的Python库，如果是在Windows、Mac本地环境直接pip下载打包成Lambda层上传，底层依赖的libpq动态链接库和Lambda运行的Amazon Linux环境不兼容，调用connect方法时会直接触发C层级的段错误（进程退出码139）。这类崩溃发生在Python解释器之外，既不会触发你写的except异常捕获逻辑，也不会把print暂存在内存缓冲区的日志刷出，进程直接退出，所以连最开始的started日志都看不到。
  解决方式：使用Amazon Linux 2运行环境编译psycopg2二进制包后再打包部署，或者直接使用Lambda平台提供的官方PostgreSQL适配层，不要使用非Linux环境打包的psycopg2依赖。
• 检查基础配置问题
  • 确认Lambda执行角色绑定了AWSLambdaBasicExecutionRole托管策略，缺少该策略的话函数没有写入CloudWatch Logs的权限，所有应用层日志都无法上传，只会保留Lambda服务本身生成的START/END记录。
  • 检查内存与超时配置：给函数分配的内存低于128M时，冷启动叠加数据库连接逻辑很容易触发OOM，被系统直接杀死进程；如果配置的执行超时时间短于数据库连接超时时间，连接过程中触发Lambda硬超时，也会直接中断进程，不会留下应用层日志。
• 验证日志缓冲区问题
  临时给所有print语句添加flush=True参数，强制每次打印就立即把日志推送到CloudWatch，排除缓冲区未刷新的干扰：

  print('started', flush=True)
  

  如果加完强制刷新后能看到connect调用前的日志，执行到连接逻辑就中断，即可实锤是数据库连接环节触发了进程崩溃。
• 通过Lambda内置监控指标定位
  打开Lambda控制台的监控页面，查看故障时间点的运行指标：如果内存使用率达到100%即为OOM问题；如果错误指标显示Runtime.ExitError且进程退出码为139，即可确认是C扩展触发的段错误，实锤依赖兼容性问题。

代码本身的隐患修正 #

你提供的示例代码存在两个会吞掉异常的逻辑问题，需要调整：

1. 不要在finally块中写return逻辑，finally块的return会强制覆盖try/except块的所有返回与异常抛出，真实错误会被直接吞掉，不会对外暴露。
2. finally块中直接引用变量s存在风险：如果s = psycopg2.__version__这行执行前就抛出异常，变量s未定义，会触发NameError，且因为return在finally块中，这个错误也不会被记录。

内容的提问来源于stack exchange，提问作者user2265417