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