开源的全链路监控方案能帮助开发者更深入的理解全链路监控的思想、原理以技术细节，但在在生产环境大规模使用开源方案，还是会给开发者带来很大的挑战：
首先，我们从自身对于整个系统架构以及业务架构的了解，能够知道当问题发生的时候，前端用户的请求在经过安全系统、负载均衡组件以网关后，最先发往哪一个微服务应用。站在微服务链路的角度，这个应用负责接收并处理最终用户的请求，是链路的发起点，可以简称为入口应用。
在调用链路视图中，可以查看到整个调用链路中，所经历的每一个应用的调用类型、服务名、IP地址，以及耗时。通过右侧的时间轴，能一步定位到哪一个应用存在性能瓶颈。
主机监控报警模板：CPU 水位过高或磁盘空间不足场景的报警
4、进程异常报警模板：进程存活场景的报警
5、GC异常报警模板：有过多的 FullGC、FullGC 耗时长或 YoungGC 耗时长场景的报警
这5条默认的报警模板很有用，代表着ARMS对于最通用的一些报警场景的抽象，我们保留这几个模板，只在细节方面做出少许调整，用最少的配置提升风险预知的能力。
除了Java语言外，ARMS还提供了PHP探针，PHP应用接入ARMS后，能够拥有和Java应用同样的全链路监控体验。除了Java和PHP之外 ，ARMS还对主流的编程语言提供了支持，我们可以选择开源的探针/SDK接入ARMS。
受益于统一的全链路监控模型，如果一个微服务体系中存在多种语言之间的相互调用，只要把对应的应用都接入ARMS，就能够跨越多语言对调用链路进行统一的管理和分析。
受限制于篇幅的原因，本文只能介绍全链路监控最核心的一些实践，作为全链路监控以及应用性能管理领域的标杆产品，ARMS还有更多的功能特性等待着我们去挖掘，我们可以对照帮助文档逐步学习。
工程师在实践中会掌握大量细节，但是，即使掌握了所有细节，却没有深刻的总结和思考，也会陷入到“学而不思则罔”的境地。成长的“量变”来自于对细节的逐渐深入地把控，而真正的“质变”来自于对“道”的更深层次的理解。
接下来我将总结自己在工作中碰到和看到的一些典型困惑。这些困惑或者长期困扰作者本人，或者困扰我身边的同事和朋友。当这些困惑被释然之后，大家都感觉如重获释，为下一阶段的征程提供满满的正能量。人生就像一场旅途，不必在乎目的地，在乎的，应该是沿途的风景，以及看风景的心情。
