写在前面
最近线上一个新功能闪现后, 经常出现报警
prod_服务异常的列表，请重点关注:
====================================
[[http://{host}/api/health](http://{host}/api/health), 504]
而且之前出现过类似的情况: 业务服务的 kafka consumer 实例一启动, 业务服务的 web 实例就马上 hang 住, 不响应任何请求
解决问题第一步: 快速缓解问题
简单说: 加机器, k8s 时代, 就是调整资源, 详细参考上篇内容
最终确认业务所需的资源:
- req: 0.8c cpu, 0.8G mem
- limit:
req*2
确认完资源侧的问题, 剩下的就是业务侧推进了, 直白点, 根因在业务代码, 靠加资源解决不了问题
解决问题第二步: 定位问题
定位问题基本就是三板斧
- 查看最近的
变更-> 成功率90%, 哪怕是祖传的bug, 也大概率是变更导致的, 所以有些大平台的稳定生产系统, 会专门做 变更管理, 当然职业生涯也遇到过祖传的bug在 1年后爆发 -- 数据量上来后, 大事务里面出现了慢查超过了3s, 而接口限制了要求3s内返回, 导致比较重要的业务挂了 - 查看问题点的
监控和日志-> 成功率95%, 当然不排除监控日志缺失的情况, 这块是基本功了, 可以上升到没有监控日志的程序员, 不是好的程序员 - 整理清楚业务流程 -> 成功率 80%, 有1个前提, 确认是业务侧的问题(参考上一条), 而且可能涉及的面比较广, 人员也比较多, 甚至可能需要一号位来拉齐 -- 笔者就遇到过一次重点项目, 由于一个细节没对齐, CHO+CTO 召集齐了项目所有人在作战室中开了4个小时会对齐
这次遇到的问题, 上面的3条路基本都试过
- 业务变更: 新上了一个定时任务, 会定时请求xxx, 和下一步的日志相互印证了
- 监控日志
-- nginx error log
2025/05/06 04:00:08 [error] 214903#214903: *5482906 upstream prematurely closed connection while reading response header from upstream, client: {ip}, server: {host}, request: "POST /retrieval/apple_health_data HTTP/1.1", upstream: "http://{ip}:30016/retrieval/apple_health_data", host: "{host}"
2025/05/06 04:00:08 [error] 214904#214904: *5482919 upstream prematurely closed connection while reading response header from upstream, client: {ip}, server: {host}, request: "POST /retrieval/apple_health_data HTTP/1.1", upstream: "http://{ip}:30016/retrieval/apple_health_data", host: "{host}"
业务日志
- 业务流程, 值得一提的是, 如果一个问题1周还没解决, 就要考虑
升级了, 问题已经不是能力行不行了, 大概率是信息是否到位
范围已经缩小了, 剩下有2条路径, 尤其是这个问题涉及到业务服务hang, 有性能问题(cpu/mem/lock)的影子
- 技术路线: 1. 压测 2. profile
- 业务路线: 通过上面尝试缩小范围后进行尝试, 到底是哪个接口, 进而是哪个函数引起的问题, 这条路径无它, 哪怕遍历一遍, 也一定能找到根因
定位性能问题: profile
这里需要岔开一嘴: 一定要有单测, 有了单测, 才能更快, 更强
- 快: 可以控制需要运行的粒度, 粒度越小, 自然越快
-
强: 单测上跑profile很轻松
golang中跑profile
pycharm中跑profile
写在最后
监控告警有一条黄金法则
海恩法则: 任何不安全事故都是可以预防的+故障的发生是量的积累 -> 长期的做好每件小事 -> 「系统内部还有没有类似问题」「今后如何能不再出现类似问题」
只要坚持 长期做好每件小事 , 就能安享太平
