政策快报平台上线第一年，日志是写到本地文件里的。
出问题了，登录服务器，用grep翻日志。运气好找到了，运气不好找半天找不到。
有一次凌晨3点系统报警，爬起来查了2小时，没查到原因，最后重启了事。不知道原因，心里一直悬着。过了几天，同样的问题又出现了。
后来我们做了一套完整的日志系统：从本地文件到ELK集中管理，再到监控告警自动发现。现在任何异常，5-10分钟内能定位到具体代码行。今天复盘这个演进过程。
3个阶段
阶段一：本地文件日志（第一年）
状态： 每个服务把日志写在本地文件里，按天切割。查日志要登录服务器，用grep翻文件。
缺点：
-
多台服务器要一台一台翻
-
跨服务的调用链查不了
-
出问题了靠人工发现，经常用户投诉了才知道
某次一个接口超时，我们翻了3台服务器、用了2小时才找到一条异常日志。效率太低，而且这个过程里服务一直在降级，用户投诉不断涌入。
阶段二：集中式日志管理（第二年）
方案： 引入ELK（Elasticsearch + Logstash + Kibana），所有服务的日志通过Filebeat采集，经Logstash解析后存入Elasticsearch，通过Kibana统一检索。
优点：
-
不用登录服务器，一个界面查所有日志
-
支持全文检索，比grep快很多
-
支持多条件过滤，快速定位问题
某次告警显示"推荐服务响应慢"，我们直接在Kibana里搜"recommend"+"timeout"，5分钟就找到了原因------一个下游接口超时。换成以前，至少要翻3台服务器、花1小时。
新问题：
-
日志量增长快，ES存储成本高
-
只能"查"问题，不能"自动发现"问题
-
还是需要等人发现异常，再查日志定位
阶段三：监控告警 + 日志关联（第三年）
方案： 在ELK基础上，增加Prometheus采集系统指标，Grafana展示仪表盘，AlertManager配置告警规则。日志和指标关联，异常时自动触发告警，告警附带相关日志上下文。
优点：
-
出问题不用等用户投诉，系统自动告警
-
告警附带日志上下文，定位时间从10分钟缩短到2分钟
-
历史趋势分析，提前发现潜在问题
效果：
-
故障发现时间：从用户投诉后（30分钟-数小时） → 系统自动告警（1-2分钟）
-
故障定位时间：从人工翻日志（10-60分钟） → 日志关联查询（3-5分钟）
总结演进路径
| 阶段 | 存储方式 | 查询方式 | 发现问题 | 定位问题 |
|---|---|---|---|---|
| 本地文件 | 本地磁盘 | grep | 用户投诉 | 小时级 |
| ELK集中 | Elasticsearch | Kibana检索 | 用户投诉 | 分钟级 |
| 监控告警 | Elasticsearch + Prometheus | Kibana + 自动告警 | 系统自动发现 | 分钟级 |
一条核心经验
日志系统的价值不是"能查到日志"，是"能在需要的时候快速找到需要的日志"。
如果查一条日志要登录3台服务器、翻1小时文件，那这个日志系统几乎等于没有。ELK让"查日志"这件事从小时级变成了分钟级，而告警让"发现问题"这件事从被动等投诉变成了主动发现。
现在政策快报平台的日志系统能做到：任何异常，5分钟内告警，10分钟内定位到具体原因。