关于eBPF与可观测性，你想知道的都在这里( 三 ) 嘉宾|王张军赵晨雨出品|CSDN云

eBPF可观测性实践【关于eBPF与可观测性，你想知道的都在这里】可以看出，我们想要通过eBPF实现的两个关键点分别是安全和高效。
安全可以通过Verifier来保证资源不会被运行无限循环的程序阻塞。 JIT编译器可以将eBPF字节码编译成与本地机器一致的机器码，以此保证eBPF运行时的效率与原生机器码保持一致。
云原生环境下的可观测性
当前eBPF落地最主要的场景是云原生。云原生环境下，单体应用已经逐渐容器化、微服务化，这就直接导致了软件内部交互复杂的问题。

文章图片
根据以往的经验及社区的方法，可以总结出eBPF应用在云原生环境下时需要三大组件的支持：
GUI：GUI要保证一些基本功能的实现，如用户认证、权限控制、节点管理、可视化、数据检索等；Scheduler：当eBPF程序数量增多、处于“点—线—面”的过渡时， Scheduler则需负责策略下发、管理编排等功能；Agent：不同环境的复杂度不同，在部署可观测性方案的过程中一定会遇到环境问题。理想状况下，可观测性提供的Agent功能能够实现零侵入、零干扰、零依赖，同时具有良好的兼容性。
我们到底要通过可观测性落地实现什么？
实际上，自底向上是源数据映射到系统资源再映射到应用态能力的过程。
内核是高度抽象的，在内核态只能获取到最基本的源数据，如PID、Cgroup、Namespace等。将源数据映射至用户态也就是在得到源数据后实现资源识别的过程。通过资源识别，可以带来更为直接的价值如性能、安全等。

文章图片
添加eBPF可观测性的挑战
挑战1：原理层面
想要知道为什么内核原理层面是应用eBPF时的挑战，首先要知道我们为什么要在内核态做观测？原因很简单，因为用户态千变万化，内核态相对稳定，是做可观测性的最佳场景。

文章图片
上图是一个网络数据包的构造/解析流程。每一个函数上面都会提取到相应的源数据，将其保存在到eBPF的Maps当中，再将数据传输到用户态。
看似简单的功能实现其实并不简单。每一个小小的功能的背后，都需要对内核原理有充分了解。
挑战2：运行时
在实际落地过程中，经常会遇到以下问题。
易用性eBPF有两个目标，一是让非内核开发人员能够轻易的修改内核，二是提高易用性。但权限方面， eBPF在内核态运行需要Root权限，但并不是所有节点都有Root权限。其次， eBPF本身也不易于调试。兼容性eBPF本身对内核版本要求较高，而业内环境中所使用的Linux内核版本一般较低，不同的内核版本和低版本内核的应用会带来兼容性的问题。管理编排当前eBPF多是单点应用，随着之后“点—线—面”的发展，在节点的管理编排上也会出现困难。
推荐基于eBPF的工具/脚手架/框架/项目
使用现有的基于eBPF的工具：BCCbpftrace；基于eBPF开发复杂功能，甚至是一个产品：libbpfC(CO-RE) ， BBCpython ， libbpf-rs ， cilium/eBPFGo；优秀的基于eBPF的可观测性项目：Pixie、Falco、MetaFlow 。
针对可观测性的观测盲点、数据深度限制等不足， eBPF有效地进行了弥补。而随着云原生的快速发展， eBPF的用武之地才刚刚开始。