政策快报平台上线第一年监控系统几乎为零。出问题了靠用户投诉才知道。哪里慢了靠用户反馈才发觉。某个接口挂了可能过了几个小时才有人发现。后来我们花了三年时间逐步建立了一套完整的可观测性体系从“只看日志”到“日志指标链路追踪”三位一体。每次升级都解决了一批问题也暴露了新的短板。今天复盘这个演进过程。三个阶段的演进阶段一日志阶段第一年——能查到“发生了什么”上线初期监控就是“日志”。所有服务的日志写到本地文件出问题的时候登录服务器用grep翻文件查错误。当时的状态出了问题先猜“可能是什么问题”登录服务器翻日志找到错误堆栈根据堆栈定位代码修复上线主要问题多台服务器的情况下要一台一台翻日志跨服务调用的问题无法串联只知道“出错了”不知道“哪里慢”阶段二指标告警阶段第二-三年——能知道“正在发生什么”引入Prometheus Grafana采集系统指标CPU、内存、QPS、响应时间、错误率建立可视化仪表盘和告警规则。当时的状态实时看到系统运行状态异常时自动告警不用等用户投诉通过指标趋势预判问题如内存持续上涨→可能泄漏主要进步从“被动响应”到“主动发现”告警让响应时间从“小时级”降到“分钟级”主要问题知道“哪里慢了”但不知道“为什么慢”一个请求经过了哪些服务、每个服务花了多少时间——看不到阶段三链路追踪阶段现在——能看清“为什么发生”引入分布式链路追踪Jaeger给每个请求生成一个TraceID贯穿所有服务。一次请求经过的每一个环节都被记录下来网关→推荐服务→数据库→缓存→返回。现在的状态知道“哪个环节慢”知道“慢了多少”知道“调用了什么外部服务”知道“数据库执行了什么SQL”一个真实案例某天上午10点告警显示“政策列表接口响应时间从200ms上升到1.2秒”。通过链路追踪发现慢在推荐服务的数据库查询。再往下看是推荐服务有一个SQL没有命中索引。从收到告警到定位到具体SQL用了不到10分钟。三个技术的引入时机技术引入时间解决的问题触发事件日志ELK第一年集中存储、快速检索出问题需要翻多台服务器效率太低指标Prometheus第二年实时监控、主动告警经常被用户投诉才知道系统出问题了链路追踪Jaeger第三年调用链路分析、慢查询定位知道系统慢了但不知道慢在哪一条经验不要一开始就想建“完美的可观测性体系”。按需建设遇到一个问题就解决一个问题。日志不够用加指标指标不够用加链路追踪。每一步都解决了当时最痛的问题才是务实的建设路径。政策快报平台的实践是先让日志“找得到”再让系统“看得见”最后让问题“查得清”。三个阶段缺一不可但顺序不能乱。
