今天聊聊日志的日志事，都知道日志采集不是和成越多越好，也不是本咱越少越省心这个道理，那么如何平衡日志和成本的维人关系呢?

什么叫价值大于成本？简单说就是，这些日志在关键时刻能救你命的该何，那就得全量保存；那些只是平衡看起来有用，实际上99%的日志时间都在吃灰的，该省就省。和成

我踩过的本咱那些坑

先说说我犯过的蠢事儿吧。

刚开始做运维那会儿，维人老杨特别"勤奋"，该何恨不得把服务器上每个进程放的平衡每个屁都记录下来。结果呢？日志

存储成本直接爆表不说，光是和成在茫茫日志海里找一条有用的信息，就能让人头秃。本咱我记得有次凌晨三点接到告警，系统出故障了，我花了两个小时才从几十GB的debug日志里找到真正的错误信息。源码下载那感觉，就像在垃圾堆里找钻戒。

后来我又矫枉过正，想着既然全量不行，那就只保存ERROR级别的日志吧。结果呢？遇到一些诡异的问题，错误日志看起来很正常，但就是定位不到根因。最后发现，关键信息都在被我丢弃的INFO级别里。

这么折腾了几年，我才摸索出一套相对靠谱的策略。

我的分级采集心得

经过这么多年的试错，我把日志分成了四个等级：

(1) A级：生死攸关的日志

这类日志包括审计记录、交易流水、合规相关的。这些东西必须全量保存，而且保留期要长。为什么？因为出了事儿，这些就是你的救命稻草。法务找你要证据，审计来检查，免费源码下载你拿不出来就死定了。

(2) B级：排障必备的日志

主要是错误和异常堆栈。这些也得优先保留，毕竟出故障的时候，这些是最直接的线索。

(3) C级：业务监控类日志

这些通常是结构化的指标信息，比如接口响应时间、用户行为统计等。这类数据有一定价值，但不是每条都重要，可以按需保留。

(4) D级：调试追踪日志

这就是那些debug、trace级别的详细信息了。平时基本用不上，但调试的时候又离不开。我的策略是默认采样保存，需要的时候再开全量。

技术实现的一些门道

说完理论，WordPress模板来点实际的。我这些年用过不少工具，也写过不少脚本。

(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, 0 end1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.

对应的Fluent Bit配置：

复制[FILTER] Name lua Match * script sample.lua call sample1.2.3.4.5.

运行起来大概是这个效果：

复制[info] Lua filter: sampled 12 of 1200 events [info] Lua filter: kept 45 ERROR events1.2.

(2) 故障时一键切换全量

这个功能救过我好几次命。平时采样运行，出故障了立马切换到全量模式。

在Kubernetes环境里，我用这个命令快速切换：

复制$ kubectl -n logging set env daemonset/fluent-bit LOG_SAMPLE_RATE=1.01.

控制台会显示：

复制daemonset.apps/fluent-bit updated ...1.2.

问题解决后，再切回来：

复制$ kubectl -n logging set env daemonset/fluent-bit LOG_SAMPLE_RATE=0.011.

(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 "http://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" fi1.2.3.4.5.

这样平时保持低成本运行，有问题的时候自动切换到全量模式，既省钱又不会漏掉关键信息。