日志采集框架，自建还是开源采集器

自己搭还是拿开源的现成采集器，我一般先反问一句：你一天写多少日志？这个数答不上来的人，先别聊架构。日志跟数据库不一样，它没有一条明确的性能红线，问题往往是越攒越多、越查越慢，真出事那天才发现少记了一个字段。所以日志采集框架走自建还是直接上开源采集器，本质不是信仰问题，是量、人、预算三个约束下的算术题。这道题算错了不会当场报错，只会在一两年后变成一笔糊涂账，连当初为什么这么选都没人记得。

先把日志量算出来，比选框架更急

日增几百MB和日增几十GB完全不是一个世界。单机小站，rsyslog 直接落到 /var/log/ 下面，再配个 logrotate 按天切、按周删，能安稳撑很久，配置文件里那几行规则网上抄来抄去都差不多。要是 access.log 一天切一次还有几十G，那多半是被爬虫刷了或者正在挨打，先解决源头，别急着上采集链路。另外还有更土的办法：Nginx 的 access.log 直接用 goaccess 跑个报表，临时排查用 journalctl -u nginx 翻两页，也够用。别为了看起来规范，把简单的事搞成三台机器。

日志采集框架自建，钱其实花在看不见的地方

不少人以为自建就是写个脚本 tail -F 往文件里灌，一晚上搞定。真跑起来才知道要补的东西一长串：采集端的并发和重试、断点续传、缓冲队列、解析规则、存储分片、查询界面、权限隔离、告警联动。每一项单看都不难，凑在一起就是持续投入。最贵的是人——写的人走了，后面接手的人得先花时间读懂那套半成品。还有 schema 变更这种破事，业务加个字段，采集端和解析规则就得跟着改，改晚了就是一片解析失败。这笔账在预算表上通常是不出现的。

开源采集器也没那么开箱即用

另一头也别想得太美。Fluent Bit 轻、资源占用小，适合塞在容器边上；Filebeat 稳，跟 Elastic 那套配合顺手；Vector 灵活，转换和路由能力强，配置写起来有点像写管道；Logstash 功能全但吃内存，JVM 一启动就是不小的开销。它们解决的是采集和搬运，解析规则、字段规范、留存策略还是得你自己定。装上一个采集器不等于有了日志体系，这中间的差距，很多人是跑了两三个月才意识到的。具体版本行为和参数以各项目官方文档为准，别照着一篇两年前的教程抄。

多行日志是最先绊人的那道坎

Java 的异常堆栈，每一行单独发出去就变成几十条互不相关的日志，查的时候根本拼不回现场。这事儿的解法是配多行合并规则，用起始行的特征把整段收进一条，但规则写宽了会吞掉正常日志，写窄了又合不上。grok 正则也是同样的脾气，看着能匹配，跑一周才发现某类时间格式全丢。建议上线前拿真实日志跑一遍回放，别拿几条手工造的样例糊弄自己。

采集端和存储端，别捆在一起做决定

常见的链路是 Filebeat 打到 Kafka，再进 Elasticsearch，中间那层不是装样子，是给下游留缓冲——存储那边重建索引或者卡住的时候，日志不会直接丢在采集机上。轻一点的玩法是 Fluent Bit 直接进 Loki，查询靠标签，成本低很多，但不太适合做复杂聚合。这两条路都能走，重要的是采集端尽量别跟存储绑死，留一层能换的接口。哪天存储要迁，你不至于连采集配置一起重写。

时区和时间戳，最容易忽略的一项

容器里默认是 UTC，业务代码打的又是本地时间，两个日志放在一起看，对不上，排查故障时等于白看。统一时区这件事说起来简单，落到实际要改的地方不少：容器环境变量、应用日志配置、采集端的解析格式。还有个坑是时间戳精度，有的精确到秒、有的到毫秒，混在一起排序就乱。定规范的时候顺手把这句写进去，比事后一条条对账省事得多。

多数团队的落点其实是混着用

边缘用成熟的开源采集器，省下自己造轮子的功夫；中间的路由、字段清洗、脱敏这类个性化环节自己写一小段，量不大但贴业务；存储和查询界面直接用现成的，除非你有非常特殊的需求，否则没必要碰。这个组合的好处是每一层都能单独替换，也方便估算成本。反倒是一开始就奔着全自建去的团队，我见过几个，半年后采集端还在改，查询界面一直是个半成品。

真要落地，按这个顺序走一遍：先量出日增体积和留存期，再看有几个人能长期维护，然后确认采集端和存储端是不是同一拨人在管，最后留一条退路——配置能不能在两天内换到另一个采集器上。这四条都答得出来，自建还是开源采集器其实已经有答案了。答不出来就先别动手，多跑两周现成的方案，把字段和查询习惯摸清楚再说，后面怎么选都不亏。