2020年8月1日

SkyWalking 观测 Service Mesh 技术大公开

作者 Admin

导读:本文摘自于SkyWalking创始人吴晟撰写的《Apache SkyWalking实战》一书,介绍了SkyWalking对Service Mesh的监控模型,并重点阐述了其与Istio的集成。通过本文,希望你对SkyWalking观测Service Mesh场景有深入的了解,并从中窥探该方向未来的发展路径。

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

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

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

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

SkyWalking可观测性模型

1、监控指标

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/skywalking-data-collect-protocol/blob/v6.6.0/service-mesh-probe/service-mesh.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 = BsourceServiceId = B...destServiceId = C 

2、告警与可视化

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

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

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

3、分布式追踪和日志

从理论上讲,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的两种集成模式。

1、Mixer模式集成

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

SkyWalking集成Mixer

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

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

监控指标Dashboard
使用Mixer生成的服务拓扑图

2、ALS模式集成

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

SkyWalking与ALS
<div class="output_wrapper" id="output_wrapper_id" style="font-size: 16px; color: rgb(62, 62, 62); line-height: 1.6; word-spacing: 0px; letter-spacing: 0px; font-family: 'Helvetica Neue', Helvetica, 'Hiragino Sans GB', 'Microsoft YaHei', Arial, sans-serif;"><pre style="font-size: inherit; color: inherit; line-height: inherit; margin: 0px; padding: 0px;"><code class="hljs makefile" style="margin: 0px 2px; line-height: 18px; font-size: 14px; font-weight: normal; word-spacing: 0px; letter-spacing: 0px; font-family: Consolas, Inconsolata, Courier, monospace; border-radius: 0px; color: rgb(169, 183, 198); background: rgb(40, 43, 46); overflow-x: auto; padding: 0.5em; white-space: pre !important; word-wrap: normal !important; word-break: normal !important; overflow: auto !important; display: -webkit-box !important;">sourceServiceId&nbsp;=&nbsp;A<br>...<br>destServiceId&nbsp;=&nbsp;B<br>sourceServiceId&nbsp;=&nbsp;B<br>...<br>destServiceId&nbsp;=&nbsp;C<br></code></pre></div> 
使用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模式可以避免与特定控制平面绑定,从而支持更多的系统。

关于SkyWalking的实战内容推荐阅读《Apache SkyWalking实战》一书,本文经出版社授权发布。

作者简介:吴晟,Apache基金会会员,Apache SkyWalking创始人、项目VP和PMC成员,Apache孵化器PMC成员,Apache ShardingSphere PMC成员,Apache APISIX (incubating) PPMC成员,Apache ECharts (incubating)和Apache DolphinScheduler (incubating)孵化器导师,Zipkin成员和贡献者,CNCF OpenTracing核心维护者。