适用场景

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

配置步骤（冷热分层与查询效率）

# 分层设计（示例）
热层：近 7 天，SSD 存储，全字段索引，供排障查询
温层：8-30 天，普通磁盘，部分字段索引，供统计与回溯
冷层：31-180 天，对象存储/压缩归档，按需恢复

# 索引策略
- 只对会用于过滤的字段建索引（service、level、trace_id、code）
- msg 等大字段不建索引，只做存储

# 查询习惯
- 先限定时间范围与 service，再做关键字搜索
- 避免通配符前缀查询（*abc）
- 常用查询沉淀为看板/保存查询，避免每次重写

关键参数与建议

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

容易踩的坑

  • 所有字段都建索引，存储与写入成本翻倍
  • 不分层，几年前的日志也在热层
  • 查询不带时间范围，一次扫全量
  • 只保留 3 天，故障复盘时数据已被删
  • 归档数据没做可读性验证，需要时取不回来
  • 没有查询规范，值班人员各查各的

验证与巡检

# 效率与成本检查
1) 热层查询响应时间 < 5 秒（常规查询）
2) 冷层恢复演练半年一次，能恢复指定时间段
3) 存储月成本环比变化 < 20%
  • 巡检：查询响应达标、分层策略生效、归档可恢复、成本有月报

小结

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

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