日志和成本咱们运维人该如何平衡?

0. 写在前面：为什么你需要“神器”而非“常用命令

大家好,欢迎来到干货、技术、专业全方位遥遥领先的老杨的博客.

帮老杨点赞、转发、在看以及打开小星标哦

攒今世之功德,修来世之福报

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

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

我踩过的那些坑

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

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

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

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

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

我的分级采集心得

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

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

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

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

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

技术实现的一些门道

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

动态采样这招真好用

我现在用的是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
end

对应的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

故障时一键切换全量

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

在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

成本控制要算清楚账

老杨给你算笔账。假设你们公司有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"
fi

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

习惯性水结尾

运维人挑灯守夜，为亿万连接负重前行，机器轰鸣中，运维人以鲜血与诗意修补世界的脆弱，朝露未晞，使命已沉。 亿万方阵,任将帅坐帷帐指点江山,运维人护军旗立于风雨之夜.挽大厦于将倾,填江湖与决口.运维不死,只是慢慢凋零. 评论区等你们!

老杨时间

这里老杨先声明一下,日常生活中大家都叫老杨波哥,跟辈分没关系,主要是岁数大了.就一个代称而已. 老杨的00后小同事老杨喊都是带哥的.张哥,李哥的. 但是这个称呼呀,在线下参加一些活动时.金主爸爸也这么叫就显的不太合适. 比如上次某集团策划总监,公司开大会来一句:“今个咱高兴!有请IT运维技术圈的波哥讲两句“ 这个氛围配这个称呼在互联网这行来讲就有点对不齐! 每次遇到这个情况老杨老杨周末浅聊服务器开在公网的那些坑老杨干了,你们随意!” 所以以后咱们改叫老杨,即市井又低调.还挺亲切,老杨觉得挺好.

运维X档案系列文章:

从告警到CTO：一个P0故障的11小时生死时速

企业级 Kubernetes 集群安全加固全攻略（ 附带一键检查脚本）

看完别走.修行在于点赞、转发、在看.攒今世之功德,修来世之福报

老杨AI的号: 98dev