政策快报平台日志系统的3次演进：从文件到ELK到告警

政策快报平台上线第一年日志是写到本地文件里的。出问题了登录服务器用grep翻日志。运气好找到了运气不好找半天找不到。有一次凌晨3点系统报警爬起来查了2小时没查到原因最后重启了事。不知道原因心里一直悬着。过了几天同样的问题又出现了。后来我们做了一套完整的日志系统从本地文件到ELK集中管理再到监控告警自动发现。现在任何异常5-10分钟内能定位到具体代码行。今天复盘这个演进过程。3个阶段阶段一本地文件日志第一年状态每个服务把日志写在本地文件里按天切割。查日志要登录服务器用grep翻文件。缺点多台服务器要一台一台翻跨服务的调用链查不了出问题了靠人工发现经常用户投诉了才知道某次一个接口超时我们翻了3台服务器、用了2小时才找到一条异常日志。效率太低而且这个过程里服务一直在降级用户投诉不断涌入。阶段二集中式日志管理第二年方案引入ELKElasticsearch 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集中ElasticsearchKibana检索用户投诉分钟级监控告警Elasticsearch PrometheusKibana 自动告警系统自动发现分钟级一条核心经验日志系统的价值不是“能查到日志”是“能在需要的时候快速找到需要的日志”。如果查一条日志要登录3台服务器、翻1小时文件那这个日志系统几乎等于没有。ELK让“查日志”这件事从小时级变成了分钟级而告警让“发现问题”这件事从被动等投诉变成了主动发现。现在政策快报平台的日志系统能做到任何异常5分钟内告警10分钟内定位到具体原因。