日志太多存不起？云上日志采样与成本优化实战
去年一个客户，微服务架构，每天日志量几个TB。日志存满30天，每月存储费用好几万。老板问：“能不能省点？”技术负责人说：“全量日志不能少，出了事要靠它排查。”
后来我们帮他算了一笔账：过去半年，真正用到的日志只有两类——报错的ERROR日志和慢请求的调用链日志。剩下的INFO、DEBUG日志，没人查过。全量存了半年，90%的日志从来没被读过。
这是日志管理最常见的困境：存了怕贵，不存怕出事。
今天聊聊云上日志采样与成本优化。不是那种“日志很重要”的入门课，而是帮你理清楚：怎么采样不丢关键信息？怎么分级存储？怎么省钱又不影响排查？
01 全量日志不等于安全
很多人有个错觉：日志存得越全越安全。错。
存了全量但不分析，等于浪费。爆款游戏的服务器日志，存了TB级，出事了根本查不过来。
全量日志增加存储成本、查询成本、传输成本。
时间长了，想删不敢删，想查查不动。
那家客户把INFO和DEBUG日志全量存了半年，从没查过。真正排查问题用的是ERROR日志和慢请求的Trace。90%的存储成本，花在了从来不看的地方。
02 采样策略：不是随机丢
采样不是“均匀丢一半”。要保留有价值的数据。
头部采样（Head-based Sampling）：在请求入口处，按固定比例采样。比如10%的请求记录完整日志。适合流量均匀、不需要追踪每笔异常的场景。
尾部采样（Tail-based Sampling）：先不采样，等请求结束后判断是否有价值。ERROR、慢请求、异常请求全量保留；正常的请求采样。适合需要捕获异常、不关心正常流量的场景。开销较大，适合后台异步处理。
关键字采样：只保留包含特定关键字（ERROR、WARN、timeout）的日志。最简单，实现成本低。
一致性采样：基于Trace ID哈希，保证同一条调用链的所有日志被统一采样。要么全留，要么全丢。适合分布式系统排查。
03 采样率调优：多少合适？
没有固定答案，看业务。
ERROR日志：100%保留。出问题全靠它。
WARN日志：50-100%保留。取决于WARN是否频繁。
INFO日志：1-10%采样。核心业务可调高，非核心调低。
DEBUG日志：0%采样。只在调试时临时开启。
慢请求日志：100%保留。超过阈值的请求全量记录。
那家客户改造后：ERROR全量，WARN全量，INFO只采5%。慢请求（>500ms）全量记录。日志量从每天几TB降到300GB。排查能力没下降，因为出问题的都是ERROR和慢请求，INFO基本没用到。
04 分级存储：热温冷分层
不同时效的日志，存不同介质。
热存储（最近7天）：SSD/NVMe，快速查询。存需要频繁回溯的日志。
温存储（7-30天）：对象存储标准层级。存偶尔查询的日志，查询速度尚可。
冷存储（30天以上）：归档存储，查询慢但极便宜。存合规要求保留的日志。
生命周期策略：创建时存热存储，7天后自动转温存储，30天后自动转冷存储，1年后自动删除。
那家客户改造成本：日志月存储费用从好几万降到几千。热存储只存7天ERROR和慢请求，温存储存30天全量，冷存储存90天归档。查询慢请求时，热存储秒级返回；查历史合规日志时，冷存储恢复几小时可接受。
05 日志采样不是万能的
采样有代价。
可能丢失罕见问题：采样率1%，低频错误可能永远采不到。解法：ERROR日志不采样，全量保留。
排查链路不完整：头部采样可能导致同一条调用链部分日志采到、部分没采到。解法：用一致性采样，基于Trace ID哈希。
实时性要求高的场景不合适：采样需要判断逻辑，可能增加延迟。解法：离线采样，先存原始日志到低成本存储，再异步采样分析。
那家客户用尾部采样，请求结束后判断是否异常。异常请求全量存，正常请求采样1%。排查链路用一致性采样，同一条Trace要么全留要么全丢。
06 一个真实案例：每月省几千块
一个电商客户，大促期间日志量暴涨，存储费用扛不住。我们做了几件事：
改采样策略：ERROR/WARN全量，INFO从10%降到1%。慢请求（>1秒）全量保留
分级存储：热存3天（ERROR+慢请求），温存7天（WARN+部分INFO），冷存30天（全量归档）
启用日志生命周期策略，自动流转
次月日志费用降了60%。双11排查问题，用ERROR日志和慢请求日志，没受影响。运维负责人说：“以前觉得日志存少了会慌，现在知道存对地方就不慌。”
写在最后
日志成本优化，不是简单删日志。是“有价值的多存，没价值的少存”。
那家客户的运维负责人后来总结：“ERROR全量保留，INFO只采一点；热存查得快，冷存放归档；尾部采样抓异常，一致性采样保链路。”
你的日志，哪些该多存，哪些该少存？今天就去看看。
