记录一下那天晚上的排查过程。Filebeat 8.15 采集 Nginx 日志，配置里给了 multiline 规则匹配以日期开头的行。上线后日志条数只有访问量的一半，统计抓取量直接少了一半。
刚开始盯着「日志里混了两种格式，一种是 main 一种是 json，同一路径下规则只认一种」，折腾了半个多小时，排掉了。
把日志和配置对完，能解释这个现象的基本就这几处。multiline 的 pattern 与日志时间格式不匹配，很多行没被识别成新记录。少数情况下是negate 写反了，导致正常行被当成续行合并。
不容易想到的是，max_lines 设得过大，一整段请求被并成一条超长记录。
动手时先确认 multiline 的 pattern 与真实行首
head -3 access.log | cat -A | cut -c1-80接着改成按行首时间戳切分
multiline.pattern: '^[0-9]{1,3}\.[0-9]{1,3}\.' multiline.negate: true multiline.match: after两种格式分开写到不同文件再采集
access_log /var/log/nginx/json.log json_fmt;剩下的就是用行数与文件大小交叉校验
wc -l access.log; ls -lh access.log改完先别撤，确认这几项。Filebeat 输出的条数与 wc -l 的结果一致，Kibana 里蜘蛛请求数回到正常量级，超长记录也不再出现。
提醒一点。多行合并规则一旦写错是静默丢数据，不会报错，接入时一定拿一天日志跑对账，别等报表出问题才发现。同一份配置在测试环境跑通，不代表线上没事，两边的默认值经常不一样。