5 . 影响正常业务：如果SDK/探针存在设计上的缺陷，有可能导致应用出现不可预知的故障。这种情况极为罕见，但一旦发生，后果会非常严重，这种情况下一般也只能等待开源社区将问题修复后才能恢复使用。
之所以在生产环境使用开源全链路监控方案存在这么大挑战，是因为这些方案本身缺乏大规模实际业务场景的验证。对于技术实力非常强的互联网企业，会有专门的技术团队负责全链路监控项目，在使用开源产品的过程中如果遇到任何问题，都可以通过自身的技术实力进行修复和弥补。但对于绝大多数使用者而言，这些挑战所带来的都是漫长而痛苦的体验。
理想的微服务应用只有不同层级之间的单向依赖，这种依赖的原则是高层应用依赖于低层应用。同层应用之间的相互依赖，或者低层应用依赖于高层应用都是违背这个原则的。假设我们在全局拓扑视图里面，找到了环状依赖关系，说明微服务应用之间的依赖关系不清晰，可以考虑对应用的层次结构进行重构。
从应用列表进入应用总览页，首先呈现给使用者的是概览分析视图，在这个视图中，我们能够查询应用在指定时间的关键指标。右上角的时间段是一个非常重要的选项，使用者可以根据需要来修改此应用关键指标的采集时间范围（默认15分钟）。在ARMS的很多视图里面，都提供了这个选项，来帮助使用者查看指定时间范围的监控信息。
在外部调用视图中，会把下游应用每一个实例以IP+端口的形式进行呈现，我们可以通过这个视图快速定位下游应用是否有某个实例存在故障。
核心实践二：快速定位故障源和性能瓶颈
通过核心实践一介绍的功能，相信大家已经可以对整个微服务系统形成全面而深入的了解。接下来，我们需要在系统遇到故障或系统问题的时候，通过ARMS来迅速定位故障源和性能瓶颈。
我们以某个业务功能出现卡顿现象为例，来说明如何通过ARMS一步一步的进行排查。这种情况发生的时候，往往来自于前端用户的反馈，直观的表现是前端用户在进行操作的时候，返回时间比较长，或者收到系统异常相关的提示。
核查应用的整体健康状态
首先，我们从自身对于整个系统架构以及业务架构的了解，能够知道当问题发生的时候，前端用户的请求在经过安全系统、负载均衡组件以网关后，最先发往哪一个微服务应用。站在微服务链路的角度，这个应用负责接收并处理最终用户的请求，是链路的发起点，可以简称为入口应用。
我们以某个业务功能出现卡顿现象为例，来说明如何通过ARMS一步一步的进行排查。这种情况发生的时候，往往来自于前端用户的反馈，直观的表现是前端用户在进行操作的时候，返回时间比较长，或者收到系统异常相关的提示。
找到有问题的应用后，接下来可以通过对方法栈的剖析，排查出真正存在问题的代码片段。点击放大镜图标，弹出的窗口中展示了这个应用为了处理接口请求所经过的方法列表。同样，通过右侧的时间轴能够迅速定位哪一个方法执行的速度与预期不符。至此，我们已经能够确定慢调用的源头，从而有效的进行下一步的代码优化工作。
