日志采集方式3种，多数人选了最费劲的

三种走法摆在那儿，最费劲的那条偏偏人最多。日志采集方式这件事，本质就是把机器上不断滚动的文本搬到另一个地方去，逻辑简单得不像个技术问题，可真到自己写脚本去拉，边界情况全冒出来了。先把结论摊开：机器超过三台、日志还指望回头查的，别自己写轮询脚本；反过来只有一台小机器、就想看看错误日志，脚本确实够用。麻烦在于多数人的选择正好相反——越大的场面越舍不得装采集器，越小的场面越折腾一堆定时任务。

日志采集方式的三种走法，先摆明白

第一种是 Agent 型，机器上装个小程序，它盯着目录里的文件，有新增就往外发。Filebeat、Fluent Bit、Logstash 都属于这一类，只是体重差得远。第二种是 Syslog 推送型，程序或者系统直接把日志丢到远端，常见于网络设备、路由器、防火墙、老一点的系统。第三种是拉取型，定时任务加 rsync 或 scp 把文件拽回来，再自己写个脚本切分、入库、去重。

三种都能跑通，差别不在能不能采到，而在出了毛病时你疼不疼。Agent 疼在配置，Syslog 疼在格式，脚本疼在一切。

脚本拉取为什么最招人

心理上的理由很实在：不装第三方、不用改业务、出事了自己能读懂那几行 shell。cron 里挂一条 rsync，看着它每天按时跑，心里是踏实的。而且不用跟人解释为什么要多装一个进程，这在小团队里是很大的加分项。

但它把所有脏活留给了你。日志轮转之后偏移量怎么记？多数脚本的做法是记一个游标文件，程序一崩溃游标没更新，下一轮整段重复，检索时看到两条一模一样的报错，人就开始怀疑人生。压缩过的日志还得先 zcat 再切，文件名带日期的那种又要现写通配。机器一多，SSH 密钥、网络策略、目标端磁盘、并发抢带宽，每一样都得自己兜。最要命的是它失败得静默——脚本死了没人知道，等你发现日志断了半个月，中间那段永远补不回来。

我被这套东西坑过一笔，不是钱的事，是时间。当时为了省一个采集器，写了二百来行脚本，后面两个月陆陆续续在补它的边界，越补越像在重造一个残缺的 Filebeat。

Agent 的成本没想象中高

Filebeat 就一个二进制，包管理器装上，systemd 拉起来，配置文件在 /etc/filebeat/filebeat.yml 里，paths 指到 /var/log/nginx/*.log，output 指到 Kafka 或者 ES，基本就完事了。它自己记读取位置，自己发现目录里新出现的文件，进程挂了重启还能接着读，这些正是手写脚本最难搞的部分。

有人把它和 Logstash 混为一谈，觉得一类东西都吃内存。不是。Logstash 要 JVM，重得多；Filebeat 和 Fluent Bit 是轻量侧采集，装在业务机上对 CPU 的影响通常在一个可接受的范围，实在担心还能用 systemd 的 CPUQuota 给它上把锁，别让它跟业务抢。

真正需要动手的是多行日志。Java 的堆栈、PHP 的报错续行，不配 multiline 就是一行一条记录，检索时一段报错被切成七八条碎片，排查全靠猜。这是配置问题，不是选型问题，但十个新装的里面有八个是栽在这儿。

Syslog 只对特定设备真香

网络设备、防火墙、老系统，往往只肯往外发 syslog，你不接就没别的办法。这种情况下 rsyslog 一句 *.* @@10.0.0.5:514 就能推走，注意两个 @ 是 TCP，一个 @ 是 UDP，这个细节坑过不少人。

取舍也很清楚：UDP 快、不阻塞，但丢包是默认行为，链路一抖就少几条；TCP 稳一些，可接收端一卡，发送端跟着卡，严重时影响业务本身。所以别把核心业务日志往 UDP syslog 上压，那是自己给自己埋雷。

格式是另一层麻烦。RFC3164 和 RFC5424 两套时间戳写法，设备厂商还各玩各的，字段顺序都不完全一样，落到最后还是要写解析规则。nginx 可以直接用 access_log syslog:server=… 往外发，也可以用 rsyslog 读本地文件再转发，但两条路别同时开着，否则同一行日志收两遍。

轮转和时区，两个很少被提起的坑

logrotate 的配置在 /etc/logrotate.d/ 下，看着不起眼，跟采集器撞起来很别扭。copytruncate 是把文件复制一份再清空，采集器如果还攥着旧的文件句柄，读到位置就对不上，轻则重复、重则整段丢失；用默认的 rename 方式，采集器认的是 inode，一般能跟着走，但得看它配的 close_inactive 有多长。

时区更隐蔽。几台机器的时钟各走各的，采回来的日志时间互相矛盾，你想按时间排一次故障经过，排出来的顺序是错的。装个 chrony 或者 ntpd，把时间对齐，这一步花不了几分钟，能省掉后面无数次自我怀疑。

还有些碎事：日志编码不统一，GBK 和 UTF-8 混着进，中文变乱码；/var/log 那块盘被日志写满，业务先趴下；采集器自己也在写日志，出了事没人看它的日志。这些都不属于选型，属于运维习惯。

怎么定，就问自己三句话

第一，机器有几台，超过三台还要一台台去写脚本，维护成本是加法不是乘法。第二，日志量多大，一天几百兆和一天几十个 G，处理方式完全不同，后者必须考虑先落盘再集中。第三，日志要不要检索、要不要留几个月，只是为了出事时看一眼，脚本也凑合；要查、要对比、要给客户看，那就老老实实上前面的采集器加存储。

混着来也完全正常。网络设备走 syslog，业务机装轻量 Agent，角落里那台跑着老系统的机器写个脚本凑合着拉——这不丢人，前提是你知道自己在用什么、它的短板在哪。

真准备动手了，先干这几件小事：把 logrotate -d 跑一遍，看轮转动作到底发生在哪一步；确认所有机器的时钟对齐；先只接一台机器，把多行日志和断点续读都验证过，再铺开；最后给采集链路本身配个告警，日志断了比日志有错更可怕。具体的参数和默认值，以各组件的官方文档和你所用服务商的说明为准，别照抄别人的配置文件。