《3.首届eBPF大会_gala-gopher:基于eBPF技术的系统白盒观测能力 v1.0.pptx》由会员分享,可在线阅读,更多相关《3.首届eBPF大会_gala-gopher:基于eBPF技术的系统白盒观测能力 v1.0.pptx(13页珍藏版)》请在三个皮匠报告上搜索。
1、首届中国首届中国eBPFeBPF研讨会研讨会gala-gopher:基于eBPF技术的系统白盒观测能力背景介绍背景介绍随着数字社会建设,云计算、云原生等技术的普及,云场景基础设施变得越来越厚重。公开数据显示,云场景重要故障与基础设施密切相关,主流云厂商(AWS/GCP等)月平均故障150+次数1,75%的故障1H,90%5H。根据历史数据统计,云上应用性能劣化、卡顿是根据历史数据统计,云上应用性能劣化、卡顿是TOPTOP问题之一问题之一。基础设施相关的软件包括:操作系统、数据库、中间件、基础库等。其中操作系统承担衔接应用、资源的关键桥梁,其可维护性的重要性不言而喻其中操作系统承担衔接应用、资源
2、的关键桥梁,其可维护性的重要性不言而喻。首届中国首届中国eBPFeBPF研讨会研讨会011 Characterizing User and Provider Reported Cloud Failures,Mehmet Berk Cetin 2021 现状及思考:现状及思考:Bottom-upBottom-up主动式系统级运维主动式系统级运维首届中国首届中国eBPFeBPF研讨会研讨会02TO-BEu OS智能运维方案特征:Bottom-Up;主动运维;以被集成方式,作为TOP-DOWN技术方案的补充。u 典型场景:数据库场景:redis、mysql、openGauss等;分布式存储场景虚拟化
3、WEB/CDN、HPC隐患发现及问题定位业务流实时拓扑构建故障传播图构建应用/系统状态高保真采集低负载探针应用/系统画像应用SLI感知各地域用户体验如何?业务运行是否正常?应用状态监控容器、中间件问题?应用代码问题?BOTTOM-UP 技术方案u 传统运维方案特征:Top-Down;被动运维;感知应用SLI为入口层层下钻。u 局限性:等问题:无法主动发现问题。难监控:服务类应用(比如redis)无法直接观测SLI。无监控:资源类应用(比如ECS)不同使用方式、业务场景,无法定义通用、有效SLI。TOP-DOWN 技术方案应用SLI感知各地域用户体验如何?业务运行是否正常?应用状态监控容器、中间
4、件问题?应用代码问题?资源状态监控资源不足?OS问题?人工介入分析专家会诊故障识别、诊断AS-IS传统运维的局限性举例:u应用SLI有明确定义,等问题:传统运维基于Top-Down方式诊断只能被动“等”问题出现,运维人员总是被动响应。u应用SLI有明确定义,难监控:如DCS场景,租户实际体验的SLI(redis QPS)与DCS拨测结果不一致,难以发现租户层故障。u应用SLI无明确定义,无监控:如ECS场景,资源类服务的SLI受租户行为、应用类型、负载波谷等因素影响,无法明确定义SLI。A-OpsA-Ops系统整体的介绍系统整体的介绍首届中国首届中国eBPFeBPF研讨会研讨会03智能运维平台
5、(智能运维平台(A-Ops)应用运维智能运维HUB硬件故障预测 系统配置溯源系统漏洞巡检基础设施监控系统参数修复应用性能诊断系统性能瓶颈诊断应用性能监控容器逃逸防护变更影响分析应用安全运维工具集自动部署自动化及监控生态伙伴集成客户自定义系统对接广泛的技术支持基础软件运维平台(A-Ops)高保真采集架构感知配置溯源异常检测x-diagnose.大前端监控(移动端/浏览器/小程序)应用监控(功能/性能/调用链)数据中心监控(服务器/网络/存储)系统实时拓扑A-OpsA-Ops工作原理介绍工作原理介绍首届中国首届中国eBPFeBPF研讨会研讨会04STEP1:系统监控白盒化定义系统范围的实体对象OS
6、OS资源/数据应用资源/数据应用STEP2:系统架构拓扑化定义实体对象之间的拓扑关系STEP3:诊断过程可视化定义全栈软件的因果关系规则基础设施至应用的根因推导过程硬件:NIC/DISK/MEM等内核:NET/IO/SCHED/MEM等容器/进程/线程/TCP等应用SLI:数据库QPS等01系统硬件/资源出现故障02故障扩散至内核子系统03故障扩散至容器/进程04故障体现至应用性能劣化定位:云基础设施场景中,针对基础设施灰度故障导致的性能劣化、卡顿系统级故障在线诊断。gala-gopher:作为A-Ops组件之一,承担系统监控白盒化职责,基于包括eBPF在内的多种技术,集成各类探针(包括第三方
7、探针)提供系统Metrics采集、系统异常检测、性能火焰图等能力。操作系统观测现状及对策:操作系统观测现状及对策:gala-gophergala-gopher首届中国首届中国eBPFeBPF研讨会研讨会05问题问题1 1)OSOS观测工具七国八制,新工具层出不穷(观测工具七国八制,新工具层出不穷(BCCBCC、BPFTraceBPFTrace、iostatiostat、netstatnetstat等),等),缺乏观测标准缺乏观测标准。2 2)OSOS观测以模块、功能角度定义,观测以模块、功能角度定义,观测结果与业务结果存在观测结果与业务结果存在GAPGAP,观测结果无法支撑业务运维诉求。,观测
8、结果无法支撑业务运维诉求。3 3)常见)常见OSOS观测工具存在底噪大、依赖多观测工具存在底噪大、依赖多,存存在生产环境无法持续部署在生产环境无法持续部署的问题。的问题。4 4)OSOS观测观测工具碎片化工具碎片化,对运维人员而言,只是工具箱(依赖有经验的,对运维人员而言,只是工具箱(依赖有经验的SRESRE操作),工具之间无法协同工作。操作),工具之间无法协同工作。Application语言运行时/中间件/基础软件容器libc系统调用文件系统VFSPage缓存BIOSCSISSD/HDD/.TCPSocketUDPTCNICDriverSWAP内存管理DRAM内存分配/回收Page缓存管理T
9、ask调度管理ARM/X86中断/时钟CgroupSched面向基础软件面向基础软件low-level观测观测技术特征统一观测标准:支持对接prometheus、kafka、openTelemetry标准。低底噪:提供eBPF观测技术,通过优化eBPF运行时性能、动态装卸载等技术降低观测底噪。协同观测:提供探针框架,根据场景协同各探针调整观测范围,避免观测碎片化。对象式:定义(且可扩展)系统观测实体以及实体间关系,实时构建出云服务数据流拓扑。网络类问题网络类问题、磁盘磁盘IO问题问题内存类问题内存类问题、调度类问题调度类问题、安全类问题安全类问题、gala-gophergala-gopher在
10、线观测的经验分享在线观测的经验分享首届中国首届中国eBPFeBPF研讨会研讨会061.1.如何避免工具碎片化?如何避免工具碎片化?2.2.如何降低观测底噪?如何降低观测底噪?3.3.如何提升观测精度?如何提升观测精度?4.4.如何观测长连接如何观测长连接TCPTCP?5.5.如何线上如何线上持续持续分析应用性能?分析应用性能?6.6.如何如何基于基于TCP/IPTCP/IP构建服务构建服务实时拓扑实时拓扑?工具化工具化-平台化平台化首届中国首届中国eBPFeBPF研讨会研讨会07问题问题:操作系统需要观测的数据范围很广,为了提升系统的扩展性、伸缩性,不同数据(比如TCP、IO、CPU等)采取不
11、同的探针来实现,各个探针独立实现、演进。但引入一个问题:各个探针各自为政,输入/输出难以协同、统一,各探针观测结果难以有效衔接,起不到数据倍增效应。解决方案:解决方案:建立共享型建立共享型eBPFeBPF MAP MAP,引入白名单机制,将观测对象(目标进程)写入共享型,引入白名单机制,将观测对象(目标进程)写入共享型MAPMAP,协同各种探针的输入、观测行为。,协同各种探针的输入、观测行为。建立建立gala-gophergala-gopher观测平台,支持非侵入方式扩展观测平台,支持非侵入方式扩展探针集,定义观测输出模型,探针集,定义观测输出模型,统一输出结果标准。统一输出结果标准。收益:收
12、益:用户设置用户设置观测范围(白名单进程观测范围(白名单进程名),名),gala-gophergala-gopher协同各探针观测行为,统一输出(协同各探针观测行为,统一输出(OpenTelemetryOpenTelemetry标准化)观测结果,数据之间通过模型形标准化)观测结果,数据之间通过模型形成关联关系,为后期成关联关系,为后期AIAI分析数据提供有效支撑。分析数据提供有效支撑。观测白名单(共享型eBPF)TCP探针ENDPOINT探针进程探针Cgroup探针IO探针gala-gopher观测平台(框架)设置观测范围协同观测行为观测数据后台统一观测结果用户降低观测底噪降低观测底噪首届中国
13、首届中国eBPFeBPF研讨会研讨会08问题问题:在线观测,最重要是降低观测底噪,避免观测行为对应用性能的干扰。尤其在高速数据路径的观测(比如TCP、IO等)会对应用性能产生干扰,比如在redis场景,对应用性能干扰10%。性能优化手段总结:性能优化手段总结:1.1.尽量降低尽量降低MAPMAP查表次数。查表次数。2.2.尽量控制尽量控制helperhelper函数的调用参数(比如访问函数的调用参数(比如访问contextcontext参数内存值)。参数内存值)。3.3.通过频率参数控制数据路径的观测次数。通过频率参数控制数据路径的观测次数。4.4.能用能用ARRAYARRAY型型MAPMAP
14、,别用,别用HASHHASH型型MAPMAP;尽量尽量不用不用per-per-cpucpu型型MAPMAP。5.5.eBPFeBPF程序尽量简短、功能单一,不要把各种功能放在一个程序尽量简短、功能单一,不要把各种功能放在一个eBPFeBPF ProgProg源码文件内。源码文件内。6.6.eBPFeBPF程序按需加载、卸载。程序按需加载、卸载。7.7.尽量减少尽量减少K/K/UprobeUprobe观测点,观测点,KprobeKprobe场景开启场景开启ftraceftrace优化。优化。收益:收益:在在redisredis场景,针对场景,针对redisredis协议的时延观测,对协议的时延观
15、测,对redisredis性能的干扰性能的干扰10%-5%10%-5%;延伸:如何进一步降低观测底噪?延伸:如何进一步降低观测底噪?提升观测精度提升观测精度首届中国首届中国eBPFeBPF研讨会研讨会09问题问题:在线识别操作系统因素对应用性能的影响,首先要在线观测应用性能。eBPF技术可以提供通用的应用性能观测行为(可以覆盖HTTP、PG、Redis、RPC等多种应用协议),但目前的观测技术依然存在观测误差问题【图1所示】:read/write观测点无法有效覆盖由于系统调度、TCP滑窗/拥塞、网络重传/延时引起的应用性能劣化。解决方案【图2所示】:1 1)ReadRead操作读取操作读取so
16、ck.sock.sk_receive_queuesk_receive_queue队列内队列内SKBSKB时间戳时间戳TS1TS1(软中断时机产生)。(软中断时机产生)。2 2)WriteWrite操作延时读取操作延时读取sock.tcp_rtx_queuesock.tcp_rtx_queue队列内删除队列内删除SKBSKB时间戳时间戳TS2TS2(TCP ACKTCP ACK时机产生)。时机产生)。收益:更精准的观测应用时延性能(测量范围包括应用处理、系统处理、网络传输时间)。收益:更精准的观测应用时延性能(测量范围包括应用处理、系统处理、网络传输时间)。图1:现有观测技术方案图2:高保证采集
17、内核协议栈网卡DMAPKG1PKG2PKGnSocket接收队列软中断(TS1)业务请求1应用程序业务请求2业务请求nReadPKG1PKG2PKGnSocket发送队列WriteTCP ACK(TS2)TCP滑窗/拥塞管理内核协议栈网卡DMAPKG1PKG2PKGnSocket接收队列软中断业务请求1应用程序业务请求2业务请求nRead(TS1)PKG1PKG2PKGnSocket发送队列Write(TS2)TCP滑窗/拥塞管理延伸延伸:eBPFeBPF是否可以实现观测应用吞吐量?是否可以实现观测应用吞吐量?观测观测TCPTCP长连接长连接首届中国首届中国eBPFeBPF研讨会研讨会10问题
18、问题:在线观测场景中,经常会遇到观测程序后于应用启动的情况。在观测TCP时,现有基于TCP建链过程eBPF观测方案,无法有效观测长连接TCP(因为其在eBPF程序加载之前已完成建链)。解决方案:解决方案:收益:对业务、观测程序的启动时机没有限制。收益:对业务、观测程序的启动时机没有限制。注意点:注意点:11:如果有多个:如果有多个namespacenamespace,用户态需要切换,用户态需要切换namespacenamespace获取获取TCPTCP。22:单个进程可能存在多个:单个进程可能存在多个TCPTCP,所以此处有循环处理,受,所以此处有循环处理,受eBPFeBPF指令数限制,指令数
19、限制,能够处理的长连接数量有上限(能够处理的长连接数量有上限(4.194.19大约大约1010个,个,5.105.10大约大约100100个)。个)。33:此处必须在进程上下文内执行获取:此处必须在进程上下文内执行获取socksock对象(推荐对象(推荐tcp_sendmsgtcp_sendmsg/tcp_recvmsgtcp_recvmsg )。用户态获取TCP信息(进程号、FD、客户/服务端)TCP信息加载进eBPF MAP启动sock获取eBPF程序进程上下文中根据FD信息获取sock对象启动TCP观测eBPF程序123taskfdfilefdfdfilefileprivate_data
20、Sock对象线上应用性能持续分析线上应用性能持续分析首届中国首届中国eBPFeBPF研讨会研讨会问题问题:在操作系统运维场景经常会遇到僵尸进程,其现象存在包括CPU持续冲高、内存持续高位(或持续增长)等,但是业务层面无法有效判断进程具体行为。传统技术方案传统技术方案perftoolperftool+火焰图方案存在底噪高,不可持续分析的问题。火焰图方案存在底噪高,不可持续分析的问题。解决方案:解决方案:1 1)Kernel 4.9Kernel 4.9开始,开始,perf eventperf event提供提供eBPFeBPF挂载点,通过挂载点,通过ioctlioctl(PERF_EVENT_IO
21、C_SET_BPF(PERF_EVENT_IOC_SET_BPF)挂载挂载eBPFeBPF程序,内核程序,内核perfperf事件触事件触发发eBPFeBPF程序周期性获取程序周期性获取CPUCPU堆栈信息,双通道交替式将堆栈信息,双通道交替式将CPUCPU堆栈信息上送至用户态;堆栈信息上送至用户态;2 2)用户态折叠)用户态折叠CPUCPU堆栈信息,周期性将堆栈信息,周期性将CPUCPU堆栈信息转换成火焰图文件。堆栈信息转换成火焰图文件。收益:用户可以全栈形式查看收益:用户可以全栈形式查看CPUCPU冲高、内存增长的具体原因,可以具体到函数粒度。采样频率冲高、内存增长的具体原因,可以具体到函
22、数粒度。采样频率10ms10ms时,时,CPUCPU占用占用0.1%(0.1%(单核单核)11内核Stack trace MAP获取CPU堆栈信息周期性perf事件通道A通道B折叠+SVG生成基于基于TCP/IPTCP/IP数据流构建实时拓扑数据流构建实时拓扑首届中国首届中国eBPFeBPF研讨会研讨会12问题问题:在线观测在面临分布式应用、云原生场景时,需要实时观测业务数据流,真实反映集群系统运行状态。业务数据流由多种标准协议(TCP、HTTP、gRPC、RPC、Nginx等)承载。如何尽量用单一技术去观测分布式场景的数据流拓扑?如何尽量用单一技术去观测分布式场景的数据流拓扑?解决方案:解决
23、方案:1 1)通过)通过eBPFeBPF技术抓取各类标准协议会话信息,定义会话关系的元信息;技术抓取各类标准协议会话信息,定义会话关系的元信息;2 2)汇总标准协议会话信息以及会话关系元信息,实时构建系统集群拓扑。)汇总标准协议会话信息以及会话关系元信息,实时构建系统集群拓扑。收益收益:用户可以实时观测集群范围内业务流实时拓扑,且不依赖各种中间件技术。:用户可以实时观测集群范围内业务流实时拓扑,且不依赖各种中间件技术。示例:https:/ Client IPIPVirtuaVirtual IPl IPServer Server IPIPServer Server PortPort#A#C#D#D#B#C#F#FClient IP#AClient IP#BVirtual IP#CNode#3Backend#1Server IP#D,Port#DBackend#2Backend#3Server IP#E,Port#EServer IP#F,Port#FTCP#B-#CTCP#C-#F