基于 eBPF 的 Kubernetes 可观测实践

本文涉及的产品
可观测可视化 Grafana 版,10个用户账号 1个月
EMR Serverless StarRocks,5000CU*H 48000GB*H
应用实时监控服务ARMS - 应用监控,每月50GB免费额度
简介: 阿里云可观测团队构建了 kubernetes 统一监控,无侵入式地提供多语言、应用性能黄金指标,支持多种协议,结合 Kubernetes 管控层与网络系统层监控,提供全栈一体式的可观测体验。通过流量拓扑、链路、资源的关系,可进行关联分析,进一步提升在 Kubernetes 环境下排查问题的效率。

作者:刘洋(炎寻)


可观测是为了解决问题,所以在聊可观测之前,应先对问题排查的普适原则进行了解。


背景介绍


问题排查的原则


1.png


以排查系统问题为例,要理解系统,要先关注基础知识,理解编程语言基本的计算机科学知识,关注系统大图比如架构部署和重大流程,要关注运行细节,要对核心功能的算法和数据结构了然于心,还要关注系统的运维工具,能够了解发布、回滚和监控。


在理解的基础上,还要能够复现问题,主要关注问题发生的触发条件以及问题发生时数据现场的保留,包含指标、链路、日志、事件等。


有了现场再加之对于系统的,才可以定位问题。通过现场保留的数据,进行关联分析;基于理解,可以快速用二分定位到根因。在定位的过程中,尤其要关注变更,因为有大量的系统问题是由变更导致的。


确定根因后再进行修复,既要治标也要治本,并且要充分验证,确保不引入新的问题。


以上为问题排查的普适原则,它不仅适用于系统问题的排查,也可以应用到生活的方方面面。


而可观测使得问题排查的过程更加高效、稳定、低成本。它能够帮助我们理解系统,出现问题的时候能够留下足够多的现场,能够使数据之间很方便地进行关联,帮助我们做二分的关联分析,最终还可以验证修复是否正确。


Kubernetes 可观测挑战


2.jpeg


复杂度是恒定的,它不会消失,只会转移。我们构建的编程语言、编程框架、容器操作系统都只是将复杂度关在合适的地方。如果一切运行正常,皆大欢喜;而一旦出现问题,就是灾难。复杂度不断下沉的趋势使得可观测面临了很大的压力。Kubernetes 的流行使得微服务架构十分普及,多语言、多通信协议成为常态,这也在另一方面带来了挑战。


挑战 1:端到端观测复杂度上升,埋点成本居高不下。然而这只是冰山一角,有大量能力下沉到 Kubernetes 管控层、容器运行层、网络和操作系统层面,这些基础设施能力的下沉带来了很大挑战。


挑战 2:由于关注点的分离,使得应用问题与底层问题无法自顶向下形成关联。


挑战 3:虽然有很多工具,但是上下文缺失、数据散落,导致无法通过这些数据很好地理解应用,因为现场的缺失无法关联,而使问题排查效率低下。


可观测需要有统一的技术来解决自身的复杂度。


基于 eBPF 的可观测实践分享


eBPF 介绍


3.png


从一开始,内核就是可观测的绝佳位置,然而由于效率和安全问题一直无法实现。经过多年发展,eBPF 技术为可观测打开了新的大门。


eBPF 是一项可以安全地在内核中运行沙盒程序的技术,无需修改代码即可在内核用户态程序事件发生时运行。它具备以下特性:


无侵入特性:观测成本极低,应用无需修改任何代码,也无需重启进程。


动态可编程性:无需重启探针,动态下发 eBPF 脚本即可修改探针侧的逻辑。


高性能:自带 JIT 编译,使探针能够获得内核本地运行的效率。


安全:verifier 机制限制了 eBPF 脚本能够访问的内核函数,保证内核运行的稳定。


除了这些令人振奋的特性外,eBPF 的使用流程也非常方便。以监控、应用、性能为例,只需要加载编译 eBPF 程序监听网络的内核事件,解析网络协议,然后聚合成指标,输出 Trace 即可。


eBPF 得到了很多大公司的支持,发展十分迅猛。过去一年,阿里云可观测团队基于 eBPF 技术构建了统一可观测平台。其架构如下图:

image.gif

4.png

基于 eBPF 的统一可观测平台架构


最底层是数据采集层,主要采用 Tracepoints、Kprobre、eBPF 函数抓取相关系统调用,关联进程容器信息,形成原始事件,并通过 eBPF 和 sysdig 的结合支持多内核版本。同时为了解决事件爆炸的问题,引入了事件过滤和高性能事件传输机制。


往上是数据处理层。用户态获取到原始事件后,首先进行协议的解析,生成指标、链路、日志等数据,过程中也会对信息做收敛。然后填充元信息,比如 K8s 信息填充或自定义应用信息填充,最后监控数据会通过 OpenTelemetry Collector 输出。引入 OpenTelemetry Collector 主要为了支持多种数据类型以及多数据传输通道,支持将监控数据写入用户指定的存储。


再往上是数据存储层,默认情况下,指标会使用 influxDB 存储在 Prometheus,链路和日志使用 SLS 存储在 Trace。


最上是数据服务层,通过 ARMS 的前端以及 Grafana 最终呈现给用户多种多样的可观测服务。


如何进行无侵入式多语言的协议解析


5.png


ARMS 可观测团队关注 eBPF 在应用层的应用,通过监听网络内核调用,构建连接跟踪,将传输的网络包进行协议分析,得到应用层面的请求响应,最终得以无侵入式地支持多语言场景下请求数、响应时间、错误数、黄金指标的监控。


目前我们支持 HTTP、 Redis 、DNS、Kafka、MySQL、gRPC 、http2 等协议,支持的协议列表也在不断扩充中。


线上问题与解决方法


6.pngimage.gif

经过一年多的生产实践,遇到最多的问题主要有以下四个:


第一,内核版本适配问题。eBPF 在内核版本 4.14 以上才有较为成熟的支持。但是线上依然存在很多老的内核版本,这部分需要使用 sysdig 进行支持。高版本在 core 不成熟的情况下,使用动态下载内核图文件以及动态编译的方式进行支持。


第二,内核事件爆炸。传统的监听 Tracepoints、Kprobre 会产生巨大的事件,给探针的性能造成巨大压力。为了解决这个问题,我们引入了事件过滤机制,只处理网络调用事件,同时优化事件传输序列化,达到高性能事件传输的目的。


第三,在事件的消费侧,协议解析效率低下。为此我们优化了高性能解析算法,比如可以减少分析的字节数,优化更多的匹配算法提升解析的效率。同时还使用了多线程内存复用等工程手段提升协议解析效率。


第四,指标时间线爆炸。所有事件最终都会聚合为指标、链路和日志,其中指标方面由于个别维度发散,会对存储的稳定性造成极大的影响。因此,我们支持在写指标的时候进行维度收敛,比如每个维度的基数不得超过 100,超过后将收敛成星号,代表通用的收敛标记。此外,还在查询侧进行了优化,主要做了精度的降级。


统一可观测交互界面


统一告警


7.jpegimage.gif


eBPF 技术的无侵入性以及多语言支持的特性使得开箱即用成为了可能。基于此,阿里云可观测团队开始构建统一可观测界面。


首先是统一告警。接入阿里云 eBPF 监控,我们设计了一套默认的告警模板,涵盖了应用层、 K8s 管控层、基础设施层和云服务层,提供了开箱即用的帮助用户发现问题的能力。


统一的关联分析逻辑


8.png


有了 eBPF 保存现场数据,加上告警系统告知存在问题,后续应如何统一进行关联分析,找到根因?


我们认为需要有一个界面来承载关联分析逻辑。它应当目标明确,比如要解决容量规划问题、成本消耗问题还是应用性能问题;它应当内容丰富,包含解决问题需要的所有内容,比如指标、链路、日志、事件、问题的影响面、关联关系等;它应当具备非常清晰的使用路径,能够回答当前是否有问题,未来是否有问题、问题的影响是什么、问题的根因是什么、用户能做什么等,以此一步步引导用户解决问题。


统一 Grafana 大盘


9.png


基于以上设想,我们推出了统一的 Grafana 大盘。它符合关联分析逻辑,无论是全局还是特定实体都有总览,能够发现问题细节,能够排查问题;它包含日志、事件、指标等多数据源,以告警异常阈值为驱动,整个大盘可以交互、点击跳转,可以定位根因,涵盖了 K8s 集群最核心的资源类型。


统一拓扑图


10.pngimage.gif


我们也推出了统一的拓扑大图,它具备拓扑感知、依赖分析、流量监控、上下文关联等特性,可以按维度筛选节点和边,构建业务语义化的视图。


Demo 演示:基于 eBPF 的统一交互页面


11.png

image.gif

在容器服务 ACK 进入一个集群后,点击运维管理,进入集群拓扑功能页面。如果没有安装 eBPF 探针则会提示安装,安装完成后开箱即用,可以获得整个集群的流量拓扑。


页面包含了 deployment、deamonset、和 statfulset 之间的流量关系。点击节点可以看到它对外提供的应用性能,也可以查看节点的上下游。通过上下游的查看,可以快速检查它是否按照预定的架构运行。


此外,也可以点击边进行查看,比如可以看到 MySQL 的 QPS 以及响应时间等。


12.png


除了查看指标,还可以查看详情,比如查看 SQL 语句以及网络耗时,比如请求发到对端用了多久、对端处理用了多久、响应的内容下载耗时多久等,可以快速定位问题所在。同时还提供了节点过滤的能力,可以快速过滤出用户感兴趣的节点,同时也可以搜索对应的节点。


13.png


Grafana 统一的大盘为 1+N 的模式。1是指集群的全局大盘提供了整个集群最核心的资源总览,包含事件,可以快速查看各类事件的个数及详情,可以查看节点是否健康、无状态应用 deployment 是否健康以及有状态应用、deamonset 等。


14.png


每一个特定资源总览的结构也是一致的,包含“总”和“分”。“总”是对整个集群进行概括的总结,可以快速通过阈值确认是否有问题,有问题的阈值会用鲜艳的颜色标出。比如上图可以看出有 1 个节点的 CPU 请求率过高,而具体哪一个节点的请求率过高,则由“分”负责查找,通过请求率排序,快速找到问题节点。image.gif


15.png


上图显示集群级别有两个 Pod 不是 ready 状态。通过对 phase 进行排序快速获取两个处于 pending 状态的 Pod。也可以看到有 15 个 Pod 在过去 24 小时存在重启行为,进行排序后即可快速找到这些 Pod。image.gif


16.png


可以点击具体节点,查看其 CPU 请求率的 top 10 ,点击查看详情后可在系统资源里进行查看,以判断请求量是否合理,并进行修正。


由此可见,Grafana 大盘具备很强的交互能力和逻辑。


17.png


前端应用的每一个 deployment 或资源详情页也具备排查逻辑。概览中展示了管控层、CPU、网络、内存等情况,一眼便能知晓系统是否存在问题,可以快速查看问题所在。


18.png


与此同时,大盘还集成了日志以及 7 层的应用性。


以上能力全部是基于 eBPF 的无侵入性提供的开箱即用的能力。


总结与展望


总结


19.pngimage.gif


阿里云可观测团队构建了 kubernetes 统一监控,无侵入式地提供多语言、应用性能黄金指标,支持多种协议,结合 Kubernetes 管控层与网络系统层监控,提供全栈一体式的可观测体验。通过流量拓扑、链路、资源的关系,可进行关联分析,进一步提升在 Kubernetes 环境下排查问题的效率。


展望


20.pngimage.gif


未来,阿里云可观测团队将进一步挖掘 eBPF 全覆盖、无侵入、可编程的特性,在以下三个方面持续发力:


第一,可扩展 APM,简称 eAPM。围绕 APM 不断扩展边界,解决其侵入每种语言都需要单独埋点的问题,解决在应用层面看不到的底层黑盒问题,包括以下几个方面:


1. 无侵入式的多语言性能监控。


2. 无侵入式的分布式链路追踪。


3. 应用请求粒度的系统与网络分析。


第二,提供工具,针对包括 tracing、profiling、动态网络包跟踪以及内核事件在用户态进行处理的开发框架进行优化。


第三, 实现 eBPF 增强的内置指标、链路和日志,主要包括对应用协议更多的支持以及高阶的系统指标和网络指标。


21.jpeg

相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
2月前
|
Kubernetes 开发工具 Docker
微服务实践k8s与dapr开发部署实验(2)状态管理
微服务实践k8s与dapr开发部署实验(2)状态管理
75 3
微服务实践k8s与dapr开发部署实验(2)状态管理
|
1月前
|
Kubernetes Cloud Native 微服务
微服务实践之使用 kube-vip 搭建高可用 Kubernetes 集群
微服务实践之使用 kube-vip 搭建高可用 Kubernetes 集群
219 3
|
2月前
|
存储 运维 监控
Kubernetes 集群监控与日志管理实践
【5月更文挑战第28天】在微服务架构日益普及的当下,容器编排工具如 Kubernetes 已成为运维工作的核心。有效的集群监控和日志管理是确保系统稳定性和服务可靠性的关键。本文将深入探讨 Kubernetes 集群的监控策略,以及如何利用现有的工具进行日志收集、存储和分析,以实现对集群健康状况的实时掌握和问题快速定位。
|
2月前
|
存储 监控 Kubernetes
Kubernetes 集群监控与日志管理实践
【5月更文挑战第27天】 在微服务架构日益普及的当下,容器化技术与编排工具如Kubernetes已成为现代云原生应用的基石。然而,随着集群规模的不断扩大和复杂性的增加,如何有效监控和管理这些动态变化的服务成为了维护系统稳定性的关键。本文将深入探讨Kubernetes环境下的监控策略和日志管理的最佳实践,旨在为运维人员提供一套系统的解决思路,确保应用性能的最优化和问题的快速定位。
|
18天前
|
Prometheus 监控 Kubernetes
深入理解Prometheus: Kubernetes环境中的监控实践
Kubernetes简介 在深入Prometheus与Kubernetes的集成之前,首先简要回顾一下Kubernetes的核心概念。Kubernetes是一个开源的容器编排平台,用于自动化容器的部署、扩展和管理。它提供了高度的可扩展性和灵活性,使得它成为微服务和云原生应用的理想选择。 核心组件 • 控制平面(Control Plane):集群管理相关的组件,如API服务器、调度器等。 • 工作节点(Nodes):运行应用容器的机器。 • Pods:Kubernetes的基本运行单位,可以容纳一个或多个容器。
|
21天前
|
Kubernetes Ubuntu Linux
k8s部署grafana beyla实现app应用服务依赖图可观测
k8s部署grafana beyla实现app应用服务依赖图可观测
28 4
|
2月前
|
运维 Kubernetes 持续交付
构建高效自动化运维体系:基于Docker和Kubernetes的实践
【5月更文挑战第30天】 在当今的快速迭代和持续部署的软件发布环境中,自动化运维的重要性愈发凸显。本文旨在探讨如何利用容器化技术与微服务架构,特别是Docker和Kubernetes,来构建一个高效、可伸缩且自愈的自动化运维体系。通过详细分析容器化的优势及Kubernetes的集群管理机制,文章将提供一个清晰的指南,帮助读者理解并实现现代软件部署的最佳实践。
|
2月前
|
运维 Kubernetes 监控
Kubernetes 集群的持续性能优化实践
【5月更文挑战第30天】 在动态且日益复杂的云原生环境中,维持 Kubernetes 集群的高性能运行是一个持续的挑战。本文将探讨一系列针对性能监控、问题定位及优化措施的实践方法,旨在帮助运维专家确保其 Kubernetes 环境能够高效、稳定地服务于不断变化的业务需求。通过深入分析系统瓶颈,我们不仅提供即时的性能提升方案,同时给出长期维护的策略建议,确保集群性能的可持续性。
|
2月前
|
运维 Prometheus 监控
Kubernetes 集群监控与日志管理实践
【5月更文挑战第29天】 在微服务架构日益盛行的今天,容器化技术已成为现代应用部署的标准。其中,Kubernetes 作为容器编排的事实标准,其集群的稳定性和性能监控变得至关重要。本文将深入探讨 Kubernetes 集群的监控策略和日志管理的最佳实践,旨在为运维工程师提供一套高效、可靠的集群监控解决方案。通过引入 Prometheus 和 Grafana 工具进行数据收集与可视化,以及 Fluentd 和 Elasticsearch 配合 Kibana 实现日志聚合与分析,本文将带领读者构建起一个全面的 Kubernetes 监控系统,确保系统的高可用性和故障快速响应。
|
2月前
|
存储 Kubernetes 监控
Kubernetes 集群的持续性能优化实践
【5月更文挑战第28天】 在动态且复杂的微服务架构中,保持 Kubernetes 集群的高性能和稳定性是一项挑战。本文将探讨一系列实用的性能监测、调优策略以及最佳实践,旨在帮助运维专家确保其容器化应用能在 Kubernetes 环境中达到最优表现。我们将通过分析真实案例,总结出一套系统化的优化流程,并介绍相关工具与技术,使读者能够对 Kubernetes 集群进行有效的性能监控和提升。

推荐镜像

更多