为什么采集频率不是越高越好
很多刚接触日志系统的运维人员有个误区，觉得日志采集频率越高越能反映系统真实状态。比如每秒采集一次，听起来很“实时”，但实际情况往往适得其反。
某电商公司在大促期间把日志采集频率从每10秒一次调到每秒一次，结果没撑过两小时，日志服务器直接被压垮。原因很简单：原本每天生成500GB日志，频率翻倍后瞬间暴涨到4TB以上，存储和网络都扛不住。
采集频率影响的不只是日志量
高频采集带来的压力是连锁反应。除了磁盘空间，还有CPU占用、网络带宽、索引性能。尤其是使用Elasticsearch这类检索引擎时，写入频率过高会导致分片频繁刷新，查询变慢甚至超时。
更隐蔽的问题是日志丢失风险上升。如果采集端（如Filebeat）发送太快，而接收端（如Logstash）处理不过来，中间件（如Kafka）积压严重，最终可能触发丢弃策略。
如何科学设置采集频率
关键是看业务需求。普通Web服务的访问日志，每5到10秒采集一次完全够用。用户登录异常检测这种安全敏感场景，可以提升到每秒1次。但像数据库慢查询日志这种低频高价值数据，哪怕每分钟采一次也合理。
实际操作中，建议先按默认频率运行几天，通过监控观察日志增长曲线。如果发现某个时段突增（比如凌晨定时任务），可以动态调整采集间隔，而不是全程高压采集。
配置示例：Filebeat 中的采集间隔设置
filebeat.inputs:
- type: log
paths:
- /var/log/app/*.log
scan_frequency: 10s
close_inactive: 5m这里的 scan_frequency: 10s 表示每10秒扫描一次日志文件是否有新内容。值设得太小会增加I/O负担，太大则可能延迟发现新日志。一般建议在5秒到30秒之间根据实际负载调整。
结合业务做分级采集
不是所有日志都值得高频率采集。可以把日志按重要性分级：
安全审计类日志（如SSH登录、权限变更）需要高频采集，建议1~5秒一次；普通应用日志保持10秒左右；调试日志在生产环境干脆关闭，真出问题再临时开启。
某银行系统就是这么干的。平时只采集关键交易流水，频率设为3秒。一旦检测到异常登录行为，自动触发“紧急采集模式”，把相关模块的日志频率提升到每秒一次，持续10分钟。既节省资源，又能抓住关键证据。
别忘了测试和回滚机制
改完采集频率别急着上线。先在测试环境模拟流量，看资源消耗是否在可接受范围。线上调整时最好配合发布窗口，同时准备好回滚配置。
一个实用技巧：用脚本定期检查日志采集延迟。比如对比日志时间戳和采集时间差，超过30秒就告警。这样能及时发现频率设置不合理或系统过载的情况。