全链路监控

一、概述

之前讲过监控的发展和应用及日志监控，但是都没有涉及到全链路监控、可见监控真的是一个庞大且复杂的体系，如果想理解透彻，必须理论结合实践再做深入。

二、全链路监控的原理及作用

如何衡量一个接口的性能好坏，一般至少会关注三个指标：接口的 RT 值、异常响应、慢在哪里。

单体架构中最容易的是用 AOP，使用 AOP 在调用具体的业务逻辑前后分别打印一下时间即可计算出整体的调用时间，使用 AOP 来 catch 住异常也可知道是哪里的调用导致的异常。

微服务架构中就无法准确定位每个请求经过的确切路径，微服务中的痛点：

• 排查问题难度大，周期长
• 系统性能瓶颈分析较难
• 特定场景难复现

分布式调用链就是为了解决以上几个问题而生，它主要的作用如下：

1. 自动采取数据
2. 分析数据产生完整调用链：有了请求的完整调用链，问题有很大概率可复现
3. 数据可视化：每个组件的性能可视化，能帮助我们很好地定位系统的瓶颈，及时找出问题所在

2.1、分布式调用链标准 - OpenTracing

为了解决不同的分布式追踪系统 API 不兼容的问题，诞生了 OpenTracing 规范，OpenTracing 是一个轻量级的标准化层，它位于应用程序/类库和追踪或日志分析程序之间。

OpenTracing 的数据模型，主要有以下三个：

• Trace：一个完整请求链路
• Span：一次调用过程(需要有开始时间和结束时间)
• SpanContext：Trace 的全局上下文信息, 如里面有traceId

一次请求完整就是一个 Trace, 显然对于这个请求来说，必须要有一个全局标识来标识这一个请求TraceId，每一次调用就称为一个 Span，每个Span都有一个SpanId，每一次调用都要带上全局的 TraceId, 这样才可把全局 TraceId 与每个调用SpanId关联起来，这个 TraceId 就是通过 SpanContext 传输的，既然要传输显然都要遵循协议来调用。

目前常用的是 zipkin+Sleuth、Pinpoint 、skywalking

于是一个完整的分布式追踪系统就需要

1. 怎么自动采集 span 数据：自动采集，对业务代码无侵入
2. 如何跨进程传递 context，并traceId 如何保证全局唯一
3. 请求量这么多采集不能影响性能

三、SkyWalking的原理和设计

3.1、怎么自动采集 span 数据

SkyWalking 采用了插件化 + javaagent 的形式来实现了 span 数据的自动采集，这样可以做到对代码的 无侵入性，插件化意味着可插拔，扩展性好。

3.2、如何跨进程传递 context

我们知道请求数据一般分为 header 和 body, 就像 http 有 header 和 body, RocketMQ 也有 MessageHeader，Message Body, body 一般放着业务数据，所以不宜在 body 中传递 context，应该在 header 中传递 context。

3.3、traceId 如何保证全局唯一

SkyWalking 最终采用了本地生成 ID 的方式，它采用了snowflow 算法，性能很高。

不过 snowflake 算法有一个时间回拨的问题，这个问题可能会导致生成的 id 重复，SkyWalking 中的如果发现了时间回拨，此时会生成一个随机数来作为 traceId。

这里可能会觉得这个随机数也会和已生成的全局 id 重复，要不要再加一层校验？

其实这个系统设计方案上的取舍问题了：

• 首先如果针对产生的这个随机数作唯一性校验无疑会多一层调用，会有一定的性能损耗。
• 其次时间回拨发生的概率很小，再加上生成的随机数重合的概率也很小。
• 最后就算重复了，日志中还是会有当前的一个具体时间，以及请求的 header 或者body中的关键业务数据。

综合考虑这里确实没有必要再加一层全局惟一性校验。

3.4、 全部采集会不会影响性能?

如果对每个请求调用都采集，那毫无疑问数据量会非常大，但是没有必要对每个请求都采集，我们可以设置采样频率，只采样部分数据，SkyWalking 默认设置了 3 秒采样 3 次，其余请求不采样。

为了保证链路完整性，如果上游采样了（有携带 Context ），则下游强制采集数据。

SkyWalking是节点数据的定时采样，采样后将数据定时上报，将其存储到 ES, MySQL 等持久化层，有了数据自然而然可根据数据做可视化分析。

3.5、SkyWalking 优势

• 从目前业内同行反馈结果看，SkyWalking 从性能损耗这个指标上是完胜zipkin+Sleuth、Pinpoint 。
• 对代码的侵入性 ， SkyWalking 采用 javaagent + 插件化这种修改字节码的方式可以做到对代码无任何侵入。
• 对多语言的支持，组件丰富：目前其支持 Java, .Net Core, PHP, NodeJS, Golang, LUA 语言等。
• 扩展性，对于不满足的插件，我们按照 SkyWalking 的规则手动写一个即可，新实现的插件对代码无入侵。

四、总结:

需要特别注意的是，引入某项技巧，一定要结合现有的技术架构作出最合理的选择，就像 SkyWalking 有四个模块（agent 进行采样、数据上报及分析、数据存储、数据可视化），并不是要用了它的全部组件，比如公司目前的监控生态体系已经相对比较完善，如果把其整个替换成 SkyWalking，一来没有必要，二来替换成本和学习成本太高，只需要采用 SkyWalking 的 agent 来进行采样。记住没有最好的技术，只有最合适的技术。