工程效率与质量 / 进阶

结构化日志落地：从 requestId 一路追到后台任务

统一字段、传递上下文并控制敏感信息，让日志真正支持跨服务检索和故障定位。

8 分钟日志 · OpenTelemetry · Trace · 可观测性

一条日志就是一个可查询事件

拼接字符串适合人眼，却不利于机器聚合。使用 JSON 输出固定字段：时间、级别、服务、事件名、请求标识和业务实体标识。message 用于阅读，event 和 error.code 用于稳定查询。

EXAMPLE / 01日志

{
  "level": "warn",
  "event": "order.create.rejected",
  "service": "order-api",
  "requestId": "req_01HQ",
  "traceId": "4bf92f...",
  "orderId": "ord_42",
  "errorCode": "STOCK_NOT_ENOUGH"
}

上下文要跨过异步边界

入口网关生成或接收 requestId，并通过 HTTP 头传给下游。消息生产者把 trace context 和业务关联 ID 写进消息属性，消费者恢复上下文后再记录日志。后台任务没有用户请求，也应拥有 jobId 和独立 trace。

所有服务使用统一字段名和时间格式；HTTP 与消息队列都传播 trace context；异常日志保留 stack 和稳定错误码；日志可跳转到对应 trace。

默认不记录敏感信息

密码、令牌、Cookie、身份证号和完整支付信息不应进入日志。对请求体采用字段白名单，在日志库中配置递归脱敏，并用测试验证嵌套对象不会漏出。高基数字段只在确有排查价值时保留。

debug 日志也可能含敏感数据。访问权限、保存周期和脱敏规则应对所有级别一致生效。