为什么我的CloudWatch日志会出现缺失断层？

• Lambda执行角色权限不足：首先检查你的Lambda执行角色是否配置了logs:CreateLogStream、logs:PutLogEvents、logs:CreateLogGroup三个必要权限。serverless框架默认会生成对应权限，但如果你手动修改过角色配置、或者使用自定义角色，部分执行实例可能因为权限问题无法上报日志，出现批量日志延迟或者丢失的情况。
• 日志流筛选遗漏：CloudWatch默认只展示最新的部分日志流，如果高并发场景下生成了大量新的日志流，控制台默认列表没加载全，就会看起来中间时间段没有日志。你可以在日志组页面选择「搜索所有日志流」，而不是单独查看某一个日志流的内容，避免漏看分散在其他日志流里的日志。
• 日志批量上报延迟：Lambda的日志不是实时单条上报的，会先缓存在执行环境中，批量异步上报到CloudWatch。如果你的函数并发量很高（比如你提到的7-8点有数千次执行）、或者函数执行逻辑中存在未捕获的异常导致进程直接退出、或者函数运行时间极短，缓存的日志可能来不及上报就被销毁，或者累积到后续冷启动的实例中统一上报，就会出现中间时间段没有日志、后续突然集中出现之前时间段日志的情况。

  可以临时给测试函数加一段Console.WriteLine(DateTime.UtcNow.ToString("o"));的强制落盘日志，验证是否是上报延迟导致的日志时间和实际执行时间错位。

• 日志流命名冲突：C#的Lambda运行时如果存在多个并发实例同时创建同名的日志流，会出现写入冲突，部分实例的日志会写入失败，需要重试后才能上报，这一情况在高并发场景下出现概率会大幅提升。你可以在serverless.yml中配置日志流的命名规则，增加随机后缀避免冲突：

  provider:
    name: aws
    runtime: dotnet6
    logs:
      lambda:
        logStreamName: /aws/lambda/${self:service}-${sls:stage}-${random_int.suffix.result}
  

• CloudWatch服务端限流：当短时间内有大量日志上报请求时，CloudWatch会对PutLogEvents接口做限流，返回429错误，Lambda会默认重试上报但有重试次数限制，超过次数的日志就会丢失。你可以通过CloudWatch的Metrics查看对应日志组的PutLogEvents.Throttle指标，确认是否存在限流情况。
• C#特定的日志缓冲问题：如果你用的是Microsoft.Extensions.Logging之类的日志库，默认会开启日志缓冲，缓冲满或者进程退出前才会刷入标准输出。如果函数执行异常退出，缓冲内的日志不会被上报，就会出现日志断层。可以修改日志配置，将缓冲级别设为最低，或者在关键逻辑后手动调用logger.Flush()强制刷缓冲。

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