公司发展到一定规模，分支机构遍布各地，问题也随之而来。比如我们公司，在北京、上海、深圳都有办事处，每个地方都跑着不同的业务系统，服务器、网络设备、应用日志分散在各处。以前排查问题，得一个个登录不同地区的服务器翻日志，效率低不说，出了事还容易遗漏关键信息。
为什么要做日志集中管理
有次深圳的订单系统突然出错，客户投诉不断。技术同事第一时间去查本地日志，但发现日志只保留三天，而且中间还因为磁盘清理被覆盖了一部分。北京的运维根本没法远程查看，最后靠一台备份机才找回线索，耽误了整整六个小时。这件事之后，管理层终于同意上日志集中方案。
我们的技术选型过程
一开始考虑过自建 ELK（Elasticsearch + Logstash + Kibana），开源免费，社区支持也好。但在测试阶段发现，Logstash 在处理多地并发日志时资源消耗大，小内存机器直接卡死。后来换成 Fluentd 做日志收集，它轻量，配置也清晰，配合 Elasticsearch 存储，Kibana 展示，整套跑起来稳多了。
每个分支机构部署一个 Fluentd 节点，负责收集本地服务器和应用的日志，通过加密通道（TLS）传送到总部的中心日志服务器。这样既保证传输安全，又避免公网暴露内部服务。
<source>
@type tail
path /var/log/app/*.log
tag branch.shenzhen.app
format json
</source>
<match branch.**>
@type forward
<server>
host logs-center.tiantianshun.com
port 24224
</server>
transport tls
</match>实际运行中的小技巧
刚开始集中后，日志量猛增，Elasticsearch 集群差点撑不住。后来加了索引按天切分，老数据自动归档到冷存储，查询压力小了很多。Kibana 里也做了多维度仪表盘，按分支机构、服务类型、错误等级分类，一打开就能看到异常高峰。
还有个实用做法：给每条日志打上明确的标签，比如 branch:shenzhen、service:order，这样搜索时可以直接过滤，不用在成千上万条记录里手动翻。
不只是技术，流程也要跟上
系统搭好了，还得有人看。我们设了日志巡检岗，每天早会前看一遍关键服务的错误日志趋势。有一次上海的支付网关连续报超时，虽然没宕机，但日志里已经有大量重试记录，提前介入后发现是数据库连接池配置错了，避免了一次潜在故障。
现在新员工入职，第一课就是怎么查中心日志。谁负责哪个模块，出了问题直接去 Kibana 搜自己的服务标签，责任清晰，响应也快。
多分支机构的日志集中管理，不是买套工具就完事的事。它背后是架构设计、安全策略、运维习惯的综合调整。但我们走通了这条路，现在哪怕新开一个成都分支，日志接入也就半天时间，问题定位从“找线索”变成了“看报表”。