专门做预言的网站,wordpress响应式,wordpress安装vps,徐州网站建设方案推广5月份中旬一天晚上#xff0c;业务需求上线后反馈#xff0c;该业务对应的搜索功能有问题#xff0c;晚上10点多开始排查#xff0c;到凌晨2点#xff0c;最后大致定位了问题#xff0c;并行修改后恢复#xff0c;虽然问题不是很大#xff0c;但是当时上线的业务对业绩…5月份中旬一天晚上业务需求上线后反馈该业务对应的搜索功能有问题晚上10点多开始排查到凌晨2点最后大致定位了问题并行修改后恢复虽然问题不是很大但是当时上线的业务对业绩比较重要当时公司很多大佬都在等问题的解决亚历山大最后定位到的问题很简单就是下游某个服务超时但是整体过程离奇曲折特此记录总结经验。 首先最大的问题下游服务那么多具体是哪个服务出问题导致了最后的问题这个当下无法通过工具定位是最大的问题公司里虽然工具都有链路工具tracing skywalking日志工具elk链路工具基本平时不使用因为不好用有些线程都没有串起来所以当第一步无法定位大致的问题服务时就靠大胆猜测结果还猜错了在错误的问题上折腾了一个小时。 第二排查到出问题的下游链路时由于接口没有对超时打日志所以无法很明确的定位问题只能临时继续加日志上线另外线上日志全部打开后日志量太多导致有的被遗弃没有收集起来还得去机器上看日志。 最终虽然解决了问题但是能看出来这是一个工程问题下次还是无法避免所以我们要建设一些工具另外还需要体系化的建设排查问题的方法论。 1.工具 tracing要善于使用skywalking在错误请求上把链路id打出来根据链路id先定位大致的错误的服务。 logging现在打日志是纵向的开一个应用的日志就把这个应用模块所有访问的日志都打出来了只需要打印错误链路的日志而且需要横向的在各服务上把错误链路的日志都打出来。 2.方法论 首先做程序员代码就是最大的确定性不能靠猜哪里有问题再去看猜其实是先有的手段无法满足定位所以只能靠猜这是下下策。最好的方式是通过metrics—tracing—logging的顺序分析问题比直接去查日志更高效首先得加上监控告警通过告警发现问题第二通过tracing发现该问题发生在微服务链路的哪个环节最后在根据日志找到最根本的问题。
