采集太频繁，服务器扛不住
公司新上的订单系统刚跑两周，运维就报警了——日志服务占用内存飙到80%，Kafka队列积压严重。查了一圈才发现，开发为了“不错过任何细节”，把日志采集频率设成了每秒一次。每天产生的原始日志超过2TB，远超存储和处理能力。
采集频率不是越高越好
很多人觉得日志采得越密，问题就越容易定位。但现实是，高频采集带来的副作用更明显：网络带宽被占满、存储成本翻倍、数据分析延迟增加。特别是微服务架构下，几十个服务同时高频上报，整个数据管道都会卡顿。
根据业务场景调整节奏
电商大促期间，交易链路的日志可以调到每10秒采集一次，确保异常能及时捕获。而后台管理类服务，本身请求量小，每分钟采集一次完全够用。像定时任务这种低频操作，甚至可以等任务结束再统一上报一次。
结合日志级别动态控制
并不是所有日志都值得高频采集。ERROR级别的错误必须实时抓取，但INFO类的常规操作完全可以降低频率。可以在采集端配置规则：
<rule>
<level>ERROR</level>
<interval>1</interval> <!-- 单位：秒 -->
</rule>
<rule>
<level>INFO</level>
<interval>30</interval>
</rule>利用缓冲与批量上报
直接每秒往中心日志库推数据，不如先在本地缓存一会儿。比如设定一个50MB的本地缓冲区，攒够了再批量发送。这样既能减少网络请求数，又能避免因瞬时高峰压垮接收端。
监控采集本身的状态
很多团队只关注业务日志，却忽略了采集组件自己的运行情况。Filebeat、Logstash这些工具是否正常？有没有丢数据？延迟是多少？建议给采集链路也加上监控，比如用Prometheus抓取Filebeat的stats指标，一旦发现采集频率异常波动，立刻告警。
测试环境先调优，再上生产
新服务上线前，在测试环境模拟真实流量跑一轮，观察不同采集频率下的资源消耗。比如从每30秒开始试，逐步缩短到10秒、5秒，看系统负载变化。找到那个“既不影响性能，又能满足排查需求”的平衡点，才是最优解。