SkyWalking观测Service Mesh技术大公开 | 周末送书

K8s已经成为一线大厂分布式平台的标配技术。你是不是还在惆怅怎么掌握它?来这里,大型互联网公司一线工程师亲授,不来虚的,直接上手实战,3天时间带你搭建K8s平台,快速学会K8s,点击下方图片可了解培训详情。

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

SkyWalking观测Service Mesh技术大公开 | 周末送书_第1张图片

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 = 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观测Service Mesh技术大公开 | 周末送书_第2张图片

SkyWalking集成Mixer

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

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

SkyWalking观测Service Mesh技术大公开 | 周末送书_第3张图片

监控指标Dashboard

SkyWalking观测Service Mesh技术大公开 | 周末送书_第4张图片

使用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观测Service Mesh技术大公开 | 周末送书_第5张图片

SkyWalking与ALS

SkyWalking观测Service Mesh技术大公开 | 周末送书_第6张图片

使用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实战》,经出版方授权发布。本次联合机械工业出版社华章公司为大家带来7本书作为福利。在文末留言中写下对SkyWalking的认识与看法,截止8月4日12点前,评论点赞数前7名的读者将获取图书1本。没获奖的同学可以点击下方链接购买。

基于Kubernetes的DevOps实战培训

基于Kubernetes的DevOps实战培训将于2020年8月14日在上海开课,3天时间带你系统掌握Kubernetes,学习效果不好可以继续学习。本次培训包括:容器特性、镜像、网络;Kubernetes架构、核心组件、基本功能;Kubernetes设计理念、架构设计、基本功能、常用对象、设计原则;Kubernetes的数据库、运行时、网络、插件已经落地经验;微服务架构、组件、监控方案等,点击下方图片或者阅读原文链接查看详情。

你可能感兴趣的:(SkyWalking观测Service Mesh技术大公开 | 周末送书)