日志的可读性：从堆量转向可追溯

没有上下文的日志等于噪声

一行写着处理失败的日志，若不包含请求标识、输入摘要与所处阶段，几乎无法定位。等到需要排查时，只能靠时间戳去猜相邻记录属于同一次调用。

解决方式是在入口生成追踪标识，并让它贯穿所有下游调用。跨服务传递时通过请求头携带，异步任务则写入任务元数据，让任何环节都能回溯到起点。

级别划分要克制

把一切异常都记为错误，会让告警失去意义。比较合理的划分是：需要立刻有人处理才算错误，可自动恢复的归为警告，描述正常流程进展的用信息级。

调试级日志应当按需开启而非默认全开。长期全量输出不仅增加存储成本，也会拖慢写入路径，在高峰时段放大延迟。

结构化优于自由文本

固定格式的字符串便于人读，却不利于检索。把关键字段拆成独立属性，查询时可以直接过滤与聚合，无需依赖正则匹配。

折中做法是保留一句人读摘要，同时附上结构化字段。排查时先看摘要快速理解，再看字段做精确筛选，两者互补。

采样与保留策略

高流量场景下全量保留并不现实。常见做法是对正常请求按比例采样，对异常请求全量保留，兼顾成本与可用性。

保留期限要分层：近期数据支持细粒度查询，历史数据只保留聚合结果。这样既能追溯当天问题，也能观察长期趋势，而不必为冷数据支付热存储的价格。

日志也会泄漏信息

把完整请求体写进日志是常见疏漏。一旦包含身份信息或凭证片段，日志系统本身就成了风险点。写入前应做脱敏，对敏感字段只记录长度或哈希。

同时要限制访问范围。日志的查阅权限应与生产数据同级管理，避免为了排查方便而放宽到全体可见。