日志集中管理：从 grep 到 ELK 的演进

日志管理的起点通常是一条 grep 命令，机器少的时候这样已经够用。机器多了、人多了，演进就自然发生，目的始终是同一件事：出问题时，找日志的时间要短于看日志的时间。值得把演进路径想清楚再动手，免得反复迁移。 一、三个阶段 一台机器：ssh 上去直接 grep /var/log/nginx/access.log，配合 tail -f 实时看。三五台：写循环脚本远程查，或者 rsync 拉回本地再搜，痛点是各机器时间不同步、格式不统一，这一阶段的脚本建议统一放一个目录并写说明，接手的人少走弯路。时间不同步是典型坑：两台机器各说各的时序，对不到一张图上，装机先校时，NTP 是地基。十几台以上、多人同时排查：值得上集中式，否则一个故障要登四五台机器，查过也没留痕。 二、ELK 是什么 ELK 是三个开源组件的组合：Elasticsearch 负责存储和检索，Logstash 负责采集与加工，Kibana 负责查询展示。实际部署常见变体是用更轻的 Filebeat 代替 Logstash 做采集，Logstash 只留在需要复杂处理时出场。字段解析是采集环节最费工的部分，日志格式统一能省一半力气。版本兼容性是这个组合的老坑，各组件升级尽量同批进行。 三、什么信号说明该上了 排查一个故障要同时登多台机器；同一问题别人查过、没人留痕、再查一遍；审计或合规要求日志集中保留半年以上。三条中两条，就该动工了。 四、成本提醒 日志量增长很快，Elasticsearch 吃内存也吃磁盘，索引不清理几个月就能写满整块盘，索引生命周期管理（ILM）要一开始就配好。冷数据放对象存储，需要时再解冻检索，成本能降一个量级。预算紧张可以看 Loki 这类只索引标签的方案，存储便宜，配合 Grafana 查询够用。 务实的路径是先集中收集，rsyslog 就能起步，检索分析后置，不必一步到位建大集群。