适用场景

日志管道做不好会出现三种结果：丢日志（需要时没有）、查得慢（半小时出不来结果）、贵得离谱（存储费超过服务器费）。根因通常是解析规则混乱、保留策略缺失。

配置步骤（日志成本控制）

# 成本三来源
1) 存储量：数据量 × 保留天数 × 副本数
2) 索引：被索引字段数量与基数
3) 查询：高并发查询消耗的计算资源

# 控制手段（按性价比排序）
1) 减少无用日志：调试日志降级或采样，杜绝重复打印
2) 字段化替代全文：把可变内容抽成字段，减少文本量
3) 按级别分流保留：ERROR 90 天，WARN 30 天，INFO 7 天
4) 索引瘦身：只索引 5-8 个关键字段
5) 压缩与分层：冷数据压缩率通常 5:1 以上

# 度量
每 GB 日志成本、每日日志量、Top 打印来源（哪个服务最啰嗦）

关键参数与建议

  • 采集：Agent 本地缓冲 + 断点续传，远端不可用时不丢日志
  • 解析：在采集端做字段化（grok/正则/JSON），不要把大段文本丢给存储
  • 分流：按级别与业务分流（错误日志长期保留，调试日志短期）
  • 冷热分层：热 7-15 天可搜索，冷数据压缩归档，按需恢复
  • 索引成本：字段索引按需开，避免全字段索引导致成本翻倍
  • 管道限速：采集与写入限速，避免高峰期把存储与网络打满
  • 监控：采集成功率、写入延迟、解析失败率三项必须监控
  • 验收：任意时间点日志可查、解析字段可用于统计、月度成本可控

容易踩的坑

  • 一个循环里每行都打日志，日志量是业务量的百倍
  • 同一个异常在多层捕获都打一次，重复三份
  • 全字段索引，成本是存储的几倍
  • 保留期一律 180 天，冷数据从未被查询
  • 从不统计谁在疯狂打日志，治理没有靶子
  • 成本只在账单出来才知道，没有月报

验证与巡检

# Top 打印来源（按 service 统计日志量）
# 存储侧：按 service 聚合每日日志量，取 Top10
df -h /var/lib/elasticsearch 2>/dev/null || true

# 目标：日志量增长 < 业务量增长；Top1 服务占比 < 30%
  • 巡检：日志量趋势、保留策略按级别生效、索引字段数受控、月度成本报告

小结

日志管道验收：抽查一条链路，能从采集端确认不丢，能在存储端按字段查询，能说清保留期与每月成本。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。