为何使用AWS Lambda内部扩展无法拦截console.log？

为什么两种方式效果不同？ #

Lambda Internal Extension和业务函数属于完全独立的进程：

• 当你给Extension设置NODE_OPTIONS: --require /opt/logging.js时，脚本会被加载到Extension自身的Node.js进程中，修改的是Extension进程的console对象，和业务函数所在的进程没有任何关联，自然无法拦截业务代码的console.log。
• 而在业务入口文件添加require('/opt/logging.js')的方式，是直接在业务函数的进程内加载脚本，修改的是业务进程的console对象，所以能正常拦截日志。

可行的无侵入方案 #

方案1：直接给Lambda函数设置NODE_OPTIONS环境变量 #

这是最简单直接的方案，无需使用Extension：

• 将你的logging.js打包到Lambda层中（层的根目录会挂载到/opt/，所以脚本最终路径为/opt/logging.js）。
• 给目标Lambda函数添加环境变量：NODE_OPTIONS="--require /opt/logging.js"。
• Lambda业务进程启动时会自动预加载该脚本，修改业务进程的console对象，完全不需要修改业务代码。

方案2：使用Node.js Runtime Hooks（Node.js 16.x+支持） #

这是官方推荐的无侵入运行时定制方案：

• 编写日志拦截逻辑到logging-hook.js中。
• 将脚本放在Lambda层的nodejs/lib/runtime-hooks/目录下。
• 设置Lambda环境变量：NODE_OPTIONS="--experimental-loader /opt/nodejs/lib/runtime-hooks/logging-hook.js"（如果是预加载类逻辑，也可以用--require参数）。
• 该方案能在业务代码执行前加载你的逻辑，实现日志拦截。

方案3：自定义Lambda Runtime #

适合需要深度统一管控的场景：

• 创建自定义Node.js Runtime，在Runtime的启动脚本中预加载你的日志拦截逻辑。
• 将所有需要日志拦截的Lambda函数部署到这个自定义Runtime上。
• 复杂度较高，但灵活性最强，能实现更多运行时定制需求。

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