背景
对于普通系统或者服务来说,一般通过打日志来进行埋点,然后再通过elk进行定位及分析问题,更有甚者直接远程服务器,使用各种linux命令单手操作查看日志,说到这,我也没摆脱这种困境。那么随着业务越来越复杂,企业应用也进入了分布式服务化的阶段,传统的日志监控等方式无法很好达到跟踪调用,排查问题等需求。
总之,在各种服务之间调用:
- 如何快速发现问题?
- 如何判断故障影响范围?
- 如何梳理服务依赖以及依赖的合理性?
- 如何分析链路性能问题以及实时容量规划?
如何在分布式服务进行日志监控呢?首先大家会想到分布式链路追踪系统,说到这,就得讲 OpenTracing 规范,OpenTracing 是一个轻量级的标准化层,它位于应用程序/类库和追踪或日志分析程序之间。详细介绍见 opentracing文档中文版。
在谷歌论文《 Dapper,大规模分布式系统的跟踪系统》的指导下,许多优秀的APM应运而生。分布式追踪系统发展很快,种类繁多,给我们带来很大的方便。但在数据采集过程中,有时需要侵入用户代码,并且不同系统的 API 并不兼容,这就导致了如果您希望切换追踪系统,往往会带来较大改动。OpenTracing为了解决不同的分布式追踪系统 API 不兼容的问题。
##技术调研指标
面对各种链式追踪系统开源,我们要如何选择:
我们主要关注在请求处理期间各个调用的各项性能指标,比如:吞吐量(TPS)、响应时间及错误记录等。
- 吞吐量,根据拓扑可计算相应组件、平台、物理设备的实时吞吐量。
- 响应时间,包括整体调用的响应时间和各个服务的响应时间等。
- 错误记录,根据服务返回统计单位时间异常次数。
全链路性能监控 从整体维度到局部维度展示各项指标,将跨应用的所有调用链性能信息集中展现,可方便度量整体和局部性能,并且方便找到故障产生的源头,生产上可极大缩短故障排除时间。
我们除了性能指标之外,我们也需要链式追踪系统拥有以下功能:
- 请求链路追踪,故障快速定位:可以通过调用链结合业务日志快速定位错误信息。
- 可视化: 各个阶段耗时,进行性能分析。
- 依赖优化:各个调用环节的可用性、梳理服务依赖关系以及优化。
- 数据分析,优化链路:可以得到用户的行为路径,汇总分析应用在很多业务场景。
当然这些要求可能有些过分了,但我们换着自己的目标进行技术选型。
接下来我们主要来介绍四种常见的开源链式追踪系统,除了一些背景、所使用技术栈、支持的技术栈&#