石头游戏网

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

简介: 监控指标Dashboard使用Mixer生成的服务拓扑图2、ALS模式集成除了进行Mixer的集成以外,SkyWalking同时可以与Envoy的ALS(Access Log Service)进行相关的系统集成(见图1

导读:本文摘自于SkyWalking创始人吴晟撰写的《Apache SkyWalking实战》一书,介绍了SkyWalking对Service Mesh的监控模型,并重点阐述了其与Istio的集成。

通过本文,希望你对SkyWalking观测Service Mesh场景有深入的了解,并从中窥探该方向未来的发展路径。

Service Mesh的监控往往被称为可观测性(Observability),其内涵是要超越传统的监控的。

而可观测性在此基础上增加了“问题定位”的功能,通过可视化、分布式和日志分析功能来给用户交互式定位问题的能力。

传统应用的SRE只能够通过监控系统发现失败的目标应用,而后由产品工程师来从代码层面最终定位到具体问题。

对于维护基于Service Mesh的微服务集群,SRE就需要可观测性赋予的各种综合能力来发现更加具体的问题,这种过程类似于在微服务集群中进行调试操作。

由于Service Mesh被认为是新一代的基础设施,在其上构建可观测组件将会比在应用中构建更为便捷。

同时,随着基础设施的落地与标准的逐步成型,可观测组件将会进行稳定的演进,而不会随着应用技术栈的变迁而推倒重来。

基于以上原因,作用于Service Mesh之上的可观测性将会有更强的生命力与更大的商业潜力。

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

SkyWalking可观测性模型1、监控指标SkyWalking主要使用“黑盒”模型来生成Service Mesh的监控指标。

如图所示,SkyWalking从Service Mesh数据平面获取到图中被标记为奇数的请求数据(1,3,5,7,9,11)。

而SkyWalking会直接进行汇总统计,计算出两节点之间的监控指标,再使用这些成对的数据构建出一段时间内的拓扑图。

Service Mesh 流量图故SkyWalking在Service Mesh模式下,Trace功能是缺失的,而其他功能是完好的。

目前SkyWalking仅仅支持Istio,如果用户希望支持其他的Service Mesh平台,可以使用该协议向SkyWalking写入监控数据。

假如需要生成A→B→C的拓扑图,则需要产生如下两条数据:sourceServiceId = A...destServiceId = BsourceServiceId = B...destServiceId = C2、告警与可视化Service Mesh的监控指标与分布式的指标是使用统一的引擎聚合计算的,故其告警完全可以复用。

这里选择范围是很广泛的,Deployment、Service、Statefulset看起来都可以,甚至一些Custom Resource也是可以的。

这就需要使用者进行相关的设计,根据自己系统的状况来将特定的目标进行映射。

目前官方的做法是使用Statefulset来映射到Service,因为它可以指向多种二级资源,监控性非常好。

由于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的上下文传播的功能,故这部分不在讨论范围内。

1、Mixer模式集成除了网络流量控制服务以外,Istio同时了对Telemetry数据集成的功能。

Telemetry组件主要通过Mixer进行集成,如图13-2所示,而这恰恰就是SkyWalking首先与Istio集成的点。

早期Istio可以进行进程内的集成,即将集成代码添加到其源码进行变异,以达到最高性能。

后来Istio为了降低系统的集成复杂性,将该功能演变为进程外的适配器。

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中无法获得此信息。

Mixer由于其性能问题将被移除,上面介绍的第一种集成模式很快会成为历史。

由于WASM代码会被编译到Envoy内部,其性能有很好的保证。

基于以上的特点,SkyWalking对于Envoy和Istio可能有以下演进方向的影响。

精细控制Envoy发送到OAP的数据粒度,目前ALS模式传入的数据过于繁杂,且不能裁剪,使用WASM插件后希望可以进行更细的控制。

由于使用Envoy作为数据平面的Service Mesh系统已经有一定规模,使用WASM模式可以避免与特定控制平面绑定,从而支持更多的系统。

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


以上是文章"

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

"的内容,欢迎阅读石头游戏网的其它文章