日志成本治理：从全量收集到分级采集

日志是排障的生命线，也是账单的隐形大户

日志系统常见的发展轨迹：初期全量收集（反正便宜）→ 服务数量翻十倍后日志量爆炸 → 存储/索引成本超过 APM 与监控的总和 → 排障时反而在海量噪音里找不到关键行。日志治理的目标不是「少存」，是「让每一字节都可能在排障时被用到」。一、分级采集策略

按日志的价值分四级处理：

1. ERROR/WARN：全量保留，保留期最长（90 天+），这是排障的主证据链；
2. 关键业务 INFO：全量保留但保留期中等（14~30 天）：订单状态变更、支付回调、权限变更——审计与业务追溯需要；
3. 常规 INFO：采样或改指标：高频的请求成功日志（QPS 上万时每条都存纯属浪费）——统计价值改成指标（QPS/耗时直方图），样本价值按 1%~10% 采样；
4. DEBUG：默认关闭，按需动态开启（配置中心推送 + 自动 10 分钟回收），排障时才打开目标服务的 DEBUG。

二、结构性减肥（往往省一半）

1. 砍掉重复字段：日志里带上的 MDC 上下文（traceId、uid）保留，静态重复文案（类名全路径、框架横幅）去除；
2. 堆栈去重：同一异常在全链路被打印 5 遍（各层都 catch 再 log）——约定「谁处理谁打印」，未处理的异常由顶层统一记录；
3. 大字段截断：请求/响应体日志截断到合理长度，大报文存对象存储引用而不是日志索引；
4. 格式收敛：JSON 结构化日志统一 schema，索引字段数控制住——日志系统的索引成本与字段数强相关，一个 40 字段的 JSON 比同长度的纯文本贵得多。

三、保留期与冷热分层

1. 热数据（0~7 天）：可检索索引存储，排障主力；
2. 温数据（7~30 天）：压缩归档到对象存储（原始日志按天打包），需要时临时检索；
3. 冷数据（30 天+）：只保留审计要求的关键日志，其余删除；
4. 成本可见：按服务/团队做日志量与成本分账（CLS/ELK 都支持按索引拆分），成本归属清晰后，各团队会自发减肥——这是最有效的治理杠杆。

四、验收与持续运营

治理效果看三个数：日志总量降幅（通常能降 50%~80%）、排障关键日志的查全率（ERROR 无遗漏）、单条日志平均成本。日志治理不是一次性项目——新服务接入时的「日志规范检查」、每季度的日志量 review，把它变成常态化的卫生工作。

日志治理的本质是信息论：留信息量最高的部分，丢弃可再生的部分。分级、减肥、分层、分账四板斧砍下去，日志系统重新变回「又便宜又好用」。