网站二次备案,管理咨询培训,知名跟单网站做信号提供方,网站平台策划方案导读#xff1a;本文摘自于SkyWalking创始人吴晟撰写的《Apache SkyWalking实战》一书#xff0c;介绍了SkyWalking对Service Mesh的监控模型#xff0c;并重点阐述了其与Istio的集成。通过本文#xff0c;希望你对SkyWalking观测Service Mesh场景有深入的了解#xff0c;… 导读本文摘自于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数据平面获取到图中被标记为奇数的请求数据1357911。传统的“黑盒”算法会尝试还原被标记为偶数的链路从而形成完整的调用链。而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 B
sourceServiceId B
...
destServiceId C2、告警与可视化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的ALSAccess Log Service进行相关的系统集成见图13-5以达到Mixer类似的效果。与Envoy集成的优势在于可以非常高效地将访问日志发送给SkyWalking的接收器这样延迟最小。但缺点是目前的ALS发送数据非常多会潜在影响SkyWalking的处理性能和网络带宽同时所有的分析模块都依赖于较为底层的访问日志一些Istio的相关特性不能被识别。比如这种模式下只能识别Envoy的元数据Istio的虚拟服务等无法有效识别。对比图13-6与图13-4所示的拓扑图我们并没有发现istio-policy组件这是由于该组件与sidecar之间的通信是不通过Envoy转发的故从ALS中无法获得此信息。SkyWalking与ALSdiv classoutput_wrapper idoutput_wrapper_id stylefont-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 stylefont-size: inherit; color: inherit; line-height: inherit; margin: 0px; padding: 0px;code classhljs makefile stylemargin: 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;sourceServiceIdnbsp;nbsp;Abr...brdestServiceIdnbsp;nbsp;BbrsourceServiceIdnbsp;nbsp;Bbr...brdestServiceIdnbsp;nbsp;Cbr/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核心维护者。#欢迎来留言#对此你怎么看留言点赞数量最多的前三名CSDN携手【机械工业出版社】送出吴晟撰写的《Apache SkyWalking实战》一本截至8月14日12:00点更多推荐阅读中台架构详解上 | 大咖说中台游戏行业应该如何建设数据中台30 年开源老兵10 年躬耕 OpenStack开源 1000 万行核心代码Python再夺冠上古语言COBOL大流行IEEE Spectrum 2020年度编程语言排行榜出炉美国禁止与字节跳动及微信交易腾讯股价暴跌字节跳动回应了
