全链路监控建设的 4 个重点
业务规模不断扩大,支撑业务运行的应用系统所采用的组件也越来越多地运用分布式、微服务架构来响应业务需求,这些组件越来越多的运用也形成了越来越复杂的分布式调用网络。所以很多企业开始部署全链路监控,而全链路监控组件这么多,应该怎么选择,又有哪些关注重点呢?大概涉及如下几点。
1、性能和稳定性
启用服务调用追踪后因为要多做些事情,一定会带来额外的性能损耗,有些应用之所以不愿意接入监控系统,就是怕影响自身服务的性能,特别是那些对性能特别敏感的应用,所以全链路追踪系统的采集模块一定要轻量,不能有太复杂的逻辑和外部依赖,以便尽可能地降低调用追踪的损耗。此外,最好能做到根据服务的流量来动态调整采集样本比例,通过配置采样率,只对一部分请求分析链路调用关系。此外,调用追踪组件的可靠性也至关重要,毕竟是要全链路接入,如果这个组件的稳定性不足,那么容易导致全链路的稳定性沦陷,这简直就是灾难。
2、代码侵入性
全链路监控组件应当对接入的业务系统尽可能少入侵或者无入侵,对于使用方透明,减少开发人员的负担。分布式追踪系统面向的客户是开发者,如果他们开发的系统需要花费较大的改造才能接入分布式追踪系统,那么接入的意愿必然会受影响。那么怎样才能把对应用系统的侵入降到最低呢?建议在公共组件和中间件上做文章。分布式系统之间的通信大多依赖 RPC、MQ 等中间件系统,即使是内部使用的线程池或者数据库连接池,大多也是使用经过公司包装的公共库,这就给服务追踪带来了机会,就像做业务监控时改造 log4j2/logback 一样,只要对中间件和公共库进行改造,就几乎可以做到全方位追踪,当然,要实现这一点,技术上的门槛也不低。
3、扩展性
扩展性,一方面是指处理能力的扩展性,随着接入的系统越来越多,监控组件自身的负载压力也必然越来越大,能否横向扩展来支撑不断接入的业务系统,是需要特别考虑的;另一方面是指插件的多样性,用户肯定希望能够支持的插件越多越好,至少要提供开放性插件开发 API,对于那些官方暂时未能支持的插件,开发者也可以自行扩展。
4、数据分析及展示
数据采集和分析要全面,分析的维度要尽可能多。追踪系统能及时反馈信息,就能对运行过程中产生的异常状况快速反应。可视化的链路分析结果展现也非常重要,大家都会喜欢直观易用的工具。
版权声明: 本文为 InfoQ 作者【穿过生命散发芬芳】的原创文章。
原文链接:【http://xie.infoq.cn/article/2cd0332169d68f80baaed65db】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论