日志采集平台就三类，多装纯属添乱

先把结论摆出来：日志采集平台就三类多装纯属添乱。这话听着武断，但凡是半夜被一条告警叫起来、在一堆自建采集器里翻半天还没找到原始日志的人，大概率会点头。日志本身不难采，难的是采完之后谁维护、谁升级、谁给磁盘腾地方，装得越多，这几件事越堆在一个人头上。

最朴素的那类：本机落盘加轮转

一台机器撑一个站，Nginx 的 access.log、PHP 的 error_log 全落在 /var/log 底下，logrotate 默认就按天切、切完压缩、老的删掉。这种规模真没必要上什么平台，出问题的时候 grep 一把、tail -f 盯两分钟，答案八成就在里面。要做的只有两件小事：盘别被打满，切分策略别把当天的日志也压走。

不少人上来就装 agent，图的是“将来万一要查”。可机器只有一台、日志只产生一份，采集器自己挂了你还得先去看采集器的日志。多一个组件就是多一个会坏的零件。

机器多了就得集中收，先把时间对齐

到了三五台七八台，日志散在各处、ssh 来回跳就有点烦。这时候上一台中间机，远端用 rsyslog 推（*.* @@192.168.1.20:514，两个 @ 是 TCP），或者放个轻量 agent 统一往一台 Loki、Fluent Bit 上送，看图的界面用 Grafana 就够。这一层的核心不是功能多，而是“所有机器的日志能在同一处看见”。

集中收最容易踩的坑是把时间搞乱。机器时区不一样、ntp 没同步，日志收上来顺序全是错的，一条报错前面连着三分钟之后发生的事，排查时能被它带进沟里。先把 chronyd 或者 ntp 对齐，再谈采集。

日志采集平台就三类多装纯属添乱，账都落在三处

第三类是带索引、带长周期留存的那种，Elasticsearch 一套组合拳，或者对象存储打底再加一层查询。它的价值在于“我要搜上个月某个订单号的完整链路”，不是“我要看今天的 error”。

三类之间是台阶关系，不是并列关系。你在第一类的位置上装第三类的东西，最直观的代价是磁盘和内存：Elasticsearch 一开，JVM 先吃掉一大块，日志量不大却按天建索引，机器半夜开始 swap。再往下是人的成本——版本升级、索引模板、分片、生命周期策略，每样都得有人盯。第三类没运维，不出三个月就是一坨没人敢动的历史遗留。

所以这句话说的不是不能装，说的是重复装。同一份日志既走 rsyslog 又走 agent，两边都往一个存储写，你以为做了冗余，其实是把数据量翻了一倍、把排查时的干扰项也翻了一倍。

采集器打架是最常见的事故

真实现场大概是这样：老系统里有一套 syslog，新同事照教程装了 filebeat，测试环境的 fluent-bit 配置文件还留在机器上。三套一起跑，磁盘 IO 明显上去，日志目录被读了三四遍，负载看着不高但写日志老是延迟。

更烦的是配置漂移。A 采集器过滤掉 debug，B 采集器全量送，平台上搜到的日志一半是另一条链路漏过来的重复行，时间戳还差几毫秒。真出事的时候，你得先判断这条是哪套采集器写的，排查成本比日志本身还高。删也别一刀切，先把每套的输出目的地、过滤规则、保留周期列出来，确认哪套是你真在用的，其余先停进程观察几天，别连数据一起删。

日志自己没收拾好，装几套都白搭

采集平台只是搬运工。日志格式乱、一行塞七八个字段、时间戳三种格式混着来，搬过去照样搜不出来。能做的几件事：应用日志统一成一行一条结构化输出，json 或者至少固定分隔符；时间戳统一成带时区的 ISO 格式；级别用固定的几个词，别一会儿 ERROR 一会儿 Error。

还有内容本身。日志里带手机号、身份证、明文密码、token 的，采上来等于把敏感数据又复制了一份到别处，访问控制、留存周期、谁能查，都得跟着重新评估。要做脱敏，规则就得放在采集端落地，别等存储层再补——库里已经有原始副本，后面怎么处理都是补救。具体合规口径以相关法规和服务商、官方页面说明为准，别照搬别人的方案。保留多久也得先想清楚，“万一以后要查”的日志，成本最后都变成磁盘账单和备份时间。

告警别一股脑全塞进短信

采完了总得有告警。见过不少配置把所有规则接到同一个通知渠道，一次上游抖动，几十条告警同时出去，手机被短信轰炸，真正要命的那条反而被淹掉。

合理的做法是按级别分渠道：致命错误直接走短信平台或者电话，这类通道到达率高、按条计费，得省着用；一般异常走邮件或者群里，能忍能翻；debug 级别压根不该发出来。短信通道的送达速度和计费方式各家不一样，以服务商页面说明为准，别把别人的经验值当成自己的预算。

这几种情况确实该多上一套

不是所有“多装”都是添乱。跨地域部署、日志必须分域存放的；有明确审计留存要求、业务日志和审计日志要物理分开的；数据量大到单套存储扛不住、得分层冷热的——这些上多套是合理的，因为目的不一样，不是为了数量。

判断标准很土：这套东西服务的是哪个具体问题，谁在用，多久用一次。答不上来就先别装，等真碰上一次“找不到日志”的事故，再针对性补。

回头看看自己服务器上正跑着的采集进程，问四句：几台机器、日志留多久、过去三个月你真去搜过几次、告警最后发到了谁手机上。这四个答得清楚，多数站点停在第二类甚至第一类就够，不用往第三类挤。机器不多、日志不复杂的时候，少装一套省下来的不只是内存。