SkyWalking观测Service Mesh技术大公开

Service Mesh的监控往往被称为可观测性（Observability），其内涵是要超越传统的监控体系的。它一般包括监控、告警、可视化、分布式追踪与日志分析。可见可观测性是监控的一个超集。监控认为目标系统是一个“黑盒”，通过观察其关键指标来展现系统状态，并报告异常情况。而可观测性在此基础上增加了“问题定位”的功能，通过可视化、分布式追踪和日志分析功能来提供给用户交互式定位问题的能力。

传统应用的SRE只能够通过监控系统发现失败的目标应用，而后由产品工程师来从代码层面最终定位到具体问题。对于维护基于Service Mesh的微服务集群，SRE就需要可观测性赋予的各种综合能力来发现更加具体的问题，这种过程类似于在微服务集群中进行调试操作。

可观测性是Service Mesh原生就需要解决的核心问题。由于Service Mesh被认为是新一代的基础设施，在其上构建可观测组件将会比在应用中构建更为便捷。同时，随着基础设施的落地与标准的逐步成型，可观测组件将会进行稳定的演进，而不会随着应用技术栈的变迁而推倒重来。基于以上原因，作用于Service Mesh之上的可观测性将会有更强的生命力与更大的商业潜力。

本文首先介绍SkyWalking的可观测性模型，然后以Istio和Envoy为例来介绍SkyWalking对它们的观测手段和未来技术的演进趋势。

SkyWalking可观测性模型

监控指标

SkyWalking主要使用“黑盒”追踪模型来生成Service Mesh的监控指标。与经典“黑盒”算法不同，SkyWalking并不会使用回归模型生成单条Trace数据，而是直接使用分析引擎构建监控指标和拓扑图。

如图所示，SkyWalking从Service Mesh数据平面获取到图中被标记为奇数的请求数据（1，3，5，7，9，11）。传统的“黑盒”算法会尝试还原被标记为偶数的链路，从而形成完整的调用链。而SkyWalking会直接进行汇总统计，计算出两节点之间的监控指标，再使用这些成对的数据构建出一段时间内的拓扑图。

Service Mesh流量图

故SkyWalking在Service Mesh模式下，Trace功能是缺失的，而其他功能是完好的。这是在效率和功能完整性之间的平衡。当然，如果希望使用Trace功能，可以通过另外一套SkyWalking集群实现。

通用Service Mesh的协议保存在 https://github.com/apache/skyw ... proto 。目前SkyWalking仅仅支持Istio，如果用户希望支持其他的Service Mesh平台，可以使用该协议向SkyWalking写入监控数据。

让我们看一下协议的核心内容：

message ServiceMeshMetric {

int64 startTime = 1;

int64 endTime = 2;

string sourceServiceName = 3;

int32 sourceServiceId = 4;

string sourceServiceInstance = 5;

int32 sourceServiceInstanceId = 6;

string destServiceName = 7;

int32 destServiceId = 8;

string destServiceInstance = 9;

int32 destServiceInstanceId = 10;

string endpoint = 11;

int32 latency = 12;

int32 responseCode = 13;

bool status = 14;

Protocol protocol = 15;

DetectPoint detectPoint = 16;

} 

如协议所示，主要内容都是写入一次调用的双端信息。这里要注意，要想获得正确的拓扑图，服务的ID要保持一致。假如需要生成A→B→C的拓扑图，则需要产生如下两条数据：

sourceServiceId = A

...

destServiceId = B

sourceServiceId = B

...

destServiceId = C

告警与可视化

Service Mesh的监控指标与分布式追踪的指标是使用统一的引擎聚合计算的，故其告警体系完全可以复用。这里唯一需要注意的是维度的映射。

以Kubernetes环境为例，其内置资源非常丰富，到底用什么资源来映射到SkyWalking的Service呢？这里选择范围是很广泛的，Deployment、Service、Statefulset看起来都可以，甚至一些Custom Resource也是可以的。这就需要使用者进行相关的设计，根据自己系统的状况来将特定的目标进行映射。目前官方的做法是使用Statefulset来映射到Service，因为它可以指向多种二级资源，监控性非常好。如果用户有定制化需求，也可以自行添加。

可视化与告警类似，只要维度定义得当，监控指标和拓扑图就会依照维度进行完美展示。

分布式追踪和日志

从理论上讲，Service Mesh并不能给追踪带来任何变化。由于Service Mesh仅仅控制了流量的入口和出口，仅仅在proxy和sidecar上增加追踪上下文的注入并不能将整个上下文在集群内传播，所以服务本身需要被注入追踪上下文。

可能有读者会认为，既然如此，那么就不要在Service Mesh组件内增加传播模块了，还能减少额外的消耗而不影响追踪链路。需要说明的是，追踪标记点越多，其实越能更好地理解系统状态，帮助定位问题。

这里举一个例子来说明在Service Mesh组件上增加追踪能力的作用。一个服务如果响应超时，传统上我们是不能区分是网络问题还是服务本身的问题的。但是有了Service Mesh的inbound agent，我们就可以从该agent有无数据来判断是哪种问题：如果inbound有数据，说明是目标服务的问题；如果inbound没有数据，则很可能是网络问题。

对于日志，SkyWalking从系统设计上并不涵盖日志的搜集和存储，但是部分用户在实践中，会使用LocalSpan将业务日志写入其中。同时由于7.0.0以后SkyWalking会引入业务扩展字段，可以预见未来将会有更多用户将SkyWalking作为接收和分析日志的系统。日志、分布式追踪与监控指标的结合也是SkyWalking后端分析的发展

目标。

观测Istio的监控指标

SkyWalking主要是接受Istio的监控指标来进行聚合分析。由于Istio并不支持SkyWalking的追踪上下文传播的功能，故这部分不在讨论范围内。现在让我们讨论一下SkyWalking与Istio的两种集成模式。

Mixer模式集成

除了网络流量控制服务以外，Istio同时提供了对Telemetry数据集成的功能。Telemetry组件主要通过Mixer进行集成，如图2所示，而这恰恰就是SkyWalking首先与Istio集成的点。早期Istio可以进行进程内的集成，即将集成代码添加到其源码进行变异，以达到最高性能。后来Istio为了降低系统的集成复杂性，将该功能演变为进程外的适配器。目前SkyWalking就是采用这种进程外适配器进行集成的。

SkyWalking集成Mixer

未来Mixer 2.0版本将会采用Envoy的WASM系统模型进行构建，Mixer插件将可以二进制形式被Envoy进行动态的变异加载。SkyWalking社区会跟进该模式，以实现新的适配器模型。

集成后，我们就可以看到如图中所示的监控指标页面和服务拓扑图了。

监控指标Dashboard

使用Mixer生成的服务拓扑图

ALS模式集成

除了进行Mixer的集成以外，SkyWalking同时可以与Envoy的ALS（Access Log Service）进行相关的系统集成（见图5），以达到Mixer类似的效果。与Envoy集成的优势在于，可以非常高效地将访问日志发送给SkyWalking的接收器，这样延迟最小。但缺点是目前的ALS发送数据非常多，会潜在影响SkyWalking的处理性能和网络带宽；同时，所有的分析模块都依赖于较为底层的访问日志，一些Istio的相关特性不能被识别。比如这种模式下只能识别Envoy的元数据，Istio的虚拟服务等无法有效识别。对比图6与图4所示的拓扑图，我们并没有发现istio-policy组件，这是由于该组件与sidecar之间的通信是不通过Envoy转发的，故从ALS中无法获得此信息。

SkyWalking与ALS

使用ALS生成的服务拓扑图

观测Istio的技术发展

目前Istio和SkyWalking都处于高速发展之中。Istio对于可观测的演进主要有以下几个方面。

• Mixer被移除。Mixer由于其性能问题将被移除，上面介绍的第一种集成模式很快会成为历史。
• Envoy WASM将会替代Mixer成为可观测的主力。未来，SkyWalking将会深度与Envoy WASM技术结合，它会带来如下好处。
• 开发灵活。WASM技术类似Nginx的LuaJIT，依靠C 与Rust语言，可以获得很好的灵活性。
• 性能优良。由于WASM代码会被编译到Envoy内部，其性能有很好的保证。
• 功能丰富。根据不能的场景，可以提供不同的插件组合，组合出更丰富的功能。基于以上的特点，SkyWalking对于Envoy和Istio可能有以下演进方向的影响。
• 使Envoy和Istio支持SkyWalking专用的追踪传播协议。
• 精细控制Envoy发送到OAP的数据粒度，目前ALS模式传入的数据过于繁杂，且不能裁剪，使用WASM插件后希望可以进行更细的控制。
• 支持更多的控制平面。由于使用Envoy作为数据平面的Service Mesh系统已经有一定规模，使用WASM模式可以避免与特定控制平面绑定，从而支持更多的系统。

本文转载自《Apache SkyWalking实战》一书，本文经出版社授权发布。