老师好，说下自己定位问题的一些经验和方法 1. 确认清楚问题的现象或本质 2. 如果时间允许可以复现下问题，对问题理解更直观 3. 查看日志，确认报错的异常信息（日志这步很关键，物理机时代通常做法是上机器grep，如果有多台机器这是比较麻烦的点，所以一般会有日志中心。容器时代的话屏蔽了Iaas层，日志都存在在日志中心，例如ELK，根据关键字就可以查了） 4. 查看代码确认业务逻辑 5. 根据日志和代码业务逻辑基本就可以确认报错的点了

1.tracid在碰到线程池异步时如何传递id？ 2.mq消息是否也该带上tracid？

分布式链路系统中，最常用的调试问题方法还是文中提到的方法，主要依赖分布式调用监控系统，比如CAT，从里面可以看到是哪个链路出问题了。

opentracing ，就是需要接管业务流量才行

老师应该介绍下skywalking、Zipkin等开源分布式链路跟踪的优缺点和使用问题等，毕竟能自研分布式链路跟踪的公司不多

分布式环境下如何快速定位问题： 1：依赖公司运维基础设施的建设，比如：JD各种工具比较健全，查日志、方法监控、容器监控、网络监控等等，基础组件的问题各个运维团队支持也给力，系统问题比较好查，自身业务问题依赖自身对自己业务逻辑的理解程度，反例——如果查个日志，需要登录中控机，再登录目标机，还需输入验证码＋密码，然后找日志路径，然后使用命令查，这种方式原始低效 2：全链路追踪系统，目前还没看到做的比较好的，理想很丰满现实很骨感，如果做的好，对许多问题确实能够做到快速定位，尤其是性能问题，一下子就知道谁慢。如果各个方法都能统计，那就更棒了 3：我目前的经验，对于日志和各种监控工具依赖比较重，如果这些OK，又是业务问题，熟悉业务就能很快定位。最不好定位的是系统异常尤其是和网络通信相关且不好复现的，最常见的就是各种连接超时、socket超时、负载偶尔抖动，很令人头疼。网络认为是网络抖动了一下，就不了了之啦！具体原因则石沉大海 4：RPC封装相信的日志确实非常重要，一下子就清楚为什么了，反例——如果这些没有封装好，就只有一个连接超时，也不知道谁调谁？那个服务和方法？超时设置多少实际耗费多少，那这种问题就且查了 5：关键业务日志的打印也非常重要，多了耗性能费空间，少了排查问题不利，幸好Jd是有UCC的可以控制日志打印，不过具体打印的OK与否还要看个人经验＋代码评审

通过日志排错的话，产生的日志量是很大的，想问下在高并发下日志会不会有乱序的情况，rpc怎么解决这个问题

还要养基础系统——调用链监控系统。这RPC，也真不是一般中小企业，养得起的

全链路追踪比较麻烦的是各种中间价的支持，例如db，缓存，mq

老师好，实际使用skywalking链路追踪遇到一个问题，在一个trace里面 A服务多次调用B，每次调用在B服务打印的traceId都不同，这个是什么原因你们？