降低日志成本七步法：在不牺牲可观测性的前提下控制账单
日志成本失控往往源于"什么都记、永久留存"。本文给出七步降本法：测算成本、削减日志量、采样、留存策略、错误日志限流、摄入量告警、平台重估，并结合观测云黑名单、多索引与数据转发给出落地操作。
降低日志成本的核心思路是：在"保留排障所需数据"和"控制摄入与存储开销"之间找到平衡点。 关键认知是——成本优化不是简单地把日志砍掉，而是系统性地识别并消除低价值数据，让每一分日志预算都花在刀刃上。
核心要点速览
- 先测算成本构成（摄入、存储、查询、人力），再动手优化；
- 最高效的降本是不记不需要的日志，其次才是采样与留存治理；
- 错误风暴时用限流防止日志量与账单双双失控；
- 观测云三板斧：黑名单降噪、多索引差异化存储、数据转发归档；
- 为日志摄入量建监控，成本异常先于账单被发现。
第一步：先测算你的日志成本
优化前先搞清钱花在哪。逐项盘点：
- 当前日志摄入量（GB/天）与平台摄入单价；
- 存储成本：留存时长 × 存储单价；
- 查询成本：部分平台对扫描量计费；
- 自建链路的隐性成本：Kafka 等中间件、网络传输费、采集器运维人力。
找到成本大头，才能对症下药——多数团队的答案都是"摄入量太大"。
第二步：削减日志量
最直接的降本是删掉不需要的日志：
- 真的需要记录所有请求吗？ 不需要请求级审计时，只记 5xx 错误请求即可；
- 用日志回答的问题是不是该交给指标？ "QPS、错误率、热门路由"这类问题用指标（Metrics）回答，既便宜又高效；
- 级别设对了吗？ 生产环境从 INFO 上调到 WARN，只关注异常，需要细节时动态调整（见本系列第 10 篇）。
观测云落地：用黑名单把健康检查、心跳等已知无效日志在采集端直接过滤，不摄入、不计费 。
第三步：引入日志采样
对剩余的高频日志按比例保留代表性子集。建议把它作为事前内建的默认实践，而不是成本失控后的事后补救——后者的推行阻力大得多。按级别差异化采样：INFO 激进采样，ERROR 完整保留。详见本系列第 16 篇。
第四步：配置合理的留存策略
评估日志价值随时间的衰减曲线：排障价值集中在最近几天，一周后鲜有人问津。据此设定最短必要留存期，并随业务节奏动态调整（大版本发布前后可适当延长）。
到期不等于删除：审计与复盘需要的日志归档到低成本对象存储。观测云落地：创建多索引，按业务线为不同日志配置差异化存储策略（标准/低频/归档），到期自动清理；需要长期留存的通过数据转发归档，必要时可重新查询 。
第五步：给错误日志限流
故障期间，同一个错误可能每秒刷出几千条带堆栈的日志——信息量为零，账单却很真实。对策：同一错误消息超过阈值后停止重复记录（如每分钟最多 N 条），既保住诊断信息，又让故障期间的成本可预测。框架支持时优先在应用内实现；不支持时可在采集管道层用规则丢弃重复日志。
第六步：为日志摄入量设置告警
成本失控往往在账单到达时才被发现——太晚了。主动做法：把日志摄入量本身作为监控对象。
观测云落地：创建工作空间级的用量监控，日志摄入量短时突变（如环比增长 N 倍）即触发告警，经钉钉/企微/飞书通知 。常见诱因：某服务临时开 DEBUG 忘记关回、新上线的服务日志过于啰嗦、故障引发错误风暴——每个都值得立即介入。
第七步：重新评估平台方案
如果做完前六步成本仍不可接受，问题可能出在平台定价模型上。评估维度：按摄入计费还是按存储计费、有无免费额度、能否按来源设置差异化留存、是否支持灵活的降噪工具。避免厂商锁定也是长期成本的一部分——选择支持开放采集协议（DataKit 为开源采集器）的平台，迁移成本可控。
总结
七步的内在线索是：先度量、再减量、然后治理留存、最后兜底监控。成本优化不是一次性项目，而是随业务量变化持续调整的运营动作。建议每季度按这七步走一遍检查清单。
常见问题（FAQ）
Q：削减日志会不会在关键时刻缺数据？
关键在"削什么"：削的是重复、低价值、可被指标替代的日志；错误日志与关键业务事件完整保留。配合哈希采样，被保留请求的日志链依然完整。
Q：留存多久算合理？
排障热数据 7–30 天是常见区间；合规审计按法规要求（通常以年计）归档到对象存储。观测云多索引可以为不同日志各配各的留存期。
Q：团队习惯"全都记"，推不动减量怎么办？
用数据说话：先跑第一步的成本测算，把"摄入量 Top 10 的低价值日志及其月成本"摆出来，共识会容易得多。
