共计 5017 个字符，预计需要花费 13 分钟才能阅读完成。
作者：李煌东、炎寻
摘要
阿里云目前推出了面向 Kubernetes 的一站式可观测性零碎，旨在解决 Kubernetes 环境下架构复杂度高、多语言 & 多协定并存带来的运维难度高的问题，数据采集器采纳当下火出天际的 eBPF 技术，产品上反对无侵入地采集利用黄金指标，构建成全局拓扑，极大地升高了私有云用户运维 Kubernetes 的难度。
前言
背景与问题
以后，云原生技术次要是以容器技术为根底围绕着 Kubernetes 的标准化技术生态，通过规范可扩大的调度、网络、存储、容器运行时接口来提供基础设施，同时通过规范可扩大的申明式资源和控制器来提供运维能力，两层标准化推动了细化的社会分工，各畛域进一步晋升规模化和专业化，全面达到老本、效率、稳定性的优化，在这样的背景下，大量公司都应用云原生技术来开发运维利用。正因为云原生技术带来了更多可能性，以后业务利用呈现了微服务泛滥、多语言开发、多通信协议的特色，同时云原生技术自身将复杂度下移，给可观测性带来了更多挑战：
1、混沌的微服务架构
业务架构因为分工问题，容易呈现服务数量多，服务关系简单的景象（如图 1）。
图 1 混沌的微服务架构（图片起源见文末）
这样会引发一系列问题：
无法回答以后的运行架构；
无奈确定特定服务的上游依赖服务是否失常；
无奈确定特定服务的上游依赖服务流量是否失常；
无法回答利用的 DNS 申请解析是否失常；
无法回答利用之间的连通性是否正确；
…
2、多语言利用
业务架构外面，不同的利用应用不同的语言编写（如图 2），传统可观测办法须要对不同语言应用不同的办法进行可观测。
图 2 多语言（图片起源见文末）
这样也会引发一系列问题：
- 不同语言须要不同埋点办法，甚至有的语言没有现成的埋点办法；
- 埋点对利用性能影响无奈简略评估；
3、多通信协议
业务架构外面，不同的服务之间的通信协议也不同（如图 3），传统可观测办法通常是在应用层特定通信接口进行埋点。
图 3 多通信协议
这样也会引发一系列问题：
- 不同通信协议因为不同的客户端须要不同埋点办法，甚至有的通信协议没有现成的埋点办法；
- 埋点对利用性能影响无奈简略评估；
4、Kubernetes 引入的端到端复杂度
复杂度是永恒的，咱们只能找到办法来治理它，无奈打消它，云原生技术的引入尽管缩小了业务利用的复杂度，然而在整个软件栈中，他只是将复杂度下移到容器虚拟化层，并没有打消（如图 4）。
图 4 端到端软件栈
这样也会引发一系列问题：
- Deployment 的冀望正本数和理论运行正本数不统一；
- Service 没有后端，无奈解决流量；
- Pod 无奈创立或者调度；
- Pod 无奈达到 Ready 状态；
- Node 处于 Unknown 状态；
- …
解决思路与技术计划
为了解决下面的问题，咱们须要应用一种反对多语言，多通信协议的技术，并且在产品层面尽可能得笼罩软件栈端到端的可观测性需求，通过调研咱们提出一种立足于容器界面和底层操作系统，向上关联利用性能观测的可观测性解决思路（如图 5）。
数据采集
图 5 端到端可观测性解决思路
咱们以容器为外围，采集关联的 Kubernetes 可观测数据，与此同时，向下采集容器相干过程的零碎和网络可观测数据，向上采集容器相干利用的性能数据，通过关联关系将其串联起来，实现端到端可观测数据的笼罩。
数据传输链路
咱们的数据类型蕴含了指标，日志和链路，采纳了 open telemetry collector 计划（如图 6）反对对立的数据传输。
图 6 OpenTelemetry Collector（图片起源见文末）
数据存储
背靠 ARMS 已有的基础设施，指标通过 ARMS Prometheus 进行存储，日志 / 链路通过 XTRACE 进行存储。
产品外围性能介绍
外围场景上反对架构感知、错慢申请剖析、资源耗费剖析、DNS 解析性能剖析、内部性能剖析、服务连通性剖析和网络流量剖析。反对这些场景的根底是产品在设计上遵循了从整体到个体的准则：先从全局视图动手，发现异常的服务个体，如某个 Service，定位到这个 Service 后查看这个 Service 的黄金指标、关联信息、Trace 等进行进一步关联剖析。
图 7 外围业务场景
永不过期的黄金指标
什么是黄金指标？用来可观测性零碎性能和状态的最小汇合：latency、traffic、errors、saturation。以下引自 SRE 圣经 Site Reliability Engineering 一书：
The four golden signals of monitoring are latency, traffic, errors, and saturation. If you can only measure four metrics of your user-facing system, focus on these four.
为什么黄金指标十分重要？一，间接了然地表白了零碎是否失常对外服务。二，面向客户的，能进一步评估对用户的影响或事态的严重性，这样能大量节俭 SRE 或研发的工夫，设想下如果咱们取 CPU 使用率作为黄金指标，那么 SRE 或研发将会奔于疲命，因为 CPU 使用率高可能并不会造成多大的影响，尤其在运行安稳的 Kubernetes 环境中。所以 Kubernetes 可观测性反对这些黄金指标：
- 申请数 /QPS
- 响应工夫及分位数（P50、P90、P95、P99）
- 谬误数
- 慢调用数
图 8 黄金指标
次要反对以下场景：
1、性能剖析
2、慢调用剖析
全局视角的利用拓补
不谋全局者，有余谋一域。– 诸葛亮
随着当下技术架构、部署架构的复杂度越来越高，产生问题后定位问题变得越来越辣手，进而导致 MTTR 越来越高。另一个影响是对影响面的剖析带来十分大的挑战，通常顾得了这头顾不了那头。因而，有一张像地图一样的大图十分必要。全局拓扑具备以下特点：
- 零碎架构感知：零碎架构图通常称为程序员理解一个新零碎的重要参考，当咱们拿到一个零碎，起码咱们得晓得流量的入口在哪里，有哪些外围模块，依赖了哪些外部内部组件等。在异样定位过程中，有一张全局架构的图对异样定位过程有十分大的推动作用。一个简略电商利用的拓扑示例，整个架构一览无遗：
图 9 架构感知
- 依赖剖析：有一些问题是呈现在上游依赖，如果这个依赖不是本人团队保护就会比拟麻烦，当本人零碎和上游零碎没有足够的可观测性的时候就更麻烦了，这种状况下就很难跟依赖的维护者讲清楚问题。在咱们的拓扑中，通过将黄金指标的上下游用调用关系连起来，造成了一张调用图。边作为依赖的可视化，能查看对应调用的黄金信号。有了黄金信号就能疾速地剖析上游依赖是否存在问题。下图为底层服务调用微服务产生慢调用导致利用整体 RT 高的定位示例，从入口网关，到外部服务，到 MySQL 服务，最终定位到产生慢 SQL 的语句：
图 10 依赖剖析
- 高可用剖析：拓扑图能不便地看出零碎之间的交互，从而看出哪些零碎是次要外围链路或者是被重度依赖的，比方 CoreDNS，简直所有的组件都会通过 CoreDNS 进行 DNS 解析，所以咱们进一步看到可能存在的瓶颈，通过查看 CoreDNS 的黄金指标预判利用是否衰弱、是否容量有余等。
图 11 高可用剖析
- 无侵入：跟蚂蚁的 linkd 和团体的 eagleeye 不同的是，咱们的计划是齐全无侵入的。有时候咱们之所以短少某个方面的可观测性，并不是说做不到，而是因为利用须要改代码。作为 SRE 为了更好的可观测性诚然出发点很好，然而要让全团体的利用 owner 陪你一起改代码，显然是不适合的。这时候就显示出无侵入的威力了：利用不须要改代码，也不须要重启。所以在接入老本上是非常低的。
协定 Trace 不便根因定位
协定 Trace 区别于分布式追踪，只跟踪一次调用。协定 Trace 同样是无入侵、语言无关的。如果申请内容中存在分布式链路 TraceID，能自动识别进去，不便进一步下钻到链路追踪。应用层协定的申请、响应信息有助于对申请内容、返回码进行剖析，从而晓得具体哪个接口有问题。
图 12 协定详情
开箱即用的告警性能
任何一个可观测性零碎不反对告警是不适合的。
1、默认模板下发，阈值通过业界最佳实际。
图 13 告警
2、反对用户多种配置形式
动态阈值，用户只须要配置阈值即可，不须要手动写 PromQL
基于灵敏度调节的动静阈值，适宜不好确定阈值的场景
兼容 PromQL，须要肯定的学习老本，适宜高级用户
丰盛的上下文关联
datadog 的 CEO 在一次采访中婉言 datadog 的产品策略不是反对越多功能越好，而是思考怎么在不同团队和成员之间架起桥梁，尽可能把信息放在同一个页面中（to bridge the gap between the teams and get everything on the same page）。产品设计上咱们将要害的上下文信息关联起来，不便不同背景的工程师了解，从而减速问题的排查。
目前咱们关联的上下文有告警信息、黄金指标、日志、Kubernetes 元信息等，同时一直新增有价值的信息。比方告警信息，告警信息主动关联到对应的服务或利用节点上，清晰地看到哪些利用有异样，点击利用或告警能主动开展利用的详情、告警详情、利用的黄金指标，所有的动作都在一个页面中进行：
图 14 上下文关联
其余
一、网络性能可观测性：
网络性能导致响应工夫变长是常常遇到的问题，因为 TCP 底层机制屏蔽了一部分的复杂性，应用层对此是无感的，这对丢包率高、重传率高这种场景带来一些麻烦。Kubernetes 反对了重传 & 丢包、TCP 连贯信息来表征网络情况，下图展现了重传高导致 RT 高的例子：
图 15 网络性能可观测性
eBPF 超能力揭秘
图 16 数据处理流程
eBPF 相当于在内核中构建了一个执行引擎，通过内核调用将这段程序 attach 到某个内核事件上，做到监听内核事件；有了事件咱们就能进一步做协定推导，筛选出感兴趣的协定，对事件进一步解决后放到 ringbuffer 或者 eBPF 自带的数据结构 Map 中，供用户态过程读取；用户态过程读取这些数据后，进一步关联 Kubernetes 元数据后推送到存储端。这是整体处理过程。
eBPF 的超能力体现在能订阅各种内核事件，如文件读写、网络流量等，运行在 Kubernetes 中的容器或者 Pod 里的所有行为都是通过内核零碎调用来实现的，内核晓得机器上所有过程中产生的所有事件，所以内核简直是可观测性的最佳观测点，这也是咱们为什么抉择 eBPF 的起因。另一个在内核上做监测的益处是利用不须要变更，也不须要从新编译内核，做到了真正意义上的无侵入。当集群里有几十上百个利用的时候，无侵入的解决方案会帮上大忙。
eBPF 作为新技术，人们对其有些担心是失常的，这里别离作简略的答复：
1、eBPF 安全性如何？eBPF 代码有诸多限度，如最大堆栈空间以后为 512、最大指令数为 100 万，这些限度的目标就是充分保证内核运行时的安全性。
2、eBPF 探针的性能如何？大概在 1% 左右。eBPF 的高性能次要体现在内核中解决数据，缩小数据在内核态和用户态之间的拷贝。简略说就是数据在内核里算好了再给用户过程，比方一个 Gauge 值，以往的做法是将原始数据拷贝到用户过程再计算。
总结
产品价值
阿里云 Kubernetes 可观测性是一套针对 Kubernetes 集群开发的一站式可观测性产品。基于 Kubernetes 集群下的指标、利用链路、日志和事件，阿里云 Kubernetes 可观测性旨在为 IT 开发运维人员提供整体的可观测性计划。
阿里云 Kubernetes 可观测性具备以下个性：
- 代码无侵入：通过旁路技术，不须要对代码进行埋点即可获取到丰盛的网络性能数据。
- 语言无关：在内核层面进行网络协议解析，反对任意语言，任意框架。
- 高性能：基于 eBPF 技术，能以极低的耗费获取丰盛的网络性能数据。
- 强关联：通过网络拓扑，资源拓扑，资源关系从多个维度形容实体关联，与此同时也反对各类数据（可观测指标、链路、日志和事件）之间的关联。
- 数据端到端笼罩：涵盖端到端软件栈的观测数据。
- 场景闭环：控制台的场景设计，关联起架构感知拓扑、利用可观测性、Prometheus 可观测性、云拨测、衰弱巡检、事件核心、日志服务和云服务，蕴含利用了解，异样发现，异样定位的残缺闭环。
点击此处，返回阿里云可观测专题页查看更多详情！
图片起源：
图 1：
https://www.infoq.com/present…
图 2：
https://www.lackuna.com/2013/…
图 6：
https://opentelemetry.io/docs…
欢送大家扫码或搜寻钉钉群号（31588365）退出答疑交换群进行交换。
