.NET Core 2.1 Lambda用NLog对接CloudWatch日志异常求助

让我们一步步拆解你的问题——先从那个Read-only file system异常入手，这大概率是日志丢失的核心诱因之一，再结合Lambda的特性和NLog的配置来逐一排查：

一、先解决Read-only file system异常 #

你提到默认Lambda日志组出现这个异常，虽然你没配置NLog的文件目标，但可能有几个隐藏点：

• NLog配置加载时的临时文件操作：你在每次Lambda调用时用new XmlLoggingConfiguration($"nlog.Consumer.{environmentName}.config")加载配置，NLog在解析配置文件时可能会尝试生成临时缓存文件，而Lambda的文件系统大部分路径是只读的。
  • 解决办法：把NLog配置文件嵌入为程序集资源，直接从内存加载配置，避免文件系统操作。比如：

    // 先把nlog配置文件设置为Embedded Resource
    var configStream = Assembly.GetExecutingAssembly().GetManifestResourceStream($"YourNamespace.nlog.Consumer.{environmentName}.config");
    LogManager.Configuration = new XmlLoggingConfiguration(configStream, null);
    

• 意外启用的默认日志目标：虽然你用了loggingBuilder.ClearProviders()，但要确认NLog本身有没有默认启用文件目标。可以开启NLog内部日志（后面会说）来排查配置加载细节。

二、日志间歇性丢失的核心排查点 #

1. AsyncWrapper的异步日志未完成就终止Lambda #

你用了AsyncWrapper，但Lambda的执行生命周期很短，默认情况下LogManager.Shutdown()可能不会等待异步日志发送完成。

• 修改AsyncWrapper配置，添加shutdownTimeout确保足够等待时间：

  <target name="CloudwatchErrorTargetAsync" xsi:type="AsyncWrapper" overflowAction="Block" shutdownTimeout="30000">
  

• 改用异步Shutdown：如果你的NLog版本≥4.6，把finally块里的LogManager.Shutdown()换成await LogManager.ShutdownAsync()，确保等待所有异步日志任务完成后再结束Lambda。

2. CloudWatch日志流限流 #

CloudWatch每个日志流的写入限制是每秒10条事件，你的Lambda预留并发是100，如果所有实例都往同一个日志流写，很容易触发节流，导致日志丢失。

• 为AWSTarget配置独立的日志流：利用Lambda上下文的LogStreamName，让每个Lambda实例的日志流唯一。修改AWSTarget的配置：

  <target name="CloudwatchErrorTarget" type="AWSTarget" 
          logGroup="/aws/lambda/adx-dev-batch-processor-consumer-error" 
          region="eu-west-2" 
          logStreamName="${lambda:LogStreamName}"
          layout="${longdate}|${uppercase:${level}}|${logger}|${message} ${exception:format=tostring}"/>
  

  （需要确保NLog.AWS.Logger版本支持${lambda:LogStreamName}布局渲染器，或者手动从ILambdaContext获取LogStreamName并设置到NLog的MDC中）

3. NLog初始化时机错误 #

你在每次Lambda调用时重新加载NLog配置，而Lambda是复用容器的，多次初始化会导致日志实例冲突，甚至丢失日志。

• 把NLog初始化移到静态构造函数里，只在冷启动时执行一次：

  public class QueueConsumerLambda {
      private const string AspnetCoreEnvironmentVariable = "ASPNETCORE_ENVIRONMENT";
      private IServiceProvider _serviceProvider;
  
      static QueueConsumerLambda() {
          var environmentName = Environment.GetEnvironmentVariable(AspnetCoreEnvironmentVariable);
          // 这里用嵌入资源加载配置，避免文件系统问题
          var configStream = Assembly.GetExecutingAssembly().GetManifestResourceStream($"YourNamespace.nlog.Consumer.{environmentName}.config");
          LogManager.Configuration = new XmlLoggingConfiguration(configStream, null);
      }
  
      // 剩余代码...
  }
  

4. 异常被内部吞掉 #

你提到本地调试能触发异常，但Lambda里没日志，可能是GetData方法内部捕获了异常却没有重新抛出或记录：

• 检查QueueConsumerController.GetData的代码，确保所有异常要么抛到外层，要么在内部用NLog记录错误日志；
• 在foreach循环里添加try-catch，单独捕获单条消息的处理异常，避免一条消息失败导致整个批次的日志丢失：

  foreach (var record in sqsEvent.Records) {
      try {
          logger.Trace($"QueueConsumer.ProcessQueueMessage - messageId: {record.MessageId}, eventSource: {record.EventSource}, record.Body: {record.Body}");
          var messageBody = JsonConvert.DeserializeObject<SqsMessageModel>(record.Body);
          await dataRetrievalController.GetData(messageBody, record.ReceiptHandle);
      } catch (Exception ex) {
          logger.Error(ex, $"Failed to process message {record.MessageId}");
          // 根据业务逻辑决定是否继续处理下一条消息
      }
  }
  

三、辅助排查工具 #

• 开启NLog内部日志：在NLog配置里添加内部日志输出到控制台（Lambda默认日志组），可以看到NLog自身的错误（比如CloudWatch发送失败、配置加载错误）：

  <nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
        throwConfigExceptions="true"
        internalLogLevel="Debug"
        internalLogToConsole="true">
  

• 检查CloudWatch指标：进入你的CloudWatch日志组，查看ThrottledLogEvents指标，如果有数值，说明确实是CloudWatch限流导致的日志丢失；
• 单条消息测试：用少量（比如10条）消息测试，确认日志是否正常写入，排除并发和批量处理的影响。

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