今天来聊聊日志管理这个让很多运维工程师头疼的话题。我们都明白日志收集并非数量越多越好，当然也不是越少越省心——那么如何在日志价值和存储成本之间找到最佳平衡点呢？
关于日志采集，有个简单却深刻的道理：关键日志在关键时刻能救你于水火，这类数据必须全力保存；而那些看似有用、实际上99%时间都在沉睡的数据，该舍弃时就要果断舍弃。
什么叫价值大于成本？简单来说，就是在系统出故障时，这些日志能否帮你快速定位问题根源。
我踩过的那些坑
先说说我亲身经历的教训吧。
刚开始做运维那会儿，我特别“勤奋”，恨不得把服务器上每个进程的每个操作都记录下来。结果呢？
存储成本直接爆表不说，光是在茫茫日志海里找一条有用信息，就足以让人崩溃。记得有次凌晨三点接到报警，系统出了故障，我花了两个小时才从几十GB的debug日志里找到真正的错误信息。那感觉，就像在垃圾堆里翻找一枚小小的钻戒。
后来我又走向另一个极端，想着既然全量不行，那就只保存ERROR级别的日志吧。结果呢？遇到一些诡异的问题时，错误日志看起来一切正常，就是定位不到根因。最后发现，关键信息都在被我丢弃的INFO级别里。
这么折腾了几年，我才摸索出一套相对靠谱的策略。
我的分级采集心得
经过这么多年的试错，我把日志分成了四个等级：
(1) A级：生死攸关的日志
这类日志包括审计记录、交易流水、合规相关的数据。这些东西必须全量保存，而且保留期要足够长。为什么？因为一旦出事，这些就是你的救命稻草。法务找你要证据，审计来检查，你拿不出来就死定了。
(2) B级：排障必备的日志
主要是错误和异常堆栈。这些也得优先保留，毕竟出故障的时候，这些是最直接的线索。
(3) C级：业务监控类日志
这些通常是结构化的指标信息，比如接口响应时间、用户行为统计等。这类数据有一定价值，但不是每条都重要，可以按需保留。
(4) D级：调试跟踪日志
这就是那些debug、trace级别的详细信息了。平时基本用不上，但调试的时候又离不开。我的策略是默认采样保存，需要的时候再开全量。
技术实现的一些门道
说完理论，来点实际的。我这些年用过不少工具，也写过不少脚本。
(1) 动态采样这招真好用
我现在用的是Fluent Bit配合自己写的Lua脚本来做采样。比如这个概率采样的脚本：
function sample(tag, timestamp, record)
-- 正常情况下采样1%
local p = 0.01
-- 如果是错误日志，100%保留
if record['level'] == 'ERROR' or record['level'] == 'FATAL' then
return 1, timestamp, record
end
-- 其他按概率采样
math.randomseed(os.time() + tonumber(tostring(record['request_id']]):sub(-4), 10))
if math.random() < p then
return 1, timestamp, record
end
return 0, 0, 0end对应的Fluent Bit配置：
[FILTER]
Name lua
Match *
script sample.lua
call sample运行起来大概是这个效果：
[info] Lua filter: sampled 12 of 1200 events[info] Lua filter: kept 45 ERROR events(2) 故障时一键切换全量
这个功能救过我好几回命。平时采样运行，出故障了立即切换到全量模式。
在Kubernetes环境里，我用这个命令快速切换：
$ kubectl -n logging set env daemonset/fluent-bit LOG_SAMPLE_RATE=1.0控制台会显示：
daemonset.apps/fluent-bit updated...问题解决后，再切回来：
$ kubectl -n logging set env daemonset/fluent-bit LOG_SAMPLE_RATE=0.01(3) 成本控制要算清楚账
老杨给你算笔账。假设你们公司有200台服务器，每台每天产生0.5GB日志。
日总量：200台 × 0.5GB = 100GB/天月总量：100GB × 30天 = 3TB/月
如果存储价格按0.2元/GB·月算（这还只是存储，不包括索引和查询费用）：3000GB × 0.2元 = 600元/月
这还没算索引费用呢，实际成本可能要翻倍。所以你得想想，这些日志到底值不值这个钱。
我现在的保留策略
经过这么多年的摸索，我现在的策略是这样的：
审计和交易日志：全量保存90天以上，有些甚至要保存几年错误异常日志：全量保存30天，这个时间基本够排查大部分问题了业务info日志：结构化后保留7-30天，看具体业务重要程度调试trace日志：采样1%-10%，保留1-3天就够了
对于历史数据，我会压缩后放到对象存储里，需要的时候再取出来分析。
监控联动让采集更智能
现在我还加了个智能的东西——用监控指标来触发采集策略。
比如当某个服务的错误率超过阈值时，自动把这个服务的日志采样率调整到100%：
# 这是我写的一个简单监控脚本的片段if [ $(curl -s "https://prometheus:9090/api/v1/query?query=error_rate{service=\"$service\"}" | jq -r '.data.result[0].value[1]') -gt 0.01 ]; then
kubectl -n logging set env daemonset/fluent-bit LOG_SAMPLE_RATE_${service^^}=1.0
echo "Service $service error rate elevated, switched to full logging"fi这样平时保持低成本运行，有问题的时候自动切换到全量模式，既省钱又不会漏掉关键信息。
