AWS Lambda中CloudWatch日志与指标的收集方式及性能影响问询

一、日志收集方式 #

• 默认自动收集：Lambda会自动捕获函数的标准输出（如print、console.log）和标准错误输出，无需额外配置，直接发送到CloudWatch Logs。对应的日志组格式为/aws/lambda/[你的函数名称]，日志流按执行环境实例划分。
• 自定义日志写入：若需更精细的日志控制（如自定义日志级别、结构化日志），可以通过AWS SDK（如Python的boto3、Node.js的aws-sdk）调用PutLogEvents API写入，但一般场景下默认收集已足够满足需求。

二、指标收集方式 #

• 内置核心指标：Lambda自动向CloudWatch Metrics上报基础运行指标，包括Invocations（调用次数）、Errors（错误数）、Duration（执行时长）、Throttles（限流次数）等，无需编写额外代码，直接在CloudWatch控制台即可查看。
• 自定义业务指标：
  • 直接API调用：使用AWS SDK调用PutMetricData API，手动上报业务相关指标（如处理订单数、请求成功率）。
  • CloudWatch Embedded Metric Format（EMF）：将指标以JSON格式嵌入到日志中，随普通日志一起推送，CloudWatch会自动解析这些日志并生成指标。这种方式无需额外API调用，是更高效的自定义指标方案。

三、性能影响细节 #

日志推送的性能逻辑 #

Lambda的日志不会每条单独触发远程调用，而是采用内存缓冲+批量推送的机制：

• 执行环境会先将日志暂存到内存缓冲区，当缓冲区达到阈值、函数执行结束，或固定时间间隔（通常为几秒）到期时，才会批量将日志发送到CloudWatch Logs。
• 短执行时长的函数：日志会在函数执行完成后一次性批量推送；长运行的函数（如容器型Lambda）则会定期批量推送，避免频繁网络请求。

指标上报的性能逻辑 #

• 内置指标：完全由Lambda服务端处理，不会占用函数执行的CPU、内存或网络资源，对函数性能无影响。
• 自定义指标：
  • 直接调用PutMetricData：每次调用都是一次独立的远程API请求，会增加函数的执行时间和网络开销，建议批量打包多个指标后再调用，减少请求次数。
  • EMF方式：指标随日志一起批量推送，无需额外API调用，性能开销与普通日志一致，且不会阻塞函数主业务逻辑。

通用性能说明 #

日志和指标的推送操作均在Lambda执行环境的后台进程中完成，不会阻塞函数的主业务代码执行，也不会计入函数的计费时长（计费时长从函数开始执行到返回结果为止）。

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