为什么日志重要

指标告诉你"出问题了"，日志告诉你"为什么"。

在排查线上问题时，日志往往是最直接、最有价值的证据来源。

结构化日志

非结构化：

2026-08-29 10:23:45 用户 zhangsan 登录失败

人能读，但机器难以解析和检索。

结构化（如 JSON）：

{
  "timestamp": "2026-08-29T10:23:45+08:00",
  "level": "WARN",
  "event": "login_failed",
  "user": "zhangsan",
  "ip": "192.168.1.100",
  "reason": "invalid_password"
}

优势：可以被索引，支持结构化查询（"找出所有 reason=invalid_password 且 ip 属于某个网段的记录"），也能做聚合分析。

日志级别

  • ERROR：错误，需要关注（如请求失败、外部调用异常）；
  • WARN：警告，潜在问题（如重试成功、降级触发）；
  • INFO：正常运行的关键信息（如服务启动、重要状态变更）；
  • DEBUG：调试信息，生产环境通常关闭。

建议：

  • 级别要有明确约定，不要所有东西都打 INFO；
  • ERROR 应该是"需要有人处理"的，而不只是"出问题了"（如果 ERROR 太多，就没人看了）。

该记什么

一、请求标识（Trace ID / Request ID）

每个请求生成一个唯一 ID，贯穿整个处理过程（包括跨服务调用）。

有了它，就能把一次请求在所有服务中的日志串联起来——这是排查分布式系统问题的关键。

二、关键业务事件

下单、支付、发货、权限变更等。这些日志有时用于审计和业务分析。

三、外部依赖调用

调用时间、耗时、状态码、是否重试。

四、异常堆栈

但要小心：重复的堆栈会淹没日志。可以考虑聚合同类异常。

不该记什么

敏感信息——这是最重要的红线：

  • 密码、令牌、密钥（即使加密后的也不应记录）；
  • 身份证号、手机号、银行卡号（除非必要且脱敏）；
  • 完整的信用卡信息。

为什么会出问题：很多人习惯性地打 log.info("request: " + request)，而 request 对象中可能包含密码字段。

做法：

  • 在日志框架层面配置脱敏规则；
  • 对象的 toString 方法要避免输出敏感字段；
  • 定期审查日志中的敏感数据（可用自动化扫描）。

日志的生命周期

采集：从应用输出到文件或标准输出，再由采集代理（如 Filebeat、Fluent Bit）收集。

传输：经过缓冲（如 Kafka）送到存储。

存储与索引：专用的日志系统（如 Elasticsearch、Loki）。

保留策略：日志量增长很快，需要分级保留：

  • 热数据（最近几天）：完整索引，可快速查询；
  • 温数据（几周）：压缩存储，查询较慢；
  • 冷数据（数月到数年）：归档到对象存储，满足合规要求，需要时再恢复。

两个实践建议

一、日志是给人看的，不是给自己看的。

写日志时想象：凌晨三点，另一个人拿着这条日志排查问题，他能看懂吗？他知道该怎么处理吗？

二、控制日志量。

日志过多会带来：存储成本、检索性能下降、噪音淹没关键信息。

在高频路径上打印日志要格外谨慎——一个每毫秒打一条的日志，很快就能填满磁盘。

说明：本文为可观测性实践的知识整理。