去哪儿旅行分布式链路追踪系统实践

直播迁移到Docker 和使用cgroup 技术的成本怎么评估的？

直接迁移到容器化的话，我觉得是跟公司整个技术体系结构是有关系的。我相信历史老一点的互联网公司肯定前面都是用那种KVM虚拟机，你使用Cgroup技术说在上面执行了一些linux的一些命令、脚本就可以了。可以运维帮大家去建一些扫描的脚本，完了之后批量在这个机器上去刷就可以了。如果说你都迁移到容器上的话，其实它是一个体系化的工程。那你要配合着KPS配合的发布系统，还有配合业务线的一个迁移，那这个可能是一个更大的事情，需要一个统一的规划。如果说单纯从Cgroup技术Docker两个点来去看的话。也是看你公司所在的阶段。

如何及时发现未被监控的指标项，避免未被观测的指标突变引发故障？

这个问题，我理解你是说。我有监控项并没有配置报警。这种情况我们也在做一些智能检测的工具。就比如说现在AIOps里面的一个故障，发现主要是针对于这些指标去做一些智能预测来做这件事情。目前来看，这块其实挺难的。现在其实有很多的。无论是机器学习也好，还是这种概率模型也好，还不能完全覆盖我们的这些问题，原因是说我们的业务监控指标非常繁多且复杂，而且规律都不一样。还在积极学习中，它没有办法规律出现。它没有办法抽象出归类，只有非常重要的指标，比如说你订单的下单量。我相信你百分之百会加监控、报警，但有一些你可能觉得也不是很重要的指标。你可能也不会都去加报警？这个问题就很复杂。你也不可能说让机器去帮你把这个东西完全去兜住，这也很难，其实我们也在探索这块的一个发展吧。我们目前来讲也是用一些概率模型，还有一些机器学习的模型来去看能不能去预测出来这些指标。

metrics 和trace 关联能在展开说下嘛？

time类的指标——不用过多解释，time类的指标非常的简单，我只需要抓耗时长的就可以了。那耗时长的，无论他是报警or不报警，那肯定是问题最大的，就不多说。

count类指标——我们有三种策略，第一种就是随机采样。就是我也不知道这个count是不是重要。我不知道。那我就随机采样？因为有可能它压根儿就没有设置任何报警，它只是一个监控指标，那我就随机采样。之后如果说他设置了报警，确实也正在报警。我们是可以知道状态的。我们要对指标做更强的采样。比如说以前是千分之一的材料，现在要做到1%或十分之一。极有可能命中在这段时间内的trace。

具体采样怎么做的？就是整个监控指标这块儿有一个打点的靶点中间键，我们安插了trace的一些功能进去。你在打点的时候，你整个在记录这个点的时候，你肯定是有一个java的APM，比如说我们是commitor，一个点record的什么东西，就是它有一个函数调用，我们在这个函数调用里面就会做这个trace采样。因为在整个线程的上下文里边，我是可以拿到trace的上下文的，当它比如说record的时候。我就可以这个trees关联关系记录下来，存储到我们的trace里，它也作为独立的一个trace做存储。存储之后，我们刚才讲了在flink任务里边，我会把存储的关联关系给它拆出来。拆出来之后，存到我们的DB里边，我们现在是存cleanhouse是存到CK里边。这样的到时候我们就知道它俩的关联关系了，既然知道关联关系，我想正着查，反着查都能做到。

我们让它闪成一条新的trace，记录好matches和trace的关系。trace其实是它可以通过线程的上下文拿到的。我们在记录mrace的时候，就把这个关联关系记录下来，采样频率根据我刚才说的，如果没有报警，我们就千分之一随机的采。有报警，我们就加大采样频率。升高采样频率。来点密集的采集。

第三个策略是关键词策略。干键词策略是我们的feelexceptionerror或者说你自定义的一些关键词，我们是全采。只要出现关键词，我就采。这个只限于某些特定关键词是完全匹配的情况下，我才会去。这点需要注意，因为，关键词特别大的话，那关联关系会特别多。后台会承受不住，也不会特别多，因为这种关键词可能都是一些业务非常重要的点你才会去设置。不重要的点，你可以用前面的策略就可以覆盖了。

完了另外一类就是rate类的指标，比如：成功率、失败率这种指标，那这种指标就是说我刚开始讲的。成功率的话，你比如说它下降。你很难去找到相关的trace，你下降可能都没有。你反过来想成功率下降了，是不是有一些指标错误率会上升，或是失败率等会上升。这些东西我们找它相关联的东西，能不能找到一些蛛丝马迹？这个东西我们说白了也是需要。你对业务系统有一定熟悉，比如说这个成功率对应可能哪些东西有失败，你要去看那些报警，找那些trace可能会找到这个问题，稍微会有点难。

完了之后，像失败率的上升，其实简单，失败率上升，你就看它的失败那个子指标，它那个量涨了，那你就只需要看那些trace就够了。我们只需要计入分子的上涨一部分trace就够了，我们一般上涨，不会看分母，都是看分子。上涨上去。因为上涨肯定是有trace？所以说这种指标就做了这样的一个处理。

老师好，接口偶发性超时，调用链只能看到超时接口名称，看不到内部方法，无法定位根因，也难以复现，怎么办？

这个问题，因为整个trace它是一个系统间调用的一个记录。其实你的问题是在系统内，比如：JVM内某个接口慢了怎么办？那其实我们有很多的手段，比如说profile，如果可以Downdown下来去看，那你偶发性的可能在那个时刻过去就没了，现在我们可以去记录一些，如果说它慢了，我可以去一直记录它的日志。比如说现在有很多工具虽然里边主要是用开源的，比如说有Arthas吧，我可以持续记录一段时间的数据。比如：持续记录这段时间，每隔多少秒去扫一下你打到日志里面，排它问题用的一个情况，比如说：你大概知道它在什么时间内，你提前设置好。提前设置好之后，完了你到时候再看一下，相关的内存情况，你就可以定位了，因为某个接口超时无外乎就是某个方法慢，那你就看那个线程调这个方法为什么在wait？那可能需要再去排查里边的问题，基本是这么一个思路。