部署到AWS Lambda后Serilog的PostgreSQL sink无法写入是什么原因？

• Serilog的PostgreSQL sink默认采用异步批量写入机制，会缓存日志事件，攒到指定条数/间隔时间后才批量写入数据库。AWS Lambda执行环境在请求处理完成返回响应后会立即被暂停/冻结，根本等不到sink的默认刷写时机，缓存的日志就会直接丢失。
• Console sink是同步输出，Lambda会实时采集控制台输出到CloudWatch，因此不受影响。你的数据访问层能正常写入，是因为业务逻辑中的数据库操作是同步/await执行完成后才返回响应，不会被冻结打断。
• 自定义ILogger出现同样问题，本质也是同理：只要日志写入逻辑用了批量缓存、后台线程异步写入，没有在请求返回前完成执行，就会被Lambda的冻结机制打断。

1. 调整PostgreSQL sink写入参数 #

关闭默认批量攒批逻辑，强制日志实时触发写入：

Log.Logger = new LoggerConfiguration()
    .MinimumLevel.Information()
    .MinimumLevel.Override("Microsoft", LogEventLevel.Warning)
    .MinimumLevel.Override("System", LogEventLevel.Warning)
    .Enrich.FromLogContext()
    .WriteTo.Console()
    // 调整PostgreSQL sink参数
    .WriteTo.PostgreSQL(
        connectionString, 
        TableName, 
        columnWriters,
        batchPostingLimit: 1, // 每条日志立刻触发写入，不攒批
        period: TimeSpan.Zero, // 取消间隔等待
        queueLimit: 1000
    )
    .CreateLogger();

2. 手动强制刷写日志缓存 #

在请求处理的生命周期末尾加刷写逻辑，确保所有缓存日志落库后再返回响应：
如果是ASP.NET Core托管的Lambda，新增全局中间件：

public class SerilogFlushMiddleware
{
    private readonly RequestDelegate _next;

    public SerilogFlushMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        try
        {
            await _next(context);
        }
        finally
        {
            // 强制刷写所有缓存的日志
            if (Log.Logger is IFlushableLogger flushable)
            {
                flushable.Flush();
            }
        }
    }
}

在Program.cs的请求管道最前面注册中间件：

app.UseMiddleware<SerilogFlushMiddleware>();

如果是原生Lambda函数（非ASP.NET Core托管），直接在函数处理逻辑的finally块中加入上述刷写代码即可。

3. 开启Serilog自我日志排查隐藏错误 #

Serilog默认会吃掉sink的异常避免影响业务，开启自我日志可以在CloudWatch中查看PostgreSQL sink是否有报错：

// 放在LoggerConfiguration配置之前
Serilog.Debugging.SelfLog.Enable(msg => Console.WriteLine($"Serilog内部错误：{msg}"));

4. 自定义ILogger适配方案 #

自定义ILogger不要使用后台线程、延迟批量写入逻辑，所有日志写入操作要同步await执行完成，再结束请求处理流程。

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