日志和成本咱們運維人該如何平衡?
今天聊聊日志的事，都知道日志采集不是越多越好，也不是越少越省心這個道理，那么如何平衡日志和成本的關系呢?
什么叫價值大于成本？簡單說就是，這些日志在關鍵時刻能救你命的，那就得全量保存；那些只是看起來有用，實際上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, 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(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 "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這樣平時保持低成本運行，有問題的時候自動切換到全量模式，既省錢又不會漏掉關鍵信息。
