Serilog如何从结构化日志认知到.NET工程中完美落地？

问题背景 很多项目不缺日志，缺的是有用的日志。 平时接口跑得顺，大家都觉得日志够用。真到线上出问题，日志的短板会一下子暴露出来。 比如订单接口偶发超时，日志里只剩这么一句： Create order failed for customer 1024, cost 3800ms, trace abc123 这种日志平时看着还行，真到线上排障时基本帮不上太多忙： 你没法直接按 CustomerId、TraceId、ElapsedMs 做过滤和聚合，只能全文搜索 同一个字段今天写 customerId，明天写 userId，后天又换成 client_id，查询条件根本沉淀不下来 想统计某类错误的数量、平均耗时、失败占比，往往还得写额外脚本二次清洗 日志平台能做的分析能力很弱，因为它拿到的只是一段文本，不是一条可分析的数据 问题往往不在于日志打得不够多，而在于日志从一开始就没按可检索、可聚合、可关联的方式去设计。 传统文本日志更像写给人看的备注，结构化日志才像写给系统消费的数据。业务一旦进入多人协作、线上排障、统一观测这些阶段，日志就不再只是打出来看一眼，而是排障、审计、告警、指标补充、链路追踪的一部分。走到这一步，结构化日志就不是锦上添花，而是该补的基础课。 原理解析 什么是结构化日志 很多人第一次接触结构化日志，会下意识把重点放在 JSON 输出上。其实 JSON 只是表现形式，核心不在日志长什么样，而在日志里的字段有没有明确语义，后续能不能被系统稳定识别。 先看两种写法的差异。 普通文本日志： logger.LogInformation( $"Order {order.Id} created for customer {order.CustomerId}, amount {order.Amount}, cost {elapsedMs}ms" ); 这行代码最终只会产出一段字符串。人类看没问题，但日志平台拿到以后，并不知道哪一段是订单号，哪一段是金额，哪一段是耗时。 结构化日志： logger.LogInformation( "Order {OrderId} created for customer {CustomerId}, amount {Amount}, cost {ElapsedMs}ms", order.Id, order.CustomerId, order.Amount, elapsedMs ); 换成这种写法以后，日志框架记录的就不再是一整段普通字符串，而是一个日志事件： 模板是 Order {OrderId} created for customer {CustomerId}, amount {Amount}, cost {ElapsedMs}ms 属性是 OrderId、CustomerId、Amount、ElapsedMs 元数据还包括时间、级别、异常、来源、线程、TraceId 这些上下文 输出到控制台时，它可以渲染成人能直接看的句子；送到 Elasticsearch、Seq、Loki 或 OpenTelemetry 后端时，它又能以字段化数据的形式被检索和聚合。 所以，结构化日志本质上是事件加字段，不是把日志换个更漂亮的格式。 为什么需要结构化日志 结构化日志真正解决的，是文本日志进入工程化阶段以后暴露出来的几个硬伤。 1. 检索成本高 文本日志适合肉眼翻看，不适合机器分析。字段埋在句子里，检索通常依赖模糊匹配或者正则，成本高，也不稳定。 一旦日志天然带字段，排查动作会直接从翻文本变成查数据： 按 TraceId 找一条请求的全链路日志 按 OrderId 找某一笔订单的状态变化 按 StatusCode = 500 统计最近 10 分钟的异常峰值 按 ElapsedMs > 3000 过滤所有慢请求 这些动作放在文本日志里都挺别扭，放在结构化日志里反而是最基础的用法。 2. 字段不稳定，团队协作成本高 同一个业务含义，如果今天有人写 customerId，明天有人写 userId，后天又有人写 client_id，日志系统就很难形成稳定查询。 结构化日志还有一个很现实的价值，它会逼着团队把字段契约慢慢收敛下来，比如： TraceId 表示链路标识 OrderId 表示订单标识 UserId 表示当前登录用户 ElapsedMs 表示耗时，统一按毫秒记录 一旦字段稳定下来，排障脚本、监控规则、仪表盘、告警条件都能复用。 3. 无法自然接入可观测体系 现在的日志通常不会单独存在，而是要和指标、链路追踪一起工作。