适用场景

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

配置步骤（采集与解析）

# Filebeat 采集要点（示例片段）
filebeat.inputs:
- type: filestream
  paths: [/var/log/app/*.log]
  parsers:
  - ndjson: { keys_under_root: true, overwrite_keys: true }
  - multiline: { pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}', negate: true, match: after }
queue.mem: { events: 4096, flush.min_events: 512, flush.timeout: 5s }
output.logstash: { hosts: ['logstash:5044'], bulk_max_size: 512 }

# 常见字段规范
# ts / level / service / host / trace_id / module / msg / cost_ms

# 解析失败要有计数（否则默默丢字段）

关键参数与建议

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

容易踩的坑

  • 日志格式随意改，采集解析规则全部失效
  • 多行堆栈没合并，一条异常拆成几十行
  • 采集端没有本地缓冲，存储侧一抖动就丢日志
  • 高峰期限速没设，采集把业务带宽吃满
  • 解析失败无计数，字段缺失没人发现
  • 采集器版本长期不更新，安全漏洞悬空

验证与巡检

# 采集健康
filebeat test output
journalctl -u filebeat --since '1h ago' | grep -i -E 'error|drop' | head

# 解析成功率：按字段缺失比例抽查
# 目标：关键字段完整率 > 99%
  • 巡检：无丢弃、解析成功率达标、版本已更新、限速生效

小结

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

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