备案站点的日志规范与集中检索实践

出事时真正的问题不是没日志，而是捞不出来

故障发生后最常见的场景是：几个人同时 SSH 到不同机器上 grep，一个人找到半条线索，另一个人在另一台机器上找到另外半条，二十分钟后才拼出完整链路。日志不是写出来就算数的，能不能在三分钟内定位到那一条才算数。

关键要点

• 日志必须结构化（一行一个 JSON 或固定字段），否则检索只能靠正则硬扫。
• 每条日志都要带请求 ID，这是把一次请求在多个服务、多台机器上的记录串起来的唯一办法。
• 采集链路要考虑背压：日志暴增时，宁可丢采样也不能把应用拖垮。
• 保留策略必须分级，全量长期保留的成本会失控。

结构化日志的最小字段集

字段	作用	缺失后果
时间戳（含时区）	排序与对齐	多机日志无法拼时间线
级别	过滤噪声	告警规则没法写
请求 ID / trace ID	串联一次调用	只能靠时间猜关联
服务名 + 实例	定位到具体机器	不知道是哪台在报错
用户或业务主键	按单据回溯	用户投诉无法复现
耗时	找慢点	只知道错了不知道慢在哪

请求 ID 要在入口生成、随调用链一路透传，并写进每一条日志，这和链路追踪是同一套上下文，见 可观测性建设。

日志级别：多数团队都在误用

• ERROR：需要人介入处理的问题。写多了必然没人看，这是告警疲劳的源头。
• WARN：降级、重试、命中兜底——现在还能转，但需要关注。
• INFO：关键业务动作与状态变更，不是给每个函数都打一行。
• DEBUG：默认关闭，线上按开关临时打开。

一个可执行的判断标准：如果一条 ERROR 出现时没有任何人需要做任何事，它就不该是 ERROR。

采集链路与「丢日志」

典型链路是：应用写本地文件 → 采集器读取 → 传输 → 存储 → 检索。每一段都可能丢：

环节	丢日志原因	对策
应用	同步写阻塞、缓冲区满	异步写 + 有界队列，满了丢 DEBUG
本地文件	轮转过快被覆盖	按大小轮转并留足份数
采集器	进程挂了、位点丢失	监控采集器自身、位点持久化
存储	写入限流、磁盘满	容量告警 + 降采样

最关键的一条原则是日志系统绝不能反向拖垮业务：应用侧写日志必须是异步且有界的，后端写不进去时丢弃低价值日志，而不是阻塞业务线程。

保留与成本：按价值分级

类型	建议保留	说明
访问日志	依合规要求	留存义务见下文
应用错误日志	1～3 个月	排障主力
DEBUG / 调试日志	数天	只在需要时开
审计与操作日志	长期	权限与操作留痕

访问日志的留存期限有明确合规要求，不能只按成本决定，见 网站访问日志留存要求；运维操作的审计留痕见 运维权限治理与操作审计。存储成本随日志量线性增长，要纳入成本盘点，见 服务器资源与成本治理。

脱敏：日志是最容易泄密的地方

密码、令牌、身份证号、手机号、银行卡号一旦进了日志，就等于把敏感数据复制到了一个权限管理通常更松的系统里。落地做法：

• 在日志输出层统一做脱敏（中间掩码），而不是指望每个人记得。
• 请求体、响应体默认不打全量，只打字段名与长度。
• 凭据类字段进白名单强制屏蔽，密钥管理见 密钥与凭据管理。

常见坑

• 日志无请求 ID：跨服务排查只能靠时间猜。
• 全部打成 ERROR：告警变噪声，真故障被淹没。
• 同步写日志：磁盘一慢，接口全部超时。
• 异常只打 message 不打堆栈：看得见错，找不到行。
• 把日志当监控用：指标该用指标系统，见 备案网站监控告警体系。

常见问题

日志量太大存不起，应该怎么砍？

先按价值分级而不是一刀切降级：错误日志与审计日志优先保留，访问日志按合规期限保留，DEBUG 与高频成功日志做采样。对成功请求做 1% 采样、对失败请求全量保留，通常能砍掉大部分存储量而几乎不影响排障。

为什么强调请求 ID 比强调日志内容更重要？

因为一次请求可能跨越网关、应用、数据库和多个下游，单条日志再详细也只是局部。请求 ID 能把这些碎片按一次调用聚合起来，排查时间通常从几十分钟缩短到几分钟。

日志里已经写了敏感信息，怎么补救？

先在输出层加上脱敏止住新增，再按保留策略让存量自然过期；若涉及凭据泄露，必须立即轮换对应密钥，仅删日志是不够的。

本地 grep 和集中检索必须二选一吗？

不必。集中检索用于跨机器、跨时间的定位，本地日志保留数天用于深挖细节，两者互补。但只有本地日志时，多实例环境下的排查效率会急剧下降。

资料来源

主流日志采集与检索方案（如 Filebeat、Fluent Bit、Loki、Elasticsearch）官方文档中关于结构化日志、背压与保留策略的公开说明。本文为通用运维说明，仅供参考，具体以实际日志架构与合规要求为准。