前后端日志串联快速排查问题方案

1. 【第5期】线上体验保障专题

2. 【第3讲】快速定位线上问题之前后端日志串联方案分享嘉宾：汤海波-58房产前端开发工程师

3. 目录 1 背景介绍 2 方案设计 3 方案实现 4 案例分析 5 规划展望

4. 背景介绍客服小花：小曹，快看看租房发布，最近10分钟好几个用户反馈，发布户型选择不了。 PM小曹：哎呀不好意思，我这就反馈给我们的开发同学来排查问题。小曹把问题甩给了前端小张。小张用自己的手机体验了一下没有发现功能异常。转而一想，我们最近没有上线，而户型选择是调用了客户端的控件，难道是客户端开发同学对控件做了改动？10分钟后怀着疑问，小张找到了客户端小刘。前端小张：小刘小刘，快看看这个户型选择功能，部分用户选择不了户型了。客户端小刘：好的，请稍等，我们来定位一下问题。

5. 背景介绍 20分钟后，小刘定位到了问题，发现是H5调用客户端控件时传入的参数有部分字段缺失导致的。前端小张想了下，调用数据是后端返回的，所以找到了后端小苏。小苏查询了后端日志，发现出现问题的用户，户型数据的确有缺失，从而导致户型选择功能出现了bug。20分钟后，小苏紧急修复数据问题并上线了。至此，经过几轮排查，问题解决了。

6. 背景介绍场景分析：相关人员解决耗时 5人 1h 代码“裸奔”无保障排查问题链路过长强依赖其他开发

7. 背景介绍解决思路： n 代码监控与报警 —— 发现问题实现前端代码错误监控与报警提醒功能，触发一定的阈值后会第一时间通知到开发者本人。 n 快速排查定位问题 —— 解决问题前端需要上报业务日志，出现问题后，通过查询前端业务日志快速定位问题。

8. 方案设计设计基础： 1. wmonitor简介提供个性化监控功能，服务调用 wmonitor api，就会产生监控数据图表，以及自定义报警，使用者不需要关注数据的存储和展示。分享人：余意

9. 方案设计设计基础： 2. 云平台介绍 58云计算平台是基于容器技术打造，适合58集团应用场景的一站式云化解决方案。一键创建集群，一键构建应用，并快速构建和打包集成。分享人：余意

10. 方案设计设计思路：分享人：余意

11. 技术实现埋点上报-技术实现一、wmonitor前端埋点上报与报警不关心返回值能跨域思考资源要小

12. 技术实现埋点上报-技术实现 node：

13. 技术实现埋点上报-技术实现 js封装：分享人：余意

14. 技术实现埋点上报-技术实现使用流程：

15. 技术实现二、日志上报-技术实现目标：前后端日志串联，统一采集、统一展示、统一查询 1. 以统一的日志格式进行上报 2. 以统一的方案进行存储 3. 前后端日志需要通过业务 id进行串联字段解释字段解释 deviceid 设备id userid 用户id serverId 业务id cookie 用户cookie logtype 日志类型 referer 页面来源 content 上报的内容 platform 平台 userip 用户ip serverip 服务器ip uri 接口uri useragent 用户代理 timestamp 时间戳 id58 58id

16. 技术实现日志上报-技术实现需要做的事情：

17. 技术实现日志上报-技术实现封装日志上报服务&日志落本地磁盘 morgan morgan(logger)来把日志落到本地磁盘 rotating-file-stream 日志切割 cors 跨域数据上报

18. 技术实现日志上报-技术实现接入Kafka进行实时数据采集&数据消费申请Kafka topic 01 云平台接入Kafka实时采集 02 前后端调用一套能力去消费Kafka数据 03

19. 技术实现日志上报-技术实现 Elasticsearch 是一个搜索和分析引擎。 Kafka数据消费 ELK Logstash 是采集数据、转换数据，发送数据的。Kibana负责可视化展示与查询 hive是基于Hadoop构建的一套数据仓 Hive 库分析系统，它提供了丰富的SQL查询方式来分析存储在Hadoop分布式文件系统中的数据云平台 File Shell+Linux命令实现日志File分析,经常结合grep命令、awk命令等来实现日志分析统计

20. 技术实现日志上报-技术实现日志存储、索引、展示 ELK消费Kafka数据 Kafka集群 Logstash 日志分析 ES集群 kib ana

21. 技术实现日志上报-业务接入封装通用request拦截器，对错误日志实现自动上报 * code不为0 * status不为200 手动调用接口主动上报业务日志

22. 技术实现日志上报-业务接入引入 request 拦截器主动抓取错误并上报业务主动上报 kibana 查询日志

23. 技术实现日志上报-遇到问题消费速度慢版本问题 logstash消费Kafka过慢导致数据不能及时查询出来 Kibana和ES的版本需要保持一致，否则会有报警信息导致不可用数据丢失数据量过大日志格式不正确导致没有存储到ES中接入方越来越多，日志量越来越大，存储周期需要控制

24. 案例分析回到背景介绍的案例

25. 案例分析案例-公共支付页页面功能提供微信、支付宝支付能力运行环境 58app、58本地版app、安居客app 三方依赖 1. BIC的支付订单服务 2. 客户端提供的唤起原生支付能力常见问题微信或支付宝支付未被唤起，页面无响应

26. 案例分析页面流程图

27. 案例分析问题预判 1. 增加详细日志信息 1. js逻辑报错问题思路 2. 调用BIC订单服务异常 2. 增加订单服务监控报警 3. 调用客户端支付能力异常 3. 明确是否客户端支付能力异常

28. 案例分析增加监控与日志

29. 案例分析初步结论 1 2 3

30. 案例分析唤起支付失败问题排查优化前优化后

31. 案例分析唤起支付失败问题排查安居客的支付action中只应存在wechat_pay，不能调用 hs_wechat_pay，这属于调用错误根源是不同版本ap p 环境内 cookie不规范，导致业务代码判断环境和app版本逻辑出现了疏漏，需要兼容这种情况。

32. 规划展望需要主动上报若干信息代码侵入性高才更有利于排查问题对于端的兼容性不够不足之处无法定位更深层次问题，比如微服务排查问题有滞后性

33. 规划展望全面对接北斗监控系统，向强大的系统靠拢 3 2 探索代码低侵入方案，使监控与日志上报与业务代码解耦 1 扩端，更多端的监控与日志采集，才能满足通用集成方案

34. Thanks~