移动端和pc网站,网站建设培训南宁,app开发一个多少钱,自动升级wordpress失败简介#xff1a;通过 eBPF 无侵入地采集多语言、多网络协议的黄金指标/网络指标/Trace#xff0c;通过关联 Kubernetes 对象、应用、云服务等各种上下文#xff0c;同时在需要进一步下钻的时候提供专业化的监测工具#xff08;如火焰图#xff09;#xff0c;实现了 Kube…简介通过 eBPF 无侵入地采集多语言、多网络协议的黄金指标/网络指标/Trace通过关联 Kubernetes 对象、应用、云服务等各种上下文同时在需要进一步下钻的时候提供专业化的监测工具如火焰图实现了 Kubernetes 环境下的一站式可观测性平台。
作者 | 李煌东
当 Kubernetes 成为云原生事实标准可观测性挑战随之而来
当前云原生技术以容器技术为基础通过标准可扩展的调度、网络、存储、容器运行时接口来提供基础设施。同时通过标准可扩展的声明式资源和控制器来提供运维能力两层标准化推动了开发与运维关注点分离各领域进一步提升规模化和专业化达到成本、效率、稳定性的全面优化。
在这样的大技术背景下越来越多的公司引入了云原生技术来开发、运维业务应用。正因为云原生技术带来了越发纷繁复杂的可能性业务应用出现了微服务众多、多语言开发、多通信协议的鲜明特征。同时云原生技术本身将复杂度下移给可观测性带来了更多挑战 1、混沌的微服务架构多语言和多网络协议混杂
业务架构因为分工问题容易出现服务数量多调用协议和关系非常复杂的现象导致的常见问题包括
无法准确清晰了解、掌控全局的系统运行架构无法回答应用之间的连通性是否正确多语言、多网络调用协议带来埋点成本呈线性增长且重复埋点 ROI 低开发一般将这类需求优先级降低但可观测数据又不得不采集。
2、下沉的基础设施能力屏蔽实现细节问题定界越发困难
基础设施能力继续下沉开发和运维关注点继续分离分层后彼此屏蔽了实现细节数据方面不好关联了出现问题后不能迅速地定界问题出现在哪一层。开发同学只关注应用是否正常工作并不关心底层基础设施细节出现问题后需要运维同学协同排查问题。运维同学在问题排查过程中需要开发同学提供足够的上下游来推进排查否则只拿到“某某应用延迟高”这么笼统的表述这很难有进一步结果。所以开发同学和运维同学之间需要共同语言来提高沟通效率Kubernetes 的 Label、Namespace 等概念非常适合用来构建上下文信息。
3、繁多监测系统造成监测界面不一致
复杂系统带来的一个严重副作用就是监测系统繁多。数据链路不关联、不统一监测界面体验不一致。很多运维同学或许大多都有过这样的体验定位问题时浏览器打开几十个窗口在 Grafana、控制台、日志等各种工具之间来回切换不仅非常耗时巨大且大脑能处理的信息有限问题定位效率低下。如果有统一的可观测性界面数据和信息得到有效地组织减少注意力分散和页面切换来提高问题定位效率把宝贵时间投入到业务逻辑的构建上去。
解决思路与技术方案
为了解决上述问题我们需要使用一种支持多语言多通信协议的技术并在产品层面尽可能覆盖软件栈端到端的可观测性需求通过调研我们提出一种立足于容器界面和底层操作系统向上关联应用性能监测的可观测性解决思路。 要采集容器、节点运行环境、应用、网络各个维度的数据挑战非常大云原生社区针对不同需求给出了 cAdvisor、node exporter、kube-state-metics 等多种方式但仍然无法满足全部需求。维护众多采集器的成本也不容小觑引发的一个思考是能否有一种对应用无侵入的、支持动态扩展的数据采集方案目前最好的答案是 eBPF。
1、「数据采集eBPF 的超能力」 eBPF 相当于在内核中构建了一个执行引擎通过内核调用将这段程序 attach 到某个内核事件上实现监听内核事件。有了事件我们就能进一步做协议推导筛选出感兴趣的协议对事件进一步处理后放到 ringbuffer 或者 eBPF 自带的数据结构 Map 中供用户态进程读取。用户态进程读取这些数据后进一步关联 Kubernetes 元数据后推送到存储端。这是整体处理过程。
eBPF 的超能力体现在能订阅各种内核事件如文件读写、网络流量等运行在 Kubernetes 中的容器或者 Pod 里的一切行为都是通过内核系统调用来实现的内核知道机器上所有进程中发生的所有事情所以内核几乎是可观测性的最佳观测点这也是我们为什么选择 eBPF 的原因。另一个在内核上做监测的好处是应用不需要变更也不需要重新编译内核做到了真正意义上的无侵入。当集群里有几十上百个应用的时候无侵入的解决方案会帮上大忙。
但作为新技术人们对 eBPF 也存在些许担忧比如安全性与探针性能。为了充分保证内核运行时的安全性eBPF 代码进行了诸多限制如最大堆栈空间当前为 512、最大指令数为 100 万。与此同时针对性能担忧eBPF 探针控制在大约在 1%左右。其高性能主要体现在内核中处理数据减少数据在内核态和用户态之间的拷贝。简单说就是数据在内核里算好了再给用户进程比如一个 Gauge 值以往的做法是将原始数据拷贝到用户进程再计算。
2、可编程的执行引擎天然适合可观测性
可观测性工程通过帮助用户更好的理解系统内部状态来消除知识盲区和及时消除系统性风险。eBPF 在可观测性方面有何威力呢
以应用异常为例当发现应用有异常后解决问题过程中发现缺少应用层面可观测性这时候通过埋点、测试、上线补充了应用可观测性具体的问题得到了解决但往往治标不治本下一次别的地方有问题又需要走同样的流程另外多语言、多协议让埋点的成本更高。更好的做法是用无侵入方式去解决以避免需要观测时没有数据。
eBPF 执行引擎可通过动态加载执行 eBPF 脚本来采集可观测性数据举个具体例子假设原本的 Kubernetes 系统并没有做进程相关的监测有一天发现了某个恶意进程如挖矿程序在疯狂地占用 CPU这时候我们会发现这类恶意的进程创建应该被监测起来这时候我们可以通过集成开源的进程事件检测库来是实现但这往往需要打包、测试、发布这一整套流程全部走完可能一个月就过去了。
相比之下eBPF 的方式显得更为高效快捷由于 eBPF 支持动态地加载到内核监听进程创建的事件所以我们可以将 eBPF 脚本抽象成一个子模块采集客户端每次只需要加载这个子模块里的脚本完成数据采集再通过统一的数据通道将数据推送到后端。这样我们就省去了改代码、打包、测试、发布的繁琐流程通过无侵入的方式动态地实现了进程监测这样的需求。所以eBPF 可编程的执行引擎非常适合用来将增强可观测性将丰富的内核数据采集上来通过关联业务应用方便问题排查。 从监测系统到可观测性
随着云原生浪潮可观测性概念正深入人心。但仍离不开日志、指标、链路这三类可观测领域的数据基石。做过运维或 SRE 的同学经常遇到这样的问题半夜被拉到应急群里披头盖地地被质问为什么数据库不工作了在没有上下文的情况下无法立刻抓住问题核心。我们认为好的可观测性平台应该帮助用户很好地反馈上下文就像 Datadog 的 CEO 说的那样监测工具不是功能越多功能越好而是要思考怎样在不同团队和成员之间架起桥梁尽可能把信息放在同一个页面中to bridge the gap between the teams and get everything on the same page。
因此在可观测性平台产品设计上需要以指标、链路、日志为基本向外集成阿里云自家的各类云服务同时也支持开源产品数据接入将关键上下文信息关联起来方便不同背景的工程师理解进而加速问题排查。信息没有有效地组织就会产生理解成本信息粒度上以事件-指标-链路-日志由粗到细地组织到一个页面中方便下钻不需要多个系统来回跳转从而提供一致体验。 那么具体怎么关联呢信息怎么组织呢主要从两方面来看
1、端到端展开说就是应用到应用服务到服务Kubernetes 的标准化和关注点分离各自开发运维各自关注各自领域那么端到端的监测很多时候成了”三不管“区域出现问题的时候很难排查链路上哪个环节出了问题。因此从端到端的角度来看两者调用关系是关联的基础因为系统调用才产生了联系。通过 eBPF 技术非常方便地以无侵入的方式采集网络调用进而将调用解析成我们熟知的应用协议如 HTTP、GRPC、MySQL 等最后将拓扑关系构建起来形成一张清晰的服务拓扑后方便快速定位问题如下图中网关-Java 应用-Python 应用-云服务的完整链路中任意一环出现延时在服务拓扑中应能一眼看出问题所在。这是第一个管线点端到端。
2、自顶向下全栈关联以 Pod 为媒介Kubernetes 层面关联 Workload、Service 等对象基础设施层面可以关联节点、存储设备、网络等应用层面关联日志、调用链路等。 接下来介绍下 Kubernetes 监测的核心功能。
1、永不过时的黄金指标
黄金指标是用来监测系统性能和状态的最小集合。黄金指标有两个好处一直接了然地表达了系统是否正常对外服务。二能快速评估对用户的影响或事态的严重性能大量节省 SRE 或研发的时间想象下如果我们取 CPU 使用率作为黄金指标那么 SRE 或研发将会奔于疲命因为 CPU 使用率高可能并不会造成多大的影响。
Kubernetes 监测支持这些指标
请求数/QPS响应时间及分位数P50、P90、P95、P99错误数慢调用数
如下图所示 2、全局视角的服务拓扑
诸葛亮曾言“不谋全局者不足谋一域 ”。随着当下技术架构、部署架构的复杂度越来越高发生问题后定位问题变得越来越棘手进而导致 MTTR 越来越高。另一个影响是对影响面的分析带来非常大的挑战通常会造成顾此失彼。因此有一张像地图一样的拓扑大图非常必要。全局拓扑具有以下特点
系统架构感知系统架构图是程序员了解一个新系统的重要参考当拿到一个系统起码需要知晓流量入口在哪里有哪些核心模块依赖了哪些内部外部组件等。在异常定位过程中有一张全局架构的图对异常定位进程有非常大推动作用。依赖分析有一些问题是出现在下游依赖如果这个依赖不是自己团队维护就会比较麻烦当自己系统和下游系统没有足够的可观测性的时候就更麻烦了这种情况下就很难跟依赖的维护者讲清楚问题。在我们的拓扑中通过将黄金指标的上下游用调用关系连起来形成了一张调用图。边作为依赖的可视化能查看对应调用的黄金信号。有了黄金信号就能快速地分析下游依赖是否存在问题。3、分布式 Tracing 助力根因定位
协议 Trace 同样是无入侵、语言无关的。如果请求内容中存在分布式链路 TraceID能自动识别出来方便进一步下钻到链路追踪。应用层协议的请求、响应信息有助于对请求内容、返回码进行分析从而知道具体哪个接口有问题。如需查看代码级别或请求界别的详情可点击 Trace ID 下钻到链路追踪分析查看。 4、开箱即用的告警功能
开箱即用的告警模板各个不同层次全覆盖不需要手动配置告警将大规模 Kubernetes 运维经验融入到告警模板里面精心设计的告警规则加上智能降噪和去重我们能够做到一旦告警就是有效的告警并且告警里面带有关联信息可以快速定位到异常实体。告警规则全栈覆盖的好处是能及时、主动地将高风险事件报给用户用户通过排查定位、解决告警、事后复盘、面向失败设计等一系列手段最终逐步达成更好的系统稳定性。 5、网络性能监测
网络性能问题在 Kubernetes 环境中很常见由于 TCP 底层机制屏蔽了网络传输的复杂性应用层对此是无感的这对生产环境定位丢包率高、重传率高这种问题带来一定的麻烦。Kubernetes 监测支持了 RTT、重传丢包、TCP 连接信息来表征网络状况下面以 RTT 为例支持从命名空间、节点、容器、Pod、服务、工作负载这几个维度来看网络性能支持以下各种网络问题的定位
负载均衡无法访问某个 Pod这个 Pod 上的流量为 0需要确定是否这个 Pod 网络有问题还是负载均衡配置有问题某个节点上的应用似乎性能都很差需要确定是否节点网络有问题通过对别的节点网络来达到链路上出现丢包但不确定发生在那一层可以通过节点、Pod、容器这样的顺序来排查。Kubernetes 可观测性全景视角
有了上述产品能力基于阿里巴巴在容器、Kubernetes 方面有着丰富且极具深度的实践我们将这些宝贵生产实践归纳、转化成产品能力以帮助用户更有效、更快捷地定位生产环境问题。使用这个排查全景图可以通过以下方法
大体结构上是以服务和 Deployment应用为入口大多数开发只需要关注这一层就行了。重点关注服务和应用是否错慢服务是否连通副本数是否符合预期等再往下一层是提供真正工作负载能力的 Pod。Pod 重点关注是否有错慢请求是否健康资源是否充裕下游依赖是否健康等最底下一层是节点节点为 Pod 和服务提供运行环境和资源。重点关注节点是否健康是否处于可调度状态资源是否充裕等。1、网络问题
网络是 Kubernetes 中最棘手、最常见的问题因为以下几个原因给我们定位生产环境网络问题带来麻烦
Kubernetes 的网络架构复杂度高节点、Pod、容器、服务、VPC 交相辉映简直能让你眼花缭乱网络问题排查需要一定的专业知识大多数对网络问题都有种天生的恐惧分布式 8 大谬误告诉我们网络不是稳定的、网络拓扑也不一成不变的、延时不可忽视造成了端到端之间的网络拓扑不确定性。
Kubernetes 环境下场景的网络问题有
conntrack 记录满问题IP 冲突CoreDNS 解析慢、解析失败节点没开外网。对你没听错服务访问不通配置问题LoadBalance 配置、路由配置、device 配置、网卡配置网络中断造成整个服务不可用。
网络问题千千万万但万变不离其宗的是网络有其表征其是否正常运行的”黄金指标“
网络流量和带宽丢包数率和重传数率RTT。
下面的示例展示了因网络问题导致的慢调用问题。从 gateway 来看发生了慢调用查看拓扑发现调下游 product 的 RT 比较高但是 product 本身的黄金指标来看 product 本身服务并没有问题进一步查看两者之间的网络状况发现 RTT 和重传都比较高说明网络性能恶化了导致了整体的网络传输变慢TCP 重传机制掩盖了这个事实在应用层面感知不到日志也没法看出问题所在。这时候网络的黄金指标有助于定界出问题从而加速了问题的排查。 2、节点问题
Kubernetes 做了大量工作尽可能确保提供给工作负载和服务的节点是正常的节点控制器 7x24 小时地检查节点的状态发现影响节点正常运行的问题后将节点置为 NotReady 或不可调度通过 kubelet 把业务 Pod 从问题节点中驱逐出去。这是 Kubernetes 的第一道防线第二道防线是云厂商针对节点高频异常场景设计的节点自愈组件如阿里云的 node repairer发现问题节点后执行排水驱逐、置换机器从而做到自动化地保障业务正常运行。即便如此节点在长期使用过程中不可避免地会产生各种奇奇怪怪的问题定位起来比较费时耗力。常见问题分类和级别: 针对这些繁杂的问题总结出如下排查流程图 以一个 CPU 打满为例1、节点状态 OKCPU 使用率超过了 90% 2、查看对应的 CPU 的三元组使用率、TopN、时序图首先每个核的使用率都很高进而导致整体 CPU 使用高接下来我们自然要知道谁在疯狂地使用 CPU从 TopN 列表来看有个 Pod 一枝独秀地占用 CPU最后我们得确认下 CPU 飙高是什么时候开始的。 3、服务响应慢
造成服务响应非常多场景可能的原因有代码设计问题、网络问题、资源竞争问题、依赖服务慢等原因。在复杂的 Kubernetes 环境下定位慢调用可以从两个方案去入手首先应用自身是否慢其次下游或网络是否慢最后检查下资源的使用情况。如下图所示Kubernetes 监测分别从横向和纵向来分析服务性能
横向主要是端到端层面来看首先看自己服务的黄金指标是否有问题再逐步看下游的网络指标。注意如果从客户端来看调用下游耗时高但从下游本身的黄金指标来看是正常的这时候非常有可能是网络问题或者操作系统层面的问题此时可以用网络性能指标流量、丢包、重传、RTT 等来确定。纵向确定应用本身对外的延时高了下一步就是确定具体哪个原因了确定哪一步/哪个方法慢可以用火焰图来看。如果代码没有问题那么可能执行代码的环境是有问题的这时可以查看系统的 CPU/Memory 等资源是否有问题来做进一步排查。下面举个 SQL 慢查询的例子如下图。在这个例子中网关调用 product 服务 product 服务依赖了 MySQL 服务逐步查看链路上的黄金指标最终发现 product 执行了一条特别复杂的 SQL关联了多张表导致 MySQL 服务响应慢。MySQL 协议基于 TCP 之上的我们的 eBPF 探针识别到 MySQL 协议后组装、还原了 MySQL 协议内容任何语言执行的 SQL 语句都能采集到。 第二个例子是应用本身慢的例子这时候自然会问具体哪一步、哪个函数造成了慢 ARMS 应用监控支持的火焰图通过对 CPU 耗时定期采样如下图帮助快速定位到代码级别问题。 4、应用/Pod 状态问题
Pod 负责管理容器容器是真正执行业务逻辑的载体。同时 Pod 是 Kubernetes 调度的最小单元所以 Pod 同时拥有了业务和基础设施的复杂度需要结合着日志、链路、系统指标、下游服务指标综合来看。Pod 流量问题是生产环境高频问题比如数据库流量陡增当环境中有成千上万个 Pod 时排查流量主要来自哪个 Pod 就显得特别困难。 接下来我们看一个典型的案例下游服务在发布过程中灰度了一个 Pod该 Pod 因代码原因响应非常慢导致上游都超时了。之所以能做到 Pod 级别的可观测是因为我们用 ebpf 的技术来采集 Pod 的流量、黄金指标因此可以通过拓扑、大盘的方式方便地查看 Pod 与 Pod、Pod 与服务、Pod 与外部的流量。 总结
通过 eBPF 无侵入地采集多语言、多网络协议的黄金指标/网络指标/Trace通过关联 Kubernetes 对象、应用、云服务等各种上下文同时在需要进一步下钻的时候提供专业化的监测工具如火焰图实现了 Kubernetes 环境下的一站式可观测性平台。
如果您在架构云原生监测的过程中有以下困扰那么请毫不犹豫的联系我们一起探讨
对 Kubernetes 不熟悉需要一整套完整的统一监测方案Prometheus、Alertmanager、Grafana 等多个系统的数据割裂和上手难;容器环境下应用、基础设施埋点成本过高正在寻找低成本或无侵入的解决方案
原文链接
本文为阿里云原创内容未经允许不得转载。
