应用监控eBPF 版调研

参考:

https://www.toutiao.com/article/7327353509735596559/?app=news_article×tamp=1717488680&use_new_style=1&req_id=20240604161119838096AAE4AD4F44788E&group_id=7327353509735596559&wxshare_count=1&tt_from=weixin&utm_source=weixin&utm_medium=toutiao_android&utm_campaign=client_share&share_token=b4685197-c1c1-43b6-ae92-0e1d9d77d29a&source=m_redirect&wid=1717555127344

应用实时监控服务(ARMS)-阿里云帮助中心

1.概述

阿里云应用监控 eBPF 版是一套针对K8s集群的一站式可观测性产品,为K8s集群安装应用监控 eBPF 版组件后,即可查看基于K8s集群下的指标、应用链路、日志和事件,为IT开发运维人员提供整体的可观测性方案。

eBPF(extended Berkeley Packet Filter)是一种在Linux内核中运行的技术,它允许用户编写并在内核中运行小型程序,以实现高效的数据包过滤、监控和分析。eBPF程序可以用于实时数据分析、性能监控、安全审计等方面。

在数据采集方面,eBPF可以用于实时监控系统的网络流量、性能指标、进程活动等。通过编写适当的eBPF程序,可以实现对特定数据的捕获、分析和记录。

2.特性

代码无侵入:通过旁路技术,不需要对代码进行埋点即可获取到丰富的网络性能数据。

语言无关:在内核层进行网络协议解析,支持任意语言,任意框架。

高性能:基于eBPF技术,能以极低的消耗获取丰富的网络性能数据。

资源关联:通过网络拓扑,资源拓扑展示相关资源的关联。

数据多样:支持可观测的各种类型数据(监控指标、链路、日志和事件)。

整体性:通过控制台的场景设计,关联起架构感知拓扑、Prometheus监控、告警配置。

3.功能说明

3.1.应用监控

3.1.1.应用概述

支持对各种类型数据进行可视化展示。应用的请求数、错误数、平均耗时、实例数、CPU使用率、内存使用量、请求数的服务排行、错误数排行和平均耗时服务排行。

3.1.2.应用拓扑

通过监控分析网络请求,自动解析网络协议,构建网络拓扑便于查看服务依赖状态、关联网络性能、错慢请求明细。

3.1.3.提供、依赖服务

应用提供的接口的调用详情。其中接口概述可以查看对应接口的调用详情,包括请求数、错误数、平均耗时,同时展示HTTP状态统计和慢调用;调用链,可以查看对应接口的Span调用详情。

说明:接口的Span调用详情通常指的是在分布式系统中使用分布式追踪工具(如Jaeger、Zipkin等)记录和展示接口调用链的详细信息。这些工具通过在代码中插入特定的Span(跨度)来跟踪请求在不同服务之间的传递和处理过程。

具体来说,当一个请求进入系统时,会创建一个根Span,然后在处理过程中,每个服务或组件都会创建自己的Span,并在Span中记录相关信息,如开始时间、结束时间、耗时、标签、日志等。这些Span会形成一个调用链,展示了请求在系统中的流转路径和耗时情况。

通过查看接口的Span调用详情,可以了解每个接口调用的耗时、调用链路、错误信息等,帮助分析系统性能问题、排查故障、优化服务调用顺序等。

3.1.4.调用链分析

显示整体调用情况(调用链采样率为5%),包括调用次数、HTTP错误数和耗时百分位。

3.1.5.数据库分析

支持查看目标数据库的名称、类型、SQL语句、请求数、慢请求数、平均耗时,以及对应的时序曲线和分布情况。

3.1.5.实例监控

服务监控:CPU使用量、内存使用量、请求数、平均耗时和错误数

网络监控:应用接收的包数、TCP RTT、重传次数、TCP Drop次数和发送的包数;

容器监控查看容器视角的CPU、内存、Disk(磁盘)、Load(负载)、网络流量和网络数据包的各项指标。

3.1.6.持续剖析

可以有效发现应用程序中因为CPU导致的瓶颈问题,并且按照方法名称、类名称和行号进行细分统计,最终协助开发者优化程序、降低延迟、增加吞吐、节约成本。

当前持续剖析的能力是基于eBPF实现的,因为无侵入的特点,针对Go等有Debug符号信息的语言,Profiling的数据能够显示具体的函数调用,如果遇到unknown的函数,表示当前函数无法在内核中找到对应的符号表信息。

Self列表示方法在自身的调用栈中所消耗的时间或资源,不包括其子方法调用所消耗的时间或资源。可以用于识别哪些方法在自身内部花费了大量的时间或资源。

Total列包含方法自身消耗的时间或资源,以及其所有子方法调用所消耗的时间或资源。可以帮助了解整个方法调用栈中哪些方法贡献了最多的时间或资源。

如需排查具体的热点代码逻辑,可以通过重点关注Self列或直接查看右侧火焰图中底部的较宽火苗从中定位到高耗时的业务方法,较宽火苗是引发上层耗时高的根源,一般是系统性能的瓶颈所在,可以重点关注。

3.2.告警监控

提供开箱即用的告警模板,可以根据预置的告警模板创建告警规则,也可以自定义针对特定k8s集群的告警规则。当告警规则被触发时,系统的通知策略会以指定的告警方式向联系人发送告警信息,以提醒告警联系人采取必要的问题解决措施。

3.2.1.阈值检测

根据需求选择对应的告警应用、指标类型和筛选条件设置告警触发模式(单/多条件)、告警条件、通知策略等可以制定针对特定的告警规则。当告警规则被触发时,系统会以指定的通知方式向告警联系人或钉群发送告警信息,以提醒采取必要的解决措施。

支持jvm、定时任务、异常监控、提供/依赖服务统计、主机监控、线程池、http状态码异常、数据库多种指标类型监控。如下http状态码异常的指标描述:

支持建议阈值功能可以根据选择的应用、接口和告警指标,通过智能算法对该指标的历史数据进行分析,推荐较为合理的静态阈值。该功能还支持实时生成指标和阈值的对比图,方便调节阈值。

3.2.2.区间检测

如果需要检测的指标在正常状态下起伏不定(例如RT和QPS),不同的时间段需要适配的告警阈值不同,那么您可以使用区间检测功能,通过动态阈值对指标数据进行异常检测。当数据点的异常突变超出预设的上下边界时,系统将生成区间异常检测事件,这种检测主要用于监控趋势稳定的数据或指标。

示例:某工作网站的访问量在白天(例如10:00~18:00)访问量低于1000是异常的,但在夜间(例如22:00~06:00)访问量超过1000可能是被攻击了。在这种场景下,指标的正常水位会随着时间变化而不断变化。 如果配置一个固定阈值,例如低于1000就告警,那白天访问异常时可以正常收到告警通知,但夜间如果被攻击则无法及时收到告警通知;如果使用区间检测功能,就可以智能识别正常水位,自动更新阈值区间。

应用场景监测服务的资源使用和响应性能。当某个服务出现异常,可以迅速定位问题,从而使管理员能够快速定位及时调整资源分配避免潜在的系统崩溃优化程序性能确保整个系统的稳定运行。

3.2.3.管理告警规则

可以对告警规则执行启动、停止、编辑、删除、查看告警详情等操作,还可以针对指定告警规则发送测试告警验证告警规则是否生效。

4.运行环境要求和限制

版本:Kubernetes v1.20及以上版本

运行环境:阿里云ACK集群(ACK Serverless集群暂不支持)、其他K8s集群。CentOS集群暂不支持。

支持的网络协议:HTTP1.1、MySQL、Redis、Kafka、DNS

服务器:

环境

要求

架构

x86-64

内存

建议≥4 GB,至少预留300 MB。

CPU

建议≥2 Core,至少预留0.3 Core。

内核版本

≥4.9

操作系统发行版本

Alibaba Cloud Linux 2

Alibaba Cloud Linux 3

其他操作系统:

执行以下命令,查询当前操作系统是否支持。

cat /boot/config-$(uname -r) | grep CONFIG_DEBUG_INFO_BTF

如果输出CONFIG_DEBUG_INFO_BTF=y,则表示支持。

如果输出其他内容,则表示不支持。

5.协议解析框架

基于 eBPF 来进行应用监控必须进行协议解析。

5.1.传统框架

主要流程为:数据采集、数据传递、协议解析。

首先eBPF从内核态中抓取到流量事件,包括控制事件如connect、close 等;数据事件如 read、write 等。采用 perf buffer(一种特殊 eBPF Map)来做数据传递,将事件从内核态传递至用户态进行协议解析。

这种方案导致CPU、内存占用过高,在高流量场景下错误率较高,主要体现如下:

高内存占用:数据采集中无法筛选协议,导致大量无关数据占满 perf buffer,引发内存过高。

事件丢失风险:高 QPS 导致 perf buffer 迅速填满,处理不及时会丢失事件,特别是控制层事件可能因数据层事件过多而丢失。

解析效率低:需要遍历尝试所有支持协议才能找到正确的协议,导致大量无效解析,增加 CPU 负担。

5.2.高效框架

基于传统框架中存在的问题,提出一种高效的协议解析框架,并在阿里云应用实时监控服务 ARMS “应用监控 eBPF 版”中正式发布。主要流程为:数据采集、协议推断、事件分流、协议解析(包含连接维护、数据分帧、协议解析、请求-响应匹配)。

首先eBPF从内核态中抓取到流量事件,根据协议帧头进行协议推断,可以初步判断是否是支持的协议。如果判断为“是”,后续才传递至用户态进一步解析,否则不处理。

然后根据事件类型进行分流。如控制事件放到control events perf buffer 中,数据事件放到data event perf buffer。

在用户态中,控制事件将用于连接维护。如长连接中,连接元数据信息总是相同的,不必每次都放入 perf buffer 中,只用传递连接 ID 可进一步降低网络带宽。data event perf buffer可以理解为数据流,需要进行分帧处理,从整个数据流中分解出每一帧的数据是进行协议解析的前提。

分解出单独的帧数据后将通过初步推断的协议类型去匹配解析器进一步解析。解析出请求与响应后,需要去匹配请求和响应,完成一个完成的可观测记录,即 record,后续也将通过 record 来生成可观测中的 Span。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值