CSDN|赠书 | SkyWalking 观测 Service Mesh 技术大公开
本文插图
导读：本文摘自于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 = 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就是采用这种进程外适配器进行集成的 。
推荐阅读
- CSDN|三次改变世界、却被无情出局的程序员
- CSDN|机器学习将会如何影响软件开发和测试？看完这文就懂了
- CSDN|语雀的技术架构演进之路
- CSDN|字节跳动、腾讯回应美国政府行政命令；英特尔回应20GB机密文档被泄露；优麒麟20.04.1发布|极客头条
- CSDNTB|监控系统选型，这篇不可不读
- CSDN|知乎技术热帖：Qt 这么强大为什么火不起来？
- CSDN|Semaphore 里面居然有这么一个大坑！
- CSDN|科技股疯狂造富的背后，“泡沫”离我们到底有多远？
- |AI不止能美颜，美妆迁移这样做 | 赠书
- CSDN|“崩溃！我再也不搞 AI 了”谷歌 AI 专家：别让你的方法打败你！