应用监控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，则表示支持。如果输出其他内容，则表示不支持。