大促期间日志采集对IO资源的占用，核心矛盾在于日志量突增和磁盘处理能力之间的剪刀差，多数情况下，瓶颈不在采集进程本身，而在于日志落盘的写入路径和采集器的批量策略。
每年618和双11，技术团队都会经历一场相似的战斗，业务指标一路飘红，但监控面板上磁盘IO等待时长也在同步飙升，日志采集这活儿平时看着不起眼,一到流量高峰就暴露出真实面目。
大促期间日志采集为什么成了IO瓶颈
日志采集对IO的消耗，本质上是三个环节在抢同一条出路：应用写日志、采集器读日志、传输前压缩，这三个动作同时落到磁盘上,竞争就开始了。
应用写盘是最容易被忽视的隐形大户
应用业务代码里的logger.info、logger.error，每一条都是一次磁盘写入动作，大促期间，订单量翻倍意味着日志条数翻倍，如果业务日志又带了完整参数和链路追踪信息,单条日志的体积可能增大到平时的3到5倍。
多数应用日志走的是同步写盘模式，即使使用了log4j2或logback的异步Appender，最终落盘的操作还是要交给磁盘，队列缓冲只解决了应用线程阻塞的问题,并没有减少写入总量。
采集器读取和压缩同样挤占IO通道
filebeat、fluentbit这类采集器比较克制，但它们读取日志文件时，会产生read操作和page cache的竞争，采集器的position文件记录偏移量，如果日志轮转频繁,每次打开关闭文件的元数据操作也会产生额外IO。
压缩环节通常消耗CPU，但压缩后的临时文件写入和传输确认，在磁盘队列深度比较高的时候，会慢得像蜗牛，一个常见的连锁反应是：采集器追不上日志产生速度，于是消费积压，磁盘IO持续满负荷，应用写日志慢，接口响应变慢,最终表现为用户可感知的卡顿。
大促期间日志采集IO占用过高的典型表现
谈论日志采集对IO的影响,先看几个事故现场特征。
- 现象一：大促进行到第20分钟，订单服务接口P99延迟从80ms涨到800ms，CPU占用率并不高，但iowait直接顶到30%以上。
- 现象二：Kafka的producer发送超时，原因是日志采集落盘慢，导致event积压,消费跟不上。
- 现象三：MySQL的binlog同步延迟告警，业务主库所在宿主机上，日志采集器吃掉了大量磁盘带宽，影响了数据库的redo log刷盘。
这些现象的共同特征是：日志采集进程本身并没有报错,但整个宿主机的IO资源已经进入危险区。
定位日志采集占IO的具体路径
排查逻辑不复杂，按照下面三步走,多数问题能定位个八九不离十。
先用iostat看整体IO压力
登录出问题的机器,执行：
iostat -x 1
重点关注%util、r_await、w_await三个指标，当%util接近100%且w_await大于50ms时，磁盘已经处于过载状态，这时候把采集器进程停掉持续30秒，再观察CPU idle和平均负载变化,就能确认日志采集在其中的贡献比例。
再用iotop锁定进程
iotop -o -P
按下P键按IO读写排序，如果采集器进程排在前三，且每秒写入量明显高于正常水位，那基本就是主犯了，正常情况下，单机filebeat的每秒写入量在几MB级别，大促期间冲到几十MB也不稀奇,但要看磁盘能不能接得住。
顺着日志源找写入大户
用lsof查采集器打开的文件句柄，看哪些日志文件被频繁读取，再配合日志平台的统计，找出写日志最凶的几个服务，一个大促订单状态变更服务，一秒钟打上百条INFO日志，条均800字节，这就是每秒80KB的写入，整个集群有200个节点，总写入量就是接近16MB/s，这个量级对SSD来说不致命，但如果混部在机械盘上,就是灾难。
日志采集系统性能优化方案
优化思路分四个梯队，后续梯队是前序梯队的兜底,常规大促建议全部做一遍。
第一梯队：缓冲与批量合并，减轻瞬时压力
给采集器配置合理的批量参数,能显著降低IO次数。
filebeat的批量参数集中在libbeat.inputs配置中：
queue.mem: events: 4096 flush.min_events: 1024 flush.timeout: 3s
含义是攒够1024条日志或内存队列超时3秒再一次性写入下游，批量越大，IO次数越少，但内存占用和发送延迟会上升，参照经验值，生产环境设置为events=8192、flush.min_events=2048,对IO的改善明显。
第二梯队：异步采集和IO优先级调整
把采集器的IO优先级调低,让它在资源紧张时主动让路。
ionice -c 2 -n 7 -p $(pgrep filebeat)
这条命令把filebeat的IO调度类设为best-effort，优先级调整到最低的7，应用写日志和数据库刷盘会被内核优先处理，采集器有点饿肚子也不致命,配合nice命令：
nice -n 10 -p $(pgrep filebeat)
调度器会优先保障高优先级进程获得CPU时间片，采集器慢一些,总比业务雪崩好。
第三梯队：日志分级与采样降噪
大促前做一轮日志打印检查，把对排查问题没有帮助的DEBUG日志全部关掉，对INFO日志进行采样输出，业内专家指出，大促场景下的核心服务日志量可以减少40%以上,主要通过三个动作实现。
- 对高频健康检查类请求不做全量日志打印。
- 对链路跟踪日志增加采样率，从100%降到10%。
- 对异常堆栈信息做去重合并,统一打印为一条摘要。
大促前容量规划与压测验证
有条件的团队建议做一轮日志系统专项压测，压测模型不要太复杂，直接在预发环境模拟大促流量,持续观察日志消费延迟和磁盘IO水位。
这里有一个量化经验：日志量达到平时5倍时，IO等待涨幅通常在3倍左右，如果压测发现w_await超过30ms，就需要扩容磁盘或横向增加采集节点，没有条件压测的小团队，至少要在峰值前24小时做一轮日志采集的容量评估，检查磁盘剩余空间、inode数和采集器消费积压情况。
监控告警与长期治理
大促过后,把阶段性优化固化为日常运维的指标体系。
建立日志采集IO监控基线
日常监控中,至少覆盖这四个指标：
| 指标 | 告警阈值 | 检查频率 |
|---|---|---|
| 磁盘iowait | 连续5分钟超过20% | 1分钟 |
| 采集器消费延迟 | 大于120秒 | 1分钟 |
| 磁盘剩余空间 | 低于20% | 5分钟 |
| 日志写入总量 | 同比上周增长2倍 | 10分钟 |
行业共识认为，消费延迟是衡量日志系统健康状况最直观的信号，采集器追不上日志产生速度,是所有IO问题的最终体现。
日志量突增时的自动降级预案
大促期间设置一个开关，当检测到宿主机iowait超过阈值且采集延迟持续升高时，自动将采集器切换为降级模式，降级模式下，采集器只收集ERROR级别以上的日志和第二方WARN日志，确保最核心的异常信息不丢失,但把普通INFO日志丢弃一部分。
这个开关需要配合日志平台的采集链路做好联动,保证降级期间的数据空缺在事后可以补齐或忽略。
定期做日志清理和归档评估
很多团队只关注日志采集，忽视了日志清理，日志保留时间过长，磁盘空间被挤占，采集器的扫描目录越来越大，读目录的开销也在涨，确定一个合理的保留周期比较重要，业务日志保留7天、访问日志保留30天是常见配置，可按实际需求调整,但别让磁盘达到满负荷才动手清理。
挖坑易填坑难：大促前的最后检查
每次大促前做一次场景演练，比理论优化更管用，模拟一个真实场景：日志量突然涨到平时10倍，应用要不要写日志、异常报警能不能发出来、日志平台能不能查得到数据，把这个链路走一遍,比看十篇优化文章都实在。
关于大促日志采集的相关问题
大促期间日志采集io占用过高怎么解决
把采集器进程的IO优先级调低，给应用进程让路，应用侧关闭冗余日志，采集侧调大批量参数，配合日志采样和分级策略，从源头减少日志量，如果仍然扛不住,扩容磁盘或增加独立采集节点是最直接的兜底办法。
filebeat和logstash在大促IO消耗上哪个对磁盘压力更大
单独从采集行为上看，filebeat对磁盘的消耗集中在读日志文件和写注册表文件，属于轻量级读取，logstash需要解析和过滤日志，CPU开销更大，同时它的内部队列在内存和磁盘之间切换时会产生额外IO，长时间运行下，logstash对磁盘的压力明显高于filebeat，这也是很多团队在采集端用filebeat、在传输端才引入logstash的原因。
日志采集器可以部署在业务应用同一台机器上吗
可以，前提是磁盘IO有富余量，部署在同一台机器上的优点是延迟低、不增加额外机器成本，缺点是日志采集的IO高峰可能与业务写盘高峰重合，稳妥的做法是给采集器设置IO优先级和CPU限额，确保资源紧张时业务先走，若宿主机本身已经有数据库或缓存实例运行,把采集器独立部署到单独节点会更安全。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/635814.html
