业务规模不断扩大，支撑业务运行的应用系统所采用的组件也越来越多地运用分布式、微服务架构来响应业务需求，这些组件越来越多的运用也形成了越来越复杂的分布式调用网络。所以很多企业开始部署全链路监控，而全链路监控组件这么多，应该怎么选择，又有哪些关注重点呢？大概涉及如下几点。

1、性能和稳定性

启用服务调用追踪后因为要多做些事情，一定会带来额外的性能损耗，有些应用之所以不愿意接入监控系统，就是怕影响自身服务的性能，特别是那些对性能特别敏感的应用，所以全链路追踪系统的采集模块一定要轻量，不能有太复杂的逻辑和外部依赖，以便尽可能地降低调用追踪的损耗。此外，最好能做到根据服务的流量来动态调整采集样本比例，通过配置采样率，只对一部分请求分析链路调用关系。此外，调用追踪组件的可靠性也至关重要，毕竟是要全链路接入，如果这个组件的稳定性不足，那么容易导致全链路的稳定性沦陷，这简直就是灾难。

2、代码侵入性

全链路监控组件应当对接入的业务系统尽可能少入侵或者无入侵，对于使用方透明，减少开发人员的负担。分布式追踪系统面向的客户是开发者，如果他们开发的系统需要花费较大的改造才能接入分布式追踪系统，那么接入的意愿必然会受影响。那么怎样才能把对应用系统的侵入降到最低呢？建议在公共组件和中间件上做文章。分布式系统之间的通信大多依赖RPC、MQ等中间件系统，即使是内部使用的线程池或者数据库连接池，大多也是使用经过公司包装的公共库，这就给服务追踪带来了机会，就像做业务监控时改造log4j2/logback一样，只要对中间件和公共库进行改造，就几乎可以做到全方位追踪，当然，要实现这一点，技术上的门槛也不低。

3、扩展性

扩展性，一方面是指处理能力的扩展性，随着接入的系统越来越多，监控组件自身的负载压力也必然越来越大，能否横向扩展来支撑不断接入的业务系统，是需要特别考虑的；另一方面是指插件的多样性，用户肯定希望能够支持的插件越多越好，至少要提供开放性插件开发API，对于那些官方暂时未能支持的插件，开发者也可以自行扩展。

4、数据分析及展示

数据采集和分析要全面，分析的维度要尽可能多。追踪系统能及时反馈信息，就能对运行过程中产生的异常状况快速反应。可视化的链路分析结果展现也非常重要，大家都会喜欢直观易用的工具。