Ebpf

01 引言随着 Kuberentes 等云原生技术的飞速发展，带来了研发与运维模式的改革。企业软件架构由单体服务向分布式、微服务演进。随着业务倒退，多语言、多框架、多协定的微服务在企业中越来越多，软件架构复杂度越来越高，如何疾速通过可观测工具疾速定位出问题对研发人员至关重要。为满足全场景、端到端的利用监控需要，利用实时监控服务 ARMS 推出利用监控 eBPF 版，通过 eBPF 技术欠缺整个利用监控体系。利用监控 eBPF 版提供无侵入、语言无关的可观测能力。 具体产品介绍：多语言利用监控最优选，ARMS 利用监控 eBPF 版正式公布 应用 eBPF 来进行可观测性须要进行应用层协定解析，但云上微服务软件架构中的应用层协定往往比较复杂，这也给协定解析带来了不小的挑战。传统的协定解析形式存在 CPU、内存占用高，错误率低等问题，在利用监控 eBPF 版中，咱们提出一种高效的协定解析计划，实现对应用层协定的高效解析。 02 eBPF 技术简介eBPF（扩大的 Berkeley 包过滤器）是一种弱小的技术，容许开发人员在 Linux 内核中平安地运行预编译的程序，而不扭转内核源码或加载内部模块[1]。这一独特的能力使得 eBPF 成为构建古代、灵便且高效的利用监控工具的现实抉择。 $$图 2.1 eBPF 示意图$$ 在可观测性方面，eBPF 劣势尤为突出： 实时性：eBPF 可能实时捕捉和剖析数据，为开发者提供即时的性能反馈。精确性：通过精密的 hook 函数（hook points），eBPF 能够在零碎的具体点进行监控，从而精确地收集所需数据。灵活性：开发者能够编写定制的 eBPF 程序来监控特定事件，使其可能适应各种简单的监控需要。低开销：eBPF 程序间接在内核空间运行，防止了传统监控工具中频繁的用户空间和内核空间之间的上下文切换。安全性：eBPF 程序在执行前必须通过内核的严格查看，确保不会危及系统安全。03 传统的协定解析计划 $$图 3.1 传统协定解析计划架构图$$ 3.1 传统计划的解析流程基于 eBPF 来做数据抓取和协定解析的传统计划次要分为： 数据采集数据传递协定解析其中数据采集次要在内核态，数据传递介于内核态和用户态，协定解析在用户态进行。具体的，数据采集的流程为 eBPF 应用 kprobe 或 tracepoint 形式，从内核中抓取到流量事件即 event，这些事件中有管制层面的事件如从 connect、close 等零碎调用处采集到的事件。也有数据层面的事件，如从 read、write 等零碎调用处采集到的事件。待数据采集到内核事件后，咱们须要将数据从内核态传递至用户态去做进一步的解决。在 eBPF 中，咱们采纳 perf buffer（一种非凡 eBPF Map）来做数据传递。数据寄存到整个 perf buffer 后，在用户态进行协定解析。 ...

前言咱们在《用eBPF/XDP来代替LVS》系列、《一张图感触实在的 TCP 状态转移》系列，以及《如何终结已存在的TCP连贯?》系列文章中，均通过纯 C 语言和 libbpf1 这个库来使用 eBPF。 然而很多的场景中（尤其是云原生场景），咱们出于防止反复造轮子、更快的迭代速度、运行时平安等起因，会抉择 go 语言来进行开发，ebpf-go2 这个库就是以后最好的抉择。 明天，咱们就对 ebpf-go 进行一个初体验，这个体验不是循序渐进的 API 文档，而是通过一个简略的需要，让大家失去一个真切的感触，这个需要就是：统计发向本机的每个 “连贯” 的包数量，并且每新增 5 个 “连贯” 就进行一次数据展现。 体验依赖本次体验须要许多前置条件： Linux kernel 版本 5.7 以上，以反对 bpf_link（我是 6.6.5）LLVM 版本 11 以上 (clang and llvm-strip，查看命令 clang --version )libbpf headers (Debian/Ubuntu 是 libbpf-dev，Fedora 是 libbpf-devel )Linux kernel headers (Debian/Ubuntu 是 linux-headers-amd64，Fedora 是 kernel-devel )Go compiler 版本须要反对 ebpf-go (我装置了 GO 1.21，查看命令 go version)我的项目初始化# 创立我的项目mkdir ebpf-go-exp && cd ebpf-go-expgo mod init ebpf-go-expgo mod tidy# 手动引入依赖go get github.com/cilium/ebpf/cmd/bpf2go如果依赖下载超时的话，能够设置下代理：go env -w GOPROXY=https://goproxy.cn,direct代码C 代码...//go:build ignorestruct event { __u32 count;};const struct event *unused __attribute__((unused));SEC("xdp") int count_packets(struct xdp_md *ctx) { __u32 ip; __u16 sport; __u16 dport; if (!parse_ip_src_addr(ctx, &ip, &sport, &dport)){ goto done; } __u16 r_sport = bpf_ntohs(sport); bpf_printk("Process a packet of tuple from %u|%pI4n:%u|%u",ip,&ip,sport,r_sport); if(8080 != bpf_ntohs(dport)){ goto done; } struct tuple key; __builtin_memset(&key,0,sizeof(key)); key.addr = ip; key.port = sport; __u32 *pkt_count = bpf_map_lookup_elem(&pkt_count_map, &key); if (!pkt_count) { __u32 init_pkt_count = 1; bpf_map_update_elem(&pkt_count_map, &key, &init_pkt_count, BPF_NOEXIST); __u32 key = 0; __u64 *count = bpf_map_lookup_elem(&tuple_num, &key); if (count) { __sync_fetch_and_add(count, 1); if(*count % 5 == 0){ struct event *e; e = bpf_ringbuf_reserve(&events, sizeof(struct event), 0); if (e){ e->count = *count; bpf_ringbuf_submit(e, 0); } } } } else { __sync_fetch_and_add(pkt_count, 1); }done: return XDP_PASS; }...Go 代码...//go:generate go run github.com/cilium/ebpf/cmd/bpf2go -type event counter counter.c -- -I headersfunc main() { // Load the compiled eBPF ELF and load it into the kernel. var objs counterObjects if err := loadCounterObjects(&objs, nil); err != nil { log.Fatal("Loading eBPF objects:", err) } defer objs.Close() ifname := "lo" iface, err := net.InterfaceByName(ifname) if err != nil { log.Fatalf("Getting interface %s: %s", ifname, err) } // Attach count_packets to the network interface. link, err := link.AttachXDP(link.XDPOptions{ Program: objs.CountPackets, Interface: iface.Index, }) if err != nil { log.Fatal("Attaching XDP:", err) } defer link.Close() rd, err := ringbuf.NewReader(objs.Events) if err != nil { log.Fatalf("opening ringbuf reader: %s", err) } defer rd.Close() stopper := make(chan os.Signal, 1) signal.Notify(stopper, os.Interrupt, syscall.SIGTERM) go func() { <-stopper if err := rd.Close(); err != nil { log.Fatalf("closing ringbuf reader: %s", err) } }() log.Println("Waiting for events..") // counterEvent is generated by bpf2go. var event counterEvent for { record, err := rd.Read() if err != nil { if errors.Is(err, ringbuf.ErrClosed) { log.Println("Received signal, exiting..") return } log.Printf("reading from reader: %s", err) continue } if err := binary.Read(bytes.NewBuffer(record.RawSample), binary.LittleEndian, &event); err != nil { log.Printf("parsing ringbuf event: %s", err) continue } log.Printf("tuple num: %d", event.Count) var ( key counterTuple val uint32 ) iter := objs.PktCountMap.Iterate() for iter.Next(&key, &val) { sourceIP := key.Addr sourcePort := key.Port packetCount := val log.Printf("%d/%s:%d => %d\n", sourceIP, int2ip(sourceIP), sourcePort, packetCount) } }}...残缺代码在：https://github.com/MageekChiu/epbf-go-exp ...

eBPF 的倒退热火朝天，在可观测性畛域大放异彩，Grafana 近期也公布了一款 eBPF 采集器，能够采集服务的 RED 指标，本文做一个尝鲜介绍，让读者有个大略理解。eBPF 根底介绍能够参考我之前的文章《eBPF Hello world》。实践上，eBPF 能够拿到服务收到的申请信息，比方QPS、提早、成功率等，这些数据对于利用级监控至关重要，Grafana Beyla 就是为此而生的。 要测试应用 Beyla 采集服务的 RED（Rate-Errors-Duration） 指标，那首先得有个服务，这里我用的是 answer（ https://answer.flashcat.cloud ） 论坛，你也能够本人搞一个简略的 http 服务，比方： package mainimport ( "net/http" "strconv" "time")func handleRequest(rw http.ResponseWriter, req *http.Request) { status := 200 for k, v := range req.URL.Query() { if len(v) == 0 { continue } switch k { case "status": if s, err := strconv.Atoi(v[0]); err == nil { status = s } case "delay": if d, err := time.ParseDuration(v[0]); err == nil { time.Sleep(d) } } } rw.WriteHeader(status)}func main() { http.ListenAndServe(":8080", http.HandlerFunc(handleRequest))}下面这个代码，保留成 server.go，而后用 go run server.go 即可运行，当然，前提是你机器上有 go 开发环境。这个小服务，能够接管两个参数，一个是 status，用来指定返回的 http 状态码，另一个是 delay，用来指定提早多久返回，比方： ...

eBPF技术是Linux内核3.15版本中引入的全新设计，自从2014年公布以来，始终都备受瞩目。在过来几年中，基于eBPF技术的实际和工程落地层出不穷，呈现了爆发式的增长。2015年微软、Google、Facebook、Netflix 和 Isovalent 也独特发表在 Linux 基金会下成立了一个新的 eBPF 基金会，以帮忙反对该技术的倒退，并促成正在倒退的许多基于 eBPF 的开源我的项目之间的单干。eBPF技术未然成为基础设施世界中最有影响力的技术之一。 01 什么是eBPF？咱们晓得操作系统分为用户空间和内核空间，内核是操作系统的外围，它独立于惯例的应用程序，能够拜访受爱护的内存空间，也有拜访底层硬件设施的所有权限。为了保障内核的平安，当初的操作系统个别都强制用户过程不能间接操作内核。而应用程序通常是在用户空间中运行，每当这些应用程序想要以任何形式与硬件交互时，都必须向内核发出请求来取得拜访权限，同时，内核还负责调度各个应用程序，以确保多个过程同时运行。eBPF的弱小与神奇之处，就是在内核和用户空间之间架起了“桥梁”，扭转了操作系统和基础设施服务的设计形式，将原先的BPF倒退成一个指令集更简单、利用范畴更广的“内核虚拟机”，以提供更多的可编程性、可扩展性和敏捷性。eBPF程序能在操作系统的内核中运行，并在不更改内核源代码的状况下对内核进行检测。为了防止注入的代码导致内核解体，eBPF会对注入的代码进行严格查看，回绝不合格的代码的注入，保障eBPF程序运行的稳定性和安全性。 02可观测性体系构建在云原生可观测体系构建中，业界通常将指标（Metrics）、链路（Tracing）和日志（Logging）称为可观测性的“三大支柱”。而在具体实际中，这三个监测维度与其说是“支柱”，更像是三条相互交织、互相关联的“线”，在各自偏重本身畛域能力建设的根底上又要实现互联——以“链路”能力串起所有利用零碎的依赖拓扑关系，补充“指标”能力实时掌控链路上各个节点的健康状况，兼以“日志”能力实现深度的业务剖析与谬误定位。 针对可观测性体系所须要的这三个方面能力的构建，行业内别离都有比拟成熟的开源我的项目能够间接应用，比方云原生运行指标数据的采集与展现根本采纳Prometheus + Grafana来构建，链路追踪有Skywalking、Zipkin等APM工具，也有基于交换机镜像通过网络旁路进行采集剖析的NPM类产品，而日志体系应用的比拟多的有ELK。 针对这些产品的组合，咱们也能够比拟疾速地搭建一个可观测性零碎，然而从业界实际来看，这样组装的零碎普遍存在几类痛点：· 不足全局性的零碎和网络拓扑关系。不论是采纳APM还是NPM来绘制链路，受限于采集形式，无奈残缺笼罩所有利用零碎、主机、负载均衡器等维度的网络调用链路拓扑，无奈构建全面的链路拓扑。· 数据采集形式不具备普适性。Skywalking与Zipkin等APM类产品须要采纳SDK集成或Agent等形式，随着利用部署运行，采集特定埋点的指标数据，这两类形式都都要依赖利用方进行适配革新，埋点的数据采集又局限于特定语言和技术栈。而在云原生环境中，多语言利用、不同通信协议共存的状况下，存在适配工作量极大、利用感知显著的问题；而NPM因为是通过交换机镜像采集网络流量，一方面随着云原生利用在虚构网络上运行，流量不通过物理交换机，单从物理交换机采集流量并不能无效反对上云业务的监测剖析须要，另一方面，未将抓取的网络信息与云资源信息联合，无奈出现利用容器间、网络要害组件的网络拓扑。 03基于eBPF技术的可观测实际摸索如上文所诉，eBPF技术在用户空间和内核空间之间架起了“桥梁”，通过将eBPF程序加载到trace points、内核、及用户空间利用，使得咱们能够从内核空间获取应用程序的运行时行为（runtime behavior）和零碎事件（system event）。利用端与零碎端的这种观测能力联合，能在排查零碎性能问题时提供更弱小的能力和独特的信息。 同时，相比于操作系统提供的动态计数器（counters、gauges），eBPF能在内核中收集和聚合自定义metric，并能从不同数据源来生成可观测数据，这既扩大了可观测性的深度，也显著缩小了整体零碎开销，因为通过eBPF可抉择只收集必要的数据，这也极大地提高了在大规模生产环境中构建可观测性能力的可行性。相比于传统监测数据采集与剖析技术，基于eBPF技术的可观测零碎有着显著的劣势：· 零侵入式，eBPF采集端程序与利用零碎运行在不同的过程中，不会对利用零碎运行带来影响；· 语言无关性，无论待监测的利用零碎采纳的是什么开发语言或技术框架，都可实现笼罩，构建全面的链路拓扑和可观测图谱；· 多环境适配，不论利用零碎运行的根底环境是采纳Kubernetes或Open Shift等云原生平台、虚拟机集群、物理机、还是科创环境，都可实现适配，采纳一套采集形式来实现多环境笼罩。

随着 eBPF 的倒退，咱们曾经能够将 eBPF/XDP 程序间接部署在一般服务器上来实现负载平衡，从而去掉用于专门部署 LVS 的机器。本系列文章就是基于这个出发点，以演进的模式，剖析和探讨一些实现思路。 系列回顾版本 0.1 分享了如何应用 xdp/ebpf 替换 lvs 来实现 slb，仍然采纳的是 slb 独立机器部署模式，并且采纳 bpftool 和硬编码配置的模式来进行加载 xdp 程序，代码在 https://github.com/MageekChiu/xdp4slb/tree/dev-0.1。 版本 0.2 在 0.1 根底上，批改为基于 bpf skeleton 的程序化加载模式，要想简略地体验下这种工作流而不改变版本 0.1 中整体部署模式的，能够去看看 https://github.com/MageekChiu/xdp4slb/tree/dev-0.2。 版本 0.3 在 0.2 根底上，反对以配置文件和命令行参数的模式动静加载 slb 配置。 版本 0.4 反对 slb 和 application 混布的模式，去除了专用的 slb 机器。混布模式使得一般机器也能间接做负载平衡，同时不影响利用（off load 模式下能够体现），有老本效益；另外，在路由到本地的场景下，缩小了路由跳数，整体性能更好。 本文属于0.5，反对应用内核能力进行 mac 寻址、健康检查、conntrack回收、向用户态透出统计数据等个性。接下来别离进行介绍，如果你心愿本人试验一下，根本的环境搭建能够参考前文。 个性介绍应用内核进行 mac 寻址后面的版本中，咱们间接在配置文件中配置了 rs 的 mac 地址，这只是做 demo，事实中这是不太可行的，因为 ip 和 mac 的关系并不是变化无穷的。因而，咱们在每包路由的时候，须要动静填充 mac 地址。当然咱们不须要本人去实现 arp 性能，只须要应用 bpf_fib_lookup 便能够借助内核能力查问 mac 地址，这也是不采纳 kernel bypass 的益处之一，咱们在晋升了性能的同时，还能享受内核带来的红利。次要代码如下，其中 ipv4_src 是本机 地址，ipv4_dst 是被选中的 rs ip： ...

随着 eBPF 的倒退，咱们曾经能够将 eBPF/XDP 程序间接部署在一般服务器上来实现负载平衡，从而节俭掉用于专门部署 LVS 的机器。 前文 分享了如何应用 xdp/ebpf 替换 lvs 来实现 slb，采纳的是 slb 独立机器部署模式，并且采纳 bpftool 和硬编码配置的模式来进行加载 xdp 程序，这是 版本 0.1。 版本 0.2 在 0.1 根底上，批改为基于 bpf skeleton 的程序化加载模式，要想简略地体验下这种工作流而不改变 版本0.1 中整体部署模式的，能够去看看 https://github.com/MageekChiu/xdp4slb/tree/dev-0.2。 版本 0.3 在 0.2 根底上，反对以配置文件和命令行参数的模式动静加载 slb 配置 本文属于 版本 0.4，反对 slb 和 application 混布的模式，去除了专用的 slb 机器。混布模式使得一般机器也能间接做负载平衡，同时不影响利用（off load 模式下能够体现），有老本效益；另外，在路由到本地的场景下，缩小了路由跳数，整体性能更好。 创立网络环境# 不同发行版命令不一样systemctl start dockerdocker network create south --subnet 172.19.0.0/16 --gateway 172.19.0.1# checkdocker network inspect south# orip link# 先用 ifconfig 取得刚创立的 network 应的 bridge# 后续则能够在宿主机上抓取这个 network 的所有 IP 包tcpdump -i br-3512959a6150 ip# 也能够取得某个容器的 veth ,抓取这个容器进出的所有包tcpdump -i vethf01d241 ip原理解析SLB 集群路由slb 为了高可用，个别都会集群化部署，那么申请怎么路由到每一台 slb 上呢？个别由（动静）路由协定（ospf bgp）实现 ecmp，使得各个 slb 实例从 router/switch 那里平均地取得流量。因为配置动静路由协定十分繁冗，不在本文思考范畴之内，这里采纳一个简略的脚本来模仿 ecmp。 ...

DeepFlow 基于 eBPF 实现了零插桩（Zero Code）的云原生利用可观测性，可能在不改代码、不改启动参数、不重启过程的前提下实现分布式追踪。这是一种全新的技术手段，因而不少用户在选型和落地 DeepFlow 的过程中会对它的性能开销存在疑难。到底 Agent 的运行会对业务造成什么样的影响？而 Agent 本身的资源开销又如何？这些问题咱们在 SIGCOMM 2023 论文《Network-Centric Distributed Tracing with DeepFlow: Troubleshooting Your Microservices in Zero Code》中都有体系化的答复，论文将于九月份正式公开。在此之前，为了尽快帮忙大家扫清落地 eBPF 可观测性的最初阻碍，最近咱们也将 DeepFlow Agent 的自动化测试后果放到了线上 Demo 页面中，本文将联合 Agent Daily Build 的测试数据，系统性的论述咱们的测试方法和测试后果，揭示 Agent 的业务影响和资源开销，帮忙大家扫清落地 eBPF 可观测性的最初阻碍。 通过剖析 Agent 的解决流程，咱们设计了六个场景进行全方位的评测。 测试结果表明 Agent 对典型高负载生产业务的 TPS 无任何影响、CPU 增长仅 0.46%、均匀单个调用的 RT 增长小于 1ms。Agent 对 HTTP 流量的解决性能不低于 Nginx，通过 eBPF uprobe 采集 Golang 协程信息的性能为 Pixie 计划的 2.5 倍。Agent 在 1 核 1GB 内存限度下可采集 90K RPS HTTP 流量，或 122K CPS 并发的 TCP 流量，或 20+Gbps（未到极限） TCP Flood 流量，或 1.28Mpps UDP Flood 流量。具体的测试方法和测试数据见注释，具体的总结见文末章节。 ...

他山之石理解和把握纯 c 语言的 ebpf 编译和应用，有助于咱们加深对于 eBPF 技术原理的进一步把握，也有助于开发合乎本人业务需要的高性能的 ebpf 程序。目前常见和支流的纯 c 语言的 ebpf 编译应用办法，次要是两种。一种是内核源码中原生提供的编译形式。另外一种是 libbpf-bootstrap 我的项目中提供的 skeleton 编译形式。libbpf-bootstrap 形式和社区 5.x 以上内核联合的比拟好，当前再做介绍，明天咱们抉择基于 4.18 内核的基于内核源码的原生编译形式做介绍。 在国内学习 ebpf 技术，就不得不提到《Linux 内核观测技术 BPF》书籍译者狄卫华老师。狄老师还有一个网站《深入浅出 eBPF》。在网站里，他专门用一篇文章介绍了基于内核源码形式编译 ebpf 的形式，文章内容叫《【BPF 入门系列-3】BPF 环境搭建》 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1200365?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

01 启示录新约圣经启示录认为：恶魔其实自身是天使，但炽天使长路西法背离了地狱，翅膀变成了彩色，坠落天堂，腐化成为恶魔。这些恶魔主宰著光明权势，妨碍人类与上帝沟通，无所不用其极。所以能够说天使和恶魔原本是一体的，只是命运不同。 随着 eBPF 技术在各种行业畛域上的应用和遍及，人们在享受着技术改革红利的同时，也蒙受着无孔不入的歹意攻打，就像任何事物都有两面性一样。没有任何一项技术只有居高临下的劣势，而没有弊病，只有更加清晰的刨析分明 eBPF 的内核，能力推动它一直的提高，趋利避害，尽可能施展正向的作用。 那么，eBPF 是天使，亦或恶魔？ 越来越严厉的 Linux 安全形势依据平安剖析机构 ESG 云原生平安钻研，88% 的网络安全专业人士示意，在过来 12 个月中，他们的云原生应用程序和基础设施蒙受过攻打 。然而，许多旨在爱护 Linux 的云平安解决方案可能很麻烦且具备破坏性，因为它们是从 Mac 或 Windows 操作系统上移植而来，这些计划有时会影响到 Linux 零碎的解决能力，甚至进行更改。 在 Linux 畛域，很多平安公司都公布了自研的 MDR、XDR、EDR 产品，大多数计划是基于轻量级代理在静默收集遥测数据，同时最大限度地缩小任何可能的性能影响，并将托管检测和响应扩大到零碎的本地和云上，通常构建有基于规定的主动响应和剖析性能，比方 SanerNow、Automox、Cybereason、Syxsense Secure、Sangfor Endpoint Secure 等等，大抵有以下特点： 从端点监督和收集可能暗示威逼的流动数据评估收集的数据以确定威逼模式主动响应已辨认的威逼以打消或遏制它们，并告诉平安人员应用取证和剖析工具钻研已辨认的威逼并寻找可疑流动目前在 Linux 环境下，对于 EDR、XDR 产品也提出更加严格的要求： Linux 威逼和攻打媒介与 Windows/Mac OS 对应物不同，须要独自构建策略。Linux 通常是生产零碎的根底，不能因为产品的中断或烦扰会对业务产生负面影响。构建轻型 Linux EDR 传感器专为 Linux 构建和优化，对系统的影响降到最小。 基于 Linux 零碎的云原生基础架构设施 云原生应用程序的组合是 CI/CD 继续集成和交付的 API、容器、VM 和无服务器性能的组合。爱护这些应用程序、底层基础设施和协调其部署的自动化平台，须要从新扫视威逼模型、取得组织一致性并利用有目标的管制。此外，随着安全性和 DevOps 一直交融，云安全控制正在失去整合。将孤立的办法倒退为对立的策略，以爱护云原生应用程序和平台是目前很多平安厂商发力的指标，也是甲方实实在在的需要。与此同时，更多的平安厂商正在尝试将云平安态势治理 (CSPM)、云工作负载爱护 (CWP)、容器平安等计划，整合到集成的云平安套件中，从而增大本身平安产品在市场上的竞争力和话语权，也防止平安产品的碎片化。 云原生的基础设施蕴含 CPU 硬件、指令集，操作系统等，加强操作系统的高性能和安全性，也是目前 eBPF 技术正在深刻的畛域，所以 eBPF 本身的平安能力，也是测验该项技术是否有可继续倒退的重要指标。 ...

本刊物旨在为中文用户提供及时、深刻、有态度的 ebpf 资讯。 如果你吃了鸡蛋感觉好吃，还想意识下蛋的母鸡，欢送关注：笔者的 twitter：https://twitter.com/spacewand... bpftrace 公布 0.17.0 版本https://github.com/iovisor/bp... 时隔数月，bpftrace 公布了新版本 0.17.0。这个版本，容许间接比拟整数数组，还新增了对以下几个架构的反对： 龙芯：https://github.com/iovisor/bp...ARM32：https://github.com/iovisor/bp...此外，一个较大的改变是反对内核模块的 BTF 文件：https://github.com/iovisor/bp... bpftrace 以前就已反对了解决内核的 BTF 文件，新版本把这一性能拓展到内核模块上，算是百尺竿头更进一步。 BTF 是 eBPF 世界内的 debuginfo。通过 BTF，咱们能够在二进制和程序代码间架起桥梁。举个例子，bpftool 可能 dump 一个 BPF map 中的数据。如果没有 BTF 来正文 BPF map 存储的数据结构，dump 的后果只能是一堆二进制。有了 BTF，能力看得懂在 map 外面存储的信息。 作为一个 tracing 畛域的工具，BTF 对于 bpftrace 十分重要。如果没有 BTF，那么 bpftrace 脚本中有时须要显式定义一个内核构造体，比方 https://github.com/iovisor/bp... 为了让这段代码可能编译： $nd = (struct nameidata *)arg0; printf("%-8d %-6d %-16s R %s\n", elapsed / 1e6, pid, comm, str($nd->last.name));须要在文件结尾定义相干的构造体： #include <linux/fs.h>#include <linux/sched.h>// from fs/namei.c:struct nameidata { struct path path; struct qstr last; // [...]};有了 BTF，就能很天然地应用内核中的构造体定义。 ...

引生产环境的问题，按呈现频率，大体能够分为两类： 高频问题低频问题 周期性低频问题无周期随机产生问题 单例产生多例产生个别，遇到 无周期随机产生问题 且 单例产生 的状况，是最难定位问题本源的。 前不久，我就遇到利用对外发动连贯 无周期随机产生 且 单例产生 的状况 。你不可能在大流量的状况下，做 tcpdump 去剖析连贯状况的。而能透视内核状态的 eBPF/BPF 可能是个更适合的抉择。 eBPF 能够在以下事件产生时，抓取到 连贯信息： 利用发动 connect()，连贯进入 SYN_SENT 状态时在发送 SYN 肯定工夫后，无收到响应而重传 SYN 时connect timeout 后，利用 close() socket。连贯从 SYN_SENT 状态变为CLOSE状态时这里说的连贯信息，包含： 连贯 4 元组： source_IP: local_port <-> destination_IP:dest_port事发时的连贯状态而这些 事件 + 连贯信息 能够为进一步研判问题的方向，提供一个主观的事实证据。 利用场景例子之前，我了一篇：特定条件下 Istio 产生 half-close 连贯透露与出站连贯失败 。其中模仿了一个场景： 应用程序出站outbound连贯超时因为应用程序抉择了一个与-15001outboundlistener-上的现有套接字抵触的长期端口 App invoke syscall connect(sockfd, peer_addr) , kernel allocation a ephemeral port(44410 in this case) , bind the new socket to that ephemeral port and sent SYN packet to peer.SYN packet reach conntrack and it create a track entry in conntrack table: ...

本刊物旨在为中文用户提供及时、深刻、有态度的 ebpf 资讯。 如果你吃了鸡蛋感觉好吃，还想意识下蛋的母鸡，欢送关注：笔者的 twitter：https://twitter.com/spacewand...笔者的 GitHub：https://github.com/spacewander Merbridge 成为 CNCF sandbox 我的项目Istio、Linkerd、Kuma 这三个我的项目除了都是 service mesh 之外，还有什么共同点？它们都能够通过 Merbridge 减速！ Merbridge 是一个旨在通过 ebpf 代替 iptables，给 service mesh 减速的我的项目。作为成立刚满一周年的新我的项目，Merbridge 曾经利用到 kuma 的官网版本当中。最近 Merbridge 又达到了另外一个里程碑 —— Merbridge 正式成为 CNCF sandbox 我的项目。 从 Merbridge 提交给 CNCF 的维护者列表来看，目前该我的项目背地是由 DaoCloud 推动的，半数维护者来自于该公司。不过因为 Merbridge 的地位偏差于底层组件，咱们还是能够置信该项目标中立性。想必该项目标创建之初是为了减速 istio，起初也被 kuma 等非 istio 的 service mesh 所驳回。 在应用 Merbridge 进行一键减速之前，一个典型的 service mesh 的网络通信是这样的： Merbridge 应用了 ebpf 的 SOCKMAP 性能，在 socket 层面上实现包的转发，绕过其余弯弯绕绕的路线。 在采纳 Merbridge 之后，sidecar 和 app 之间的门路可能显著缩短： ...

编者按：eBPF(extended Berkeley Packet Filter) 是一种能够在 Linux 内核中运行用户编写的程序，而不须要批改内核代码或加载内核模块的技术。简略说，eBPF 让 Linux 内核变得可编程化了。本文整顿自龙蜥大讲堂第 57 期，浪潮信息 SE 王传国从原理上剖析了 eBPF 的加载工作过程，解释了它如何保证系统运行稳固以及它能减速网络的起因。 01 eBPF 加载过程咱们晓得，个别 eBPF 的加载过程，首先是写 C 代码，而后用 llvm lang 编译成 ELF 文件，接着用 libelf 对 ELF 文件进行解析，解析之后依照 libbpf 所须要的格局进行数据的整顿、组织，再通过 BPF 的零碎调用，能够将这些数据都加载到内核外面，包含程序翻译进去的 eBPF 指令集。 在内核外面有校验器负责对程序进行校验，有 JIT 对程序进行翻译解析。 1.1 重定位BPF 基础设施提供了一组无限的“稳固接口”， 应用 convert_ctx_access 对各种 CTX 进行转换，在内核版本升级时保障稳固。 CO-RE 核心思想就是采纳(BTF)非硬编码的模式对成员在构造中的偏移地位进行形容，解决不同版本之间的差别。 须要重定位的元素：Map、函数调用、Helper函数调用、字段、Extern 内核符号和kconfig。 1.2 安全性查看：数据、指令、循环数学计算除数不能为 0，指令调用范畴[0, prog->len)深度优先遍历排除环。 1.3 eBPF 指令集 1.4 指针安全性查看 确定指针类型、范畴纠正，辨认不了的指针类型不容许援用。 范畴查看，不同的指针类型有不同的查看办法和范畴。 02 eBPF 减速容器网络次要波及的 eBPF 程序类型：XDP、tc、sock_ops。 ...

本周「龙蜥大讲堂」预报来啦！龙蜥社区邀请了浪潮信息 SE、eBPF 技术摸索 SIG Contributor 王传国，Intel Arch SIG Contributor 马腾做本周主题分享，快来扫码入群，预约前排小板凳观看直播！ 直播主题及内容介绍一、直播主题：eBPF 加载过程解析与 eBPF 减速容器网络的原理剖析直播工夫：2022 年 12 月 28 日（周三）15：00-16：00 直播内容：eBPF(extended Berkeley Packet Filter) 是一种能够在 Linux 内核中运行用户编写的程序，而不须要批改内核代码或加载内核模块的技术。简略说，eBPF 让 Linux 内核变得可编程化了。本次分享从原理上剖析了它的加载工作过程，解释了它如何保证系统运行稳固以及它能减速网络的起因。 听众受害：深刻了解 eBPF 的加载过程，以及减速容器网络的基本原理。 适宜人群：eBPF 爱好者、容器网络工程师等。 讲师介绍： 王传国，浪潮信息 SE 、eBPF 技术摸索 SIG Contributor， 负责 KOS 操作系统体系的需要、设计工作，次要波及的畛域有 OS 资源隔离、网络和 eBPF 等。 二、直播主题：Intel Arch SIG 月会直播工夫：2022 年 12 月 29 日（周四）15：00-16：00 直播内容：CXL 作为下一代高带宽低提早的互联协定，行将被广泛应用在数据中心之中。本次流动次要介绍了 CXL 的根底概念和标准，以后 Linux 内核和硬件厂商 Intel 对于 CXL 的反对，以及龙蜥社区对于 CXL 的布局。 ...

eBPF 是一个可能在内核运行沙箱程序的技术，提供了一种在内核事件和用户程序事件产生时平安注入代码的机制，使得非内核开发人员也能够对内核进行管制。随着内核的倒退，eBPF 逐渐从最后的数据包过滤扩大到了网络、内核、平安、跟踪等，而且它的性能个性还在疾速倒退中，晚期的 BPF 被称为经典 BPF，简称 cBPF，正是这种性能扩大，使得当初的 BPF 被称为扩大 BPF，简称 eBPF。 现在 eBPF 被广泛应用在云原生、可观测、性能调优、平安、硬件加速等畛域，并且其利用场景还在疾速扩大，各种场景基于 eBPF 技术的翻新 idea 出现井喷景象，eBPF 的时代曾经降临。 eBPF 技术现状尽管 eBPF 技术利用出现井喷景象，然而开发、公布、装置等相干的根底技术呈现碎片化景象，导致技术成绩无奈疾速平移至行业客户生产环境；类似 eBPF 技术利用在反复实际。这些问题妨碍 eBPF 技术的遍及与推广。 如下图所示，总结目前 eBPF 的开发、公布形式根本能够划分成 2 种技术路线： 开发态、运行态拆散（典型代表 libbpf） 长处：ELF 文件模式（或者链接进应用程序）公布，运行时轻量化，适宜生产环境大规模利用。 毛病：利用技术门槛高，且不具备可移植性（比方高内核版本的 eBPF 程序无奈移植至低内核版本中）。 开发态、运行态交融（典型代表 BCC） 长处：源码模式公布人造具备可移植性；封装形象运行时，提供高级语言 API，升高开发难度。 毛病：运行时重型化，对生产环境要求较高（须要装置开发态一系列工具）；高度形象后，升高应用灵便度，不适宜大型利用开发。 这两种技术路线都存在弊病，随着 eBPF 技术的倒退，呈现 BumbleBee 、eunomia-bpf 等我的项目致力于综合这两类技术路线的长处，但仍旧不足对 eBPF 根底技术的整体规划。 eBPF 倒退瞻望eBPF summit 2022 《The future of eBPF in the Linux Kernel》瞻望了 eBPF 的倒退方向，具体的演进方向包含几个方面： 更齐备的编程能力：以后 eBPF 的编程能力存在一些局限性（比方不反对变量边界的循环，指令数量受限等），演进指标提供图灵齐备的编程能力。 ...

“ Trace-Profiling通过eBPF技术将程序代码执行过程转换成操作系统资源耗费过程，并交融tracing、logging、metrics等多种可观测性技术，造成一个相似光学摄像头的程序摄像头。次要能够帮忙开发者理解程序执行过程当中每一毫秒在干什么。”Q：Trace Profiling能够解决什么场景下的问题？ A：请参考：Kindling程序摄像头——Trace-Profiling性能正式公布 Q：Trace Profiling捕获的是一次申请下，所有工作线程的执行实况，这些线程是指申请执行这段时间内，执行了事件的线程吗？ A：捕获的是所有工作线程的执行状况。从eBPF角度是分不进去哪些线程是与申请无关，所以咱们有个要害线程概念，要害线程概念就是执行此次申请的线程，之所以展现所有线程的执行状况目标是为了可能发现要害线程在执行过程中被挂起的起因，很可能是因为其它线程如JVM虚拟机线程执行GC操作导致的。咱们以后没有方法齐全辨认所有的场景，到底哪些线程的执行行为会影响要害线程的执行过程。为了可能实在还原程序的执行状况，所以咱们将所有工作线程的执行状况都记录展现进去，之后靠人为比照剖析要害线程被挂起时，其它线程在做什么，从而判断是哪些线程导致要害线程被挂起的。 Q： 这么多工作线程，什么是本次申请的要害线程？断定根据是什么？ A：要害线程是在此过程当中，解决此次申请的线程。断定根据是通过与tracing零碎做集成，比方与skywalking集成，能够清晰无误的断定解决此次申请的线程。 Q：Kindling agent是怎么捕捉到线程的执行事件的？又是怎么划分某个事件具体是在net？lock？futex？cpu on？file？epoll？other？ A：通过对屡次switch做判断，从而判断出oncpu的工夫。通过对要害零碎调用进行辨别判断offcpu类型，比方write read归属到IO，再依据fd的属性是网络还是文件从而判断是网络IO还是文件IO。epoll就是网络系统调用。futex是一个比拟难以解释的零碎调用，因为程序在太多场合应用了futex，目前曾经辨认次要场景有如下： 线程闲暇线程执行锁操作线程被挂起java程序的sleep操作实现咱们是通过如下规定判断futex到底是何意义的：在要害线程的trace start工夫之前的futex是闲暇状态从JVM中获取java虚拟机层面锁相干信息，通过此信息解释在要害线程trace start 与 trace end的futex工夫在排除以上两种状况之后，在要害线程trace start与trace end之间的futex，绝大多数状况咱们认为就是被其余线程烦扰导致的挂起时间。在执行一次trace当中的业务代码当中，咱们认为根本不会有开发写sleep操作，如果有写，的确在当前情况下，是比拟难以辨别sleep的futex与线程烦扰的挂起操作。 Q：一次申请的IO/Trace start、End别离从哪一刻开始算？ A：对于一次申请过程而言，理论执行流程是操作系统先实现数据筹备，也就是IO start，等有可用执行线程之后，线程会将IO http数据转成序列化对象，而后调用springcloud的control或者dubbo的服务接口开始一次trace，所以IO start是早于trace start的，然而在显示的时候，两者工夫可能十分靠近，所以根本重合了，然而如果呈现线程不够的状况下，能够显著看出io start早于trace start。当申请trace在业务代码层被解决完结之后，也就是tracing零碎将trace收回来的时候trace end会被记录，之后当申请对应的响应通过零碎调用写回的时候点，咱们记录为io end。 Q：Kindling agent装置为什么要基于k8s的环境？如果小公司没有装k8s环境，不装docker能够用Trace Profiling吗？ A：实践上非k8s环境是能够应用，然而kindling指标用户是云原生的用户，非k8s的用户不是咱们的指标用户。次要有以下几点思考。 在非云原生的环境中操作系统版本对eBPF的反对可能性较低在非云原生的环境中，遇到比较复杂的问题可能性较小，简略问题能够应用tracing、logging、metrics工具解决。Q：应用Trace Profiling前，为什么要装置Skywalking探针？它在外面采集了哪些数据？和Kindling agent是怎么分工合作的？ A：之所以叫Trace profiling就是要剖析一次trace中的span理论执行状况，所以肯定须要和trace零碎对接能力失去trace相干信息。因为咱们目前只对接了国内罕用的skywalking，所以要求用户先装置skwwalking探针，skywalking探针采集的数据就是依照其原有工作失常工作，咱们没有革新skywalking探针。对接原理就是咱们须要trace探针或者sdk告诉咱们以后执行的申请的线程是哪一个线程，以及trace开始工夫和完结工夫。 Q： 如何装置Kindling，并开启Trace Profiling性能？ A：参考装置教程 我的项目开源地址 官网地址 Q： 如何操作应用Trace Profiling？ A：参考操作教程： Q：我还有别的疑难和想法，或者应用上遇到问题，该怎么分割你们？ A：能够增加小编微信、关注咱们的公众号哦～

近日，在 2022 云栖大会龙蜥峰会 eBPF & Linux 稳定性专场上，来自 eBPF 技术摸索 SIG Maintainer 、浙江大学的郑昱笙分享了《eunomia-bpf：eBPF 轻量级开发框架》技术演讲，以下为本次演讲内容： 大家好！我是来自浙江大学的郑昱笙，明天为大家介绍下 eunomia-bpf 我的项目作为一个为了简化 eBPF 程序的开发、散发、运行而设计的轻量级 eBPF 开发框架的背景和指标；再通过一些简略的实例，展现一下 eunomia-bpf 是如何从云端一行命令下载运行 eBPF 程序、只编写内核态代码即可运行和导出事件，以及和 WebAssembly 的联合等性能，最初简要论述一下 eunomia-bpf 的原理和设计实现的思路，探讨一下接下来的倒退方向。 eunomia-bpf 我的项目龙蜥社区开源仓库：https://gitee.com/anolis/eunomia 概要eunomia-bpf 起源于 2022 年全国大学生操作系统大赛，心愿将 eBPF 程序作为服务运行，把 eBPF 程序打包为一个 JSON 对象，通过 HTTP 申请即可动静插拔运行任意一个可重定位的 eBPF 程序，并且能够适应不同内核版本和架构。较量完结之后，在高校的几位老师和社区中的一些搭档的帮忙和领导下（在这里重点感激西安邮电大学陈莉君传授及团队和龙蜥社区毛文安老师），逐渐把这些想法变成了一个初具雏形的开源我的项目。 以后，eunomia-bpf 想要解决的问题或 eBPF 程序以后的开发和散发过程中存的痛点次要有以下两个： 第一对于老手而言，搭建和开发 eBPF 程序的门槛较高，不仅须要必须同时关注内核态和用户态两方面的交互和信息处理，还须要编写用户态加载代码。 第二在不同架构的不同内核版本上无奈方便快捷地打包、散发、公布各种 eBPF 程序。eBPF 很多小工具由不同的语言开发，存在不同的接口，无奈轻易集成到大型的可观测零碎。以后没有很好的插件计划，很多时候必须从新编译整个可观测的框架，再重新部署上线，能力更新 eBPF 探针或数据处理模块。另外，如果引入第三方的用户态数据处理代码，代码解体会导致整个程序解体。 因而，针对下面两个问题，咱们提出了三种解决思路： 1.针对初学者，只须要编写内核态代码即可主动获取内核态导出的数据，编译后即可进行加载和运行，升高了 eBPF 的学习老本，进步了开发效率。2.基于 libbpf一次编译处处运行的个性，将用户态、内核态的编译和运行的齐全拆散，通过规范 JSON 或 WASM模块的形式进行散发，无需进行从新编译，利用启动占用资源少，工夫短，甚至容器启动更短。 WebAssembly (缩写 WASM) 是一种基于堆栈虚拟机的二进制格局， WASM 是为了可移植的指标而设计。可作为 C/C+/RUST 等高级语言的编译指标，使客户端和服务器应用程序可能在 Web 上部署。到当初为止， WASM 曾经倒退成为一个轻量级、高性能、跨平台和多语种的软件沙盒环境，被使用于云原生软件组件，能够在非浏览器环境下运行。 WASM 的设计思路和 eBPF 也有不少相似之处。3.只编写内核态代码的时候，应用 JSON 即可实现散发、加载、打包的过程，对于残缺的、须要用户态和内核态进行交互的 eBPF 利用或工具，能够在 WASM 中编写简单的用户态处理程序进行管制和解决，并且将编译好的 eBPF 字节码嵌入在 WASM 模块中一起散发，在指标机器上动静加载运行。和 WASM 生态项联合能够给 eBPF 程序带来许多个性，同时和 eBPF 程序本来的设计思路也不约而同，比方可移植、隔离性、安全性，它也是一个跨语言、轻量级的运行环境等等。同时也能够借助 WASM 的相干工具实现 eBPF 程序的 OCI 镜像的存储和散发，最近 Docker 官网也推出了一个基于 WASM 的散发工具。以上三局部就是 eunomia-bpf 的外围个性，接着和大家一起来看一些示例。 ...

近日，在 2022 云栖大会龙蜥峰会 eBPF & Linux 稳定性专场上，来自 eBPF 技术摸索 SIG Maintainer 、浙江大学的郑昱笙分享了《eunomia-bpf：eBPF 轻量级开发框架》技术演讲，以下为本次演讲内容： 大家好！我是来自浙江大学的郑昱笙，明天为大家介绍下 eunomia-bpf 我的项目作为一个为了简化 eBPF 程序的开发、散发、运行而设计的轻量级 eBPF 开发框架的背景和指标；再通过一些简略的实例，展现一下 eunomia-bpf 是如何从云端一行命令下载运行 eBPF 程序、只编写内核态代码即可运行和导出事件，以及和 WebAssembly 的联合等性能，最初简要论述一下 eunomia-bpf 的原理和设计实现的思路，探讨一下接下来的倒退方向。 eunomia-bpf 我的项目龙蜥社区开源仓库： https://gitee.com/anolis/eunomia概要eunomia-bpf 起源于 2022 年全国大学生操作系统大赛，心愿将 eBPF 程序作为服务运行，把 eBPF 程序打包为一个 JSON 对象，通过 HTTP 申请即可动静插拔运行任意一个可重定位的 eBPF 程序，并且能够适应不同内核版本和架构。较量完结之后，在高校的几位老师和社区中的一些搭档的帮忙和领导下（在这里重点感激西安邮电大学陈莉君传授及团队和龙蜥社区毛文安老师），逐渐把这些想法变成了一个初具雏形的开源我的项目。 以后，eunomia-bpf 想要解决的问题或 eBPF 程序以后的开发和散发过程中存的痛点次要有以下两个： 第一对于老手而言，搭建和开发 eBPF 程序的门槛较高，不仅须要必须同时关注内核态和用户态两方面的交互和信息处理，还须要编写用户态加载代码。 第二在不同架构的不同内核版本上无奈方便快捷地打包、散发、公布各种 eBPF 程序。eBPF 很多小工具由不同的语言开发，存在不同的接口，无奈轻易集成到大型的可观测零碎。以后没有很好的插件计划，很多时候必须从新编译整个可观测的框架，再重新部署上线，能力更新 eBPF 探针或数据处理模块。另外，如果引入第三方的用户态数据处理代码，代码解体会导致整个程序解体。 因而，针对下面两个问题，咱们提出了三种解决思路： 针对初学者，只须要编写内核态代码即可主动获取内核态导出的数据，编译后即可进行加载和运行，升高了 eBPF 的学习老本，进步了开发效率。基于 libbpf一次编译处处运行的个性，将用户态、内核态的编译和运行的齐全拆散，通过规范 JSON 或 WASM模块的形式进行散发，无需进行从新编译，利用启动占用资源少，工夫短，甚至容器启动更短。WebAssembly (缩写 WASM) 是一种基于堆栈虚拟机的二进制格局， WASM 是为了可移植的指标而设计。可作为 C/C+/RUST 等高级语言的编译指标，使客户端和服务器应用程序可能在 Web 上部署。到当初为止， WASM 曾经倒退成为一个轻量级、高性能、跨平台和多语种的软件沙盒环境，被使用于云原生软件组件，能够在非浏览器环境下运行。 WASM 的设计思路和 eBPF 也有不少相似之处。只编写内核态代码的时候，应用 JSON 即可实现散发、加载、打包的过程，对于残缺的、须要用户态和内核态进行交互的 eBPF 利用或工具，能够在 WASM 中编写简单的用户态处理程序进行管制和解决，并且将编译好的 eBPF 字节码嵌入在 WASM 模块中一起散发，在指标机器上动静加载运行。和 WASM 生态项联合能够给 eBPF 程序带来许多个性，同时和 eBPF 程序本来的设计思路也不约而同，比方可移植、隔离性、安全性，它也是一个跨语言、轻量级的运行环境等等。同时也能够借助 WASM 的相干工具实现 eBPF 程序的 OCI 镜像的存储和散发，最近 Docker 官网也推出了一个基于 WASM 的散发工具。以上三局部就是 eunomia-bpf 的外围个性，接着和大家一起来看一些示例。 ...

1、演讲题目eunomia-bpf: 联合 wasm 的 ebpf 轻量级开发框架 2、演讲工夫2022年11月20日上午10:30 3、演讲人郑昱笙浙江大学学生/eunomia-bpf 开发者 4、引言eBPF 源于 BPF，实质上是处于内核中的一个高效与灵便的虚拟机组件，以一种平安的形式在许多内核 hook 点执行字节码，开发者可基于 eBPF 开发性能剖析工具、软件定义网络、平安等诸多场景。然而，一方面来说目前搭建和开发 ebpf 程序相对来说还是一个门槛比拟高、比较复杂的工作，另外一方面，如何跨语言、跨架构和内核版本，方便快捷的编写、打包、散发、公布和集成各类eBPF 程序也是一个挑战。 5、内容简介eunomia-bpf 是一个开源的 eBPF 动静加载运行时和开发工具链，是为了简化 eBPF 程序的开发、构建、散发、运行而设计的轻量级开发框架。应用 eunomia-bpf ，能够在编写 eBPF 程序时只编写内核态代码，主动获取内核态导出信息，或应用 WASM 在多种语言中进行用户态交互程序的开发。eunomia-bpf 能够将预编译的 eBPF 程序打包为通用的 JSON 配置信息或 WASM 模块，跨架构和内核版本进行散发，无需从新编译即可动静加载运行。 6、直播预约欢迎您通过公众号“达坦科技DatenLord”预约直播，或者登陆腾讯会议观看直播：会议号：581-8301-3525

https://www.bilibili.com/vide... 背景零碎调用是内核提供给用户的性能接口，在咱们的零碎中，通常会运行许多零碎调用，其中有很多零碎调用是由咱们的用户程序来触发的(比方C语言中的printf()函数，理论会触发底层的write()零碎调用)。在绝大多数状况下，零碎调用能够在很短的工夫内执行实现并且返回，然而在某些状况下， 零碎调用可能会执行的比较慢，从而成为咱们过程运行时的瓶颈。对于这些执行较慢的零碎调用咱们能够分为两类，一类是在肯定工夫内执行实现，然而执行工夫过长的零碎调用，咱们能够称之为慢零碎调用；另一类是在肯定工夫内始终未返回的零碎调用，咱们称之为超时零碎调用。在Kindling中，咱们实现了对于这两类零碎调用的捕捉和剖析，并将其报告给下层用户，以便用户洞察零碎调用的状况。 实现原理内核空间eBPF捕捉零碎调用首先，咱们能够应用eBPF技术通过内核提供的rawsyscalls目录下的tracepoint来捕捉所有零碎调用的入口和进口(sysenter对应零碎调用的入口，sysexit对应零碎调用的进口)，可在/sys/kernel/debug/tracing/events/rawsyscalls/中看到该tracepoint的具体信息。图1 sys_enter tracepoint的format信息咱们通过该tracepoint捕捉所有零碎调用，并将每一个零碎调用关联到具体的线程上，发送至用户空间进行进一步解决。 用户空间关联系统调用工夫信息慢零碎调用对于一个零碎调用而言，它有一个enter和一个exit（所有零碎调用都只有一个trap，不会呈现堆栈序列的enter和exit），咱们能够在零碎调用enter时获取以后工夫戳，而后在exit时再获取以后工夫戳，此时两个工夫戳的差值就是该零碎调用的理论执行时长，在Kindling中，咱们将该值称为一个慢零碎调用的latency。图2 慢零碎调用实现示意 超时零碎调用对于超时的零碎调用，它们在一段时间范畴内并未返回，因而咱们无奈获取到零碎调用的exit信息，目前kindling采取的策略是保护一个以tid为key，syscall信息为value的map，当有零碎调用进入时，在map做一次标记，而后咱们会定时去扫描这个map，如果发现map中有超时的零碎调用则立刻将该零碎调用标记为超时零碎调用。图3 超时零碎调用实现示意 demo测试这里咱们写一个简略的demo来测试一下咱们所捕捉到的慢零碎调用 ，咱们写一个最简略的调用nanosleep()零碎调用的例子，让过程睡眠3秒钟，咱们能够在运行的Kindling输入日志中看到捕捉到的信息：咱们能够看到，Kindling捕捉到了该零碎调用，并给出了其类型，执行时长以及TID、PID等具体信息。 总结首先，咱们通过eBPF技术和内核提供的零碎调用tracepoint捕捉了所有的零碎调用数据，而后把零碎调用与线程信息做了关联，而后咱们在用户空间对系统调用的enter和exit进行了latency的计算以判断是否为慢零碎调用，特地的是，对于那些超时的零碎调用，咱们无奈间接计算latency，采取了应用map标记零碎调用入口并定时扫描map的策略，从而实现对于超时零碎调用的捕捉。Kindling是一款基于eBPF的云原生可观测性开源工具，旨在帮忙用户更好更快的定界云原生零碎问题，并致力于打造云原生全故障域的定界能力。 Kindling是一款基于eBPF的云原生可观测性开源工具，旨在帮忙用户更好更快的定界云原生零碎问题，并致力于打造云原生全故障域的定界能力。关注咱们退出咱们

编者按：BPF 技术还在热火朝天的倒退着，本文先通过对 BPF 常识的介绍，率领大家入门 BPF，而后介绍 coolbpf 的近程编译（原名 LCC，LibbpfCompilerCollection），意为酷玩 BPF，指标把简单的 BPF 开发和编译过程简化，本文还会以一个示例来体验 coolbpf 的享受式开发。本文整顿自龙蜥大讲堂第 20 期，精彩分享视频回放已上传至龙蜥官网（首页-动静-视频），欢送查看！ 一、 引言要实现一个 BPF 二进制程序的开发，须要搭建开发编译环境，要关注指标零碎的内核版本状况，须要把握从 BPF 内核态到用户态程序的编写，以及如何加载、绑定至对应的 HOOK 点期待事件触发，最初再对输入的日志及数据进行解决。 这几个过程对于一个刚接触 BPF 的同学会感觉相当繁琐。本文先通过对 BPF 常识的介绍，率领大家入门BPF，而后介绍 coolbpf 的近程编译（原名 LCC，LibbpfCompilerCollection， 意为酷玩 BPF，指标把简单的 BPF 开发和编译过程简化），以一个示例来体验 coolbpf 的享受式开发。 二、 BPF入门BPF 最早在 1992 年被提出，过后叫伯克利包过滤器（Berkely Packet Filter，个别称为cBPF），号称比过后最先进的数据包过滤技术快 20 倍，次要利用场景在 tcpdump、seccomp。 2014年，Alexei Starovoitov 对 BPF 进行彻底地革新，提出 Extended Berkeley Packet Filter (eBPF)。eBPF 指令更靠近硬件的 ISA，便于晋升性能，提供了可基于零碎或程序事件高效平安执行特定代码的通用能力，通用能力的使用者不再局限于内核开发者。其应用场景不再仅仅是网络分析，能够基于 eBPF 开发性能剖析、零碎追踪、网络优化等多种类型的工具和平台。咱们通常不加区分，把 cBPF 和 eBPF 都称之为 BPF。 2.1 BPF 知识点总结大家都在谈 BPF，介绍BPF的文章也很多，这里先总结 BPF 的知识点，最初咱们从最根底的 BPF 指令架构及 map 和 prog type 去介绍如何疾速入门。 ...

Kindling通过eBPF技术实现了无侵入性的容器环境监控，在调用拓扑图上展现了黄金指标：申请量、申请延时、申请错误率、发送和接管的网络流量，帮忙理解集群中不同节点的根本性能状况。当须要进一步排查问题时，还须要通过其余面板来定位具体的问题边界，本期给大家介绍Kindling的网络详情面板。上面是Kindling中单K8S集群下某个命名空间的调用拓扑，通过图能够看到prometheus-k8s与process-exporter的工作负载间通信SRTT比拟高，可能存在物理网络的问题。那SRTT指标的变化趋势是怎么的，是否有突增景象？这个时候就能够应用网络详情面板来进一步排查了。 网络详情面板网络详情面板次要用来查看整个集群下POD间的网络状况。在通过拓扑图找到网络指标异样的POD后，能够通过本面板来进一步排查。面板的最下面区域是检索区域。通过筛选源端工作负载和目标端工作负载，能够只查看感兴趣的工作负载下POD间的网络状况。也能够通过面板上面的列表区域间接增加检索字段，来更细粒度的筛选感兴趣的POD。例如查看源端POD为alertmanager-main-0的数据。面板剩下的局部分为4个区域。上面每个区域能够解决什么问题。 整体指标区域这个区域的指标能够用来评估整体容器网络的状况，并提供具体的SRTT指标的变化趋势。 重传数：展现了容器网络重传包的数量。若产生重传数突增，而整体申请量和网络流量没有突增或者错误率突增的状况下，则示意容器网络不稳固或者性能变差。须要排查物理网络的问题。丢包数：展现了工作负载在解决从容器网络中接管的数据包时，在网络协议栈中失落包的数量。若这个数量突增，示意呈现了比如说缓冲区满、包非法等状况而把包抛弃，或者iptable等防火墙设置谬误。SRTT：每条线展现了工作负载之间的往返延时，即咱们应用ping去探测的网络延时。SRTT过高很容易引起申请超时。 工作负载连贯详情区域该列表能够查看单个集群下有产生过通信的2个工作负载间的申请延时、SRTT、发送流量、接管流量、丢包数等。通过该表能够帮忙找到利用容器网络层面问题，而造成通信性能差的具体两段的POD名称，以便咱们能够有针对性的进行前面的物理网络排查。能够看到prometheus-k8s与process-exporter的SRTT比拟高，和拓扑图中的一样。 重传详情区域该列表显示了哪些POD之间有重传，能够看到产生数据包重传两端的具体信息：源端命名空间、源端工作负载、源端POD、源端IP、目标端命名空间、目标端工作负载、目标端POD、目标端IP以及具体的重传数量。能够筛选出特定范畴内的POD，例如prometheus-k8s与process-exporter间工作负载的详情数据。 丢包详情区域和上述列表一样，能够看到POD级别，只是显示的是丢包数指标。该列表显示了哪些POD之间有丢包，能够查看产生网络协议栈丢包两端的具体信息：源端命名空间、源端工作负载、源端POD、源端IP、目标端命名空间、目标端工作负载、目标端POD、目标端IP以及具体的丢包数量。 Kindling是一款基于eBPF的云原生可观测性开源工具，旨在帮忙用户更好更快的定界云原生零碎问题，并致力于打造云原生全故障域的定界能力。关注咱们退出咱们

什么是page fault在Linux内核中，每一个过程都有一个独立的虚拟地址空间，而过程自身感知不到真正的物理内存的存在（比方某过程感知到的内存是间断的，然而实际上它被调配的内存是物理内存中扩散的空间）。MMU（内存治理单元）负责实现对于这种虚拟地址-物理内存地址的转换工作。Linux为每一个过程保护了一张页表，用于记录虚拟地址和物理内存地址之间的关系，并在过程运行时实时进行地址转换从而使得过程拜访到真正的物理内存。图1 内存治理单元MMU 而咱们要提到的page fault便是在这种场景下产生的，page fault大抵能够分为三类： major page fault：过程要拜访的页面不在真正的物理内存中，可能须要从磁盘中载入（比方Linux开启了swap机制，内核通过LRU页面置换算法将页面置换到了磁盘中暂存），这个时候将会产生一个major page fault。图2 swap页面置换机制 minor page fault：过程要拜访的页面在物理内存中，然而MMU还没有建设过程的虚拟地址和相应物理地址的映射关系，这个时候就会触发soft page fault（比如说咱们应用malloc函数在堆上申请内存，在过程不拜访这片虚拟内存之前它的物理内存页是不会被理论调配的，当过程第一次拜访应用malloc调配的内存空间时，因为会调配物理内存，这时候只须要再建设虚拟内存-物理内存的映射关系即可）。invalid fault：就是segment fault，过程的内存越界。在kindling中，咱们重点关注前两种page fault，事实上，结合实际需要，咱们其实往往只须要关注major page fault即可，因为minor page fault从某种意义上来说并不算是一种"fault"，它是内核中广泛且常见的一种景象，而major page fault的呈现往往意味着零碎开始咱们内存可能不太够用了，这时候咱们就须要重点关注是哪些线程触发了这些major page fault，从而帮忙咱们更好的定位和排查问题。 无关page fault的tracepointLinux内核为page fault提供了tracepoint，/sys/kernel/debug/tracing/events/exceptions外面有相干的tracepoint构造体形容，/sys/kernel/debug/tracing/events/exceptions分为pagefaultkernel和pagefaultuser，对应于内核和用户态的page fault（内核也可能page fault，比方copyfromuser的时候）。咱们关上外面的format文件能够看到如下构造： name: page_fault_kernelID: 115format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:unsigned long address; offset:8; size:8; signed:0; field:unsigned long ip; offset:16; size:8; signed:0; field:unsigned long error_code; offset:24; size:8; signed:0;print fmt: "address=%pf ip=%pf error_code=0x%lx", (void *)REC->address, (void *)REC->ip, REC->error_codename: page_fault_userID: 116format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:unsigned long address; offset:8; size:8; signed:0; field:unsigned long ip; offset:16; size:8; signed:0; field:unsigned long error_code; offset:24; size:8; signed:0;print fmt: "address=%pf ip=%pf error_code=0x%lx", (void *)REC->address, (void *)REC->ip, REC->error_code这个构造外面有个error_code的字段，含意如下： ...

1 我的项目概览Kindling collector我的项目作为Go端分析器，应用相似opentelmetry的pinpeline进行数据分析。其中波及5个组件： UdsReceiver - Unix Domain Socket接收器，接管探针事件并传递给后续的网络分析器。NetworkAnalyzer - 网络事件分析器，将接管的Read / Write事件匹配成单次申请后，依据协定解析申请内容生成要害指标，传递给后续的分析器。K8sMetadataProcessor - K8S指标处理器，补充K8S指标并传递给后续的聚合处理器AggregateProcessor - 数据聚合处理器，将接管的指标数据生成Trace和Metric，传递给给后续的转发器。OtelExporter - Opentelmetry转发器，将Trace / Metric数据转发给Prometheus进行展现。其中协定解析流程次要在NetworkAnalyzer组件中进行，将接管的申请/响应事件成对匹配后，交由parseProtocols()函数解析出协定指标。 1.1 协定解析流程NetworkAnnalyzer.parseProtocols()办法定义了整体解析流程，依据协定解析器别离解析申请和响应，当最终都胜利时输入指标。 1.2 协定解析设计思路失常的协定解析只负责逐帧解析指标性能。现已反对5种协定解析，当协定越来越多时，遍历引起的解析会越来越耗时，那么需引入fastfail疾速辨认协定对于简单的多报文协定，如Kafka有不同的API报文，而雷同API也有不同的版本报文。将所有报文解析逻辑都写在一起会使整个类过于臃肿且不易保护。为此引入树形多报文构造用于疾速且低耦合地实现开发。 1.2.1 报文解析构造体在树形报文解析过程中，有如下2个场景须要思考 当父协定解析了指标A，子协定解析可能会用到A指标，那么父子协定解析的指标须要透传。父协定已解析了局部报文长度的内容，那么子协定在开始解析时可间接跳过相应长度的内容进行解析，此处引入偏移量用于下一个协定跳过解析。定义PayloadMessage，封装报文内容、读取偏移量和指标存储的Map。 type PayloadMessage struct { Data []byte Offset int attributeMap *model.AttributeMap}1.2.2 报文解析API因为引入协定树，协定解析过程parse() (ok bool)将不再实用。协定树中的个协定的解析胜利不示意整个协定解析胜利，需解析整颗树的协定是否胜利，将API扩大为parse() (ok bool, complete bool)。 对于单层协定(HTTP)，返回为(ok, true)基于以上几点需要，设计树形构造的报文解析器PkgParser。PkgParser定义了fastFail(疾速辨认失败) 和parser(解析单个报文)函数；每个协定只需注册本身的PkgParser即可接入整套流程。fastFail(message *PayloadMessage) (fail bool) 申明协定是否辨认失败，用于疾速辨认协定parser(message *PayloadMessage) (ok bool, complete bool) 解析协定，将解析出的指标存储到message的Attributes中返回是2个参数： 是否解析胜利是否解析实现 (默认为true，当为false次要是用于嵌套解析过程，例如先定义一个头解析，再定义不同的音讯体解析)。1.3 申请 / 响应解析ProtocolParser定义了申请和响应的解析器，并提供ParseRequest()和ParseResponse() API用于解析申请和响应其中response的message携带了request解析出的attributes指标，用于匹配。eg. kafka的correlationId request和response报文需统一，且response报文解析用到了request的key。 2 开发流程 2.1 增加协定名const ( HTTP = "http" ... XX = "xx" // 此处替换具体协定名 ...)2.2 创立协定analyzer/network/protocol目录下创立文件夹xx，xx替换为具体协定，并创立3个文件xx_parser.go、xx_request.go 和 xx_response.go ...

CCF GitLink 编程夏令营（GitLink Code Camp，简称GLCC）是在 CCF 中国计算机学会领导下，由 GitLink 社区联结 CCF 开源倒退委员会（CCF ODC）独特举办的面向全国高校学生的暑期开源我的项目实习打算。Kindling社区共申报了3个课题，目前学生报名正在炽热进行中。CCF GitLink开源编程夏令营 · 学生凋谢报名！ Kindling是一款基于eBPF的云原生可观测性开源我的项目，旨在帮忙用户更快更好的定界云原生零碎问题，并致力于打造云原生全故障域的定界能力。通过Kindling，用户能够疾速定界问题类型，如是网络问题、容器问题还是代码问题等，而后再利用APM等工具定位具体问题，大大提高故障定位的效率。Kindling本次申报的3个课题笼罩了高中低3种难度，并提供了丰富的物质奖励。 学生们能够依据本人的趣味和善于的技能选取其中一项或多项课题。《应用eBPF技术扩大kindling在文件系统方面性能剖析的能力》《实现url的聚合算法，缩小数据发散维度》《反对rocketmq协定辨认和解析，以提供kindling剖析利用和rocketmq的交互性能剖析》 欢送对开源或者Kindling我的项目感兴趣的学弟学妹们退出咱们，一起建设Kindling社区。退出咱们关注咱们

在本周进行的Kindling研讨会上，Kindling团队的小伙伴给大家分享了多语言微服务环境下的监控问题以及解决对策，并对相干指标进行了解读。本次研讨会也星散了云可观测畛域的各路大神：观测云的CEO蒋总、云杉的背阴总以及其余可观测畛域的大佬。在前面的交换环节，就以后用户在应用Kindling过程中存在的一些问题，Kindling团队的小伙伴做了答复。如有用户问：Kindling如何解决内存占用的问题？答：目前引起内存占用的起因包含URL发散、慢trace、零碎调用的事件源多等，解决方案是尽量减少事件源的数据，只取须要的事件源进行剖析，目前，Kindling对于事件源进行了分类，能够按需取用。前面，蒋总、背阴总也参加到了探讨中，与Kindling团队的小伙伴们一起就以后云可观测方面的一些问题以及将来的倒退方向进行了交换和探讨，如高基数存储的问题，因为微小的数据量，目前高基数存储是云可观测畛域普遍存在的一个问题，大家就这个问题开展了探讨，并替换了各自的认识。 Kindling是一款基于eBPF的云原生可观测性开源我的项目，旨在帮忙用户更快更好的定界云原生零碎问题，并致力于打造云原生全故障域的定界能力。通过Kindling，用户能够疾速定界问题类型，如是网络问题、容器问题还是代码问题等，而后再利用APM等工具定位具体问题，大大提高故障定位的效率。 目前，Kindling曾经开源轻量版，能够提供全局topo、DNS、workload等指标数据，还能够依据本身需要自定义一些监控指标。轻量版能够方便快捷地与其余可观测性产品以及现有监控计划集成，如Prometheus，后续也会依据须要反对更多产品的集成，这方面也欢送大家与咱们交换。 不久，Kindling还将开源标准版，能够为用户提供更简略快捷牢靠地故障定界能力，以及更具体的数据。将来，Kindling开源版将在火焰图、on-off CPU、GRPC以及疾速集成等方面演进，欢送对这方面有趣味的小伙伴退出Kindling小家庭，一起为Kindling社区做奉献，也欢送在云可观测性方面有需要的小伙伴多多交换、多多反馈，让Kindling能够更好地解决云可观测性方面的问题。 退出咱们关注咱们

eBPF技术正以令人难以置信的速度倒退，作为一项新兴技术，它具备扭转容器网络、平安、可观测性生态的后劲。eBPF作为更加现代化的内核技术，相较于内核模块，它的编写难度曾经有了较大的升高，然而不可否认对于一般开发者还是有肯定门槛。因而，很多云原生软件会在eBPF零碎调用(函数)和libbpf之上封装一层更加简略易用的api，比方falco的libs、bcc的libbcc、cilium的cilium-ebpf。笔者将这些依赖库称之为eBPF的基础设施。Kindling专一于云可观测性畛域，致力于排查各种简单故障，包含但不限于网络、文件、内存、on-off cpu堆栈，解决上述问题是Kindling的第一优先级指标，本着不反复造轮子的准则，Kindling无心于再发明一个eBPF的基础设施。 丰盛的eBPF基础设施库当下有很多库能够供开发者抉择，比方libbcc、dropbox的goebpf、cilium的ebpf库、calico的底层库、falco的lib库。这些库次要帮助实现以下性能： 将eBPF程序加载到内核中并且重定位将map载入初始化，提供fd供用户态和内核态交互更敌对的开发应用体验基于此，咱们别离抉择了2个基于c和go的基础设施库来比照： LibbccGobpfFalco-libsCilium-ebpf开发语言c或cgogocc通过bpf2go转换成go是否反对CO-RE反对反对不反对（正在反对）反对api欠缺度较好较好较好很好初始化流程欠缺水平好好好好在这4个比拟对象中，libbcc和gobpf一脉同源，gobpf是libbcc的go实现，其原理是用cgo包装了libbcc和libelf。faclo-libs是纯c语言的实现，cilium-ebpf则是纯go语言的实现。在性能实现方面，这些库都实现了eBPF程序加载应用的根本流程。不过这些库别离也领有一些其独有的劣势，比方： Cilium-ebpf因为cilium踩得坑较多，在一些细节方面更加杰出，比方eBPF中应用memcmp函数存在一些可用性的BUG(详见：https://lists.llvm.org/piperm...)，cilium就重写这些根底库函数，保障函数是可用的libbcc和faclo-libs因为是纯c的库，不须要通过cgo这样的形式调用，相对来说性能也更加杰出一点libbcc有更好的脚本语言生态，bcc中很多python和lua这类运行在libbcc之上的脚本曾经很成熟，能帮忙用户更快和更容易的写出eBPF程序Kindling抉择falco-libs的N大理由既然根底的性能这些库都能实现，并且在细节方面cilium更加杰出，那么为什么Kindling仍旧抉择了falco-libs作为了eBPF基础设施呢？理由如下： 对低版本内核的反对家喻户晓，eBPF在4.14内核版本以上能力应用。然而现阶段很多发行版比方centOS7的内核版本都是3.x,无奈应用eBPF(centOS7.6以上曾经通过eBPF patch反对)。falco-libs应用内核模块实现了和eBPF雷同的性能，且性能体现更加杰出，Kindling认为centOS7.4等版本在国内现阶段还是广泛应用的，在低版本内核中体验到Kindling可观测性的性能是十分重要的。因为采纳了faclo-libs，Kindling反对的发行版本: 发行版版本Ubuntu16.04+Debian9.0+RHEL7+CentOS7+内核模块更杰出的性能体现（图出自falco-libs github）：faclo社区的性能测试后果 对于零碎调用的精细化整顿falco-libs是syscall方面的专家，而Kindling对syscall的剖析需要也必不可少。syscall是Kindling可观测性事件的重要起源，syscall能够剖析出一次网络调用的工夫、具体网络报文，一次 文件读写等指标。在Kindling的将来性能布局里，oncpu offcpu分析也须要用到futex,write,epoll等syscall。facalo-libs梳理了300多个syscall，将其中的主要参数从内核数据结构转换成如下相似事件构造： /* PPME_SOCKET_GETSOCKOPT_E */{"getsockopt", EC_NET, EF_MODIFIES_STATE | EF_DROP_SIMPLE_CONS, 0 },/* PPME_SOCKET_GETSOCKOPT_X */{"getsockopt", EC_NET, EF_USES_FD | EF_MODIFIES_STATE| EF_DROP_SIMPLE_CONS, 6, {{"res", PT_ERRNO, PF_DEC}, {"fd", PT_FD, PF_DEC}, {"level", PT_FLAGS8, PF_DEC, sockopt_levels}, {"optname", PT_FLAGS8, PF_DEC, sockopt_options}, {"val", PT_DYN, PF_DEC, sockopt_dynamic_param, PPM_SOCKOPT_IDX_MAX}, {"optlen", PT_UINT32, PF_DEC}}},/* PPME_SOCKET_SENDMSG_E */{"sendmsg", EC_IO_WRITE, EF_USES_FD | EF_WRITES_TO_FD | EF_MODIFIES_STATE, 3, {{"fd", PT_FD, PF_DEC}, {"size", PT_UINT32, PF_DEC}, {"tuple", PT_SOCKTUPLE, PF_NA} } },/* PPME_SOCKET_SENDMSG_X */{"sendmsg", EC_IO_WRITE, EF_USES_FD | EF_WRITES_TO_FD | EF_MODIFIES_STATE, 2, {{"res", PT_ERRNO, PF_DEC}, {"data", PT_BYTEBUF, PF_NA} } },Falco-libs对事件的丰富化Falco-libs会依据内核事件的tid，fd等信息主动补全事件的以下字段： ...

问题形容最近在帮助用户做业务的容器化迁徙时，对业务做压力测试，发现ui服务的/homepage接口呈现了偶发性的响应申请超时。给大家分享下排查问题过程。 问题定位先通过skywalking看看相干ui的/homepagetrace，通过下图能够看到总耗时超过5828ms。发现延时呈现在ui/homepage的self上，共耗时4005ms。其余依赖调用的工夫只用了1823ms。能够确认从ui/homepage调用app/homepage的申请产生到申请数据传输实现耗时太多。当初没有更好的办法进一步排查具体的耗时状况，进入ui容器内，只能应用curl拜访app/homepage看看。 $curl -4 -w "@curl-format.txt" -o /dev/null -l "http://app.default.svc.cluster.local:8091/homepage" % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- 0:00:03 --:--:-- 0time_namelookup: 4.150time_connect: 0.800time_appconnect: 0.000time_redirect: 0.000time_pretransfer: 0.021time_starttransfer: 0.000----------time_total: 4.981间接在pod中应用tcpdump抓包，应用wireshark剖析后果如下： app.default.svc.cluster.local 域名解析成IP的总共耗时4.1s。在app.default.svc.cluster.local 的根底上，顺次增加default.svc.cluster.local、svc.cluster.local、cluster.local、openstacklocal 后缀进行域名解析，都失败了。最初一次应用app.default.svc.cluster.local 进行解析胜利了。为啥会有屡次申请DNS，百度了下发现K8S的DNS解析机制，和resolv.conf文件中ndots和search两个参数的机制作用有关系。查看容器的/etc/resolv.conf配置： nameserver 10.96.0.10search default.svc.cluster.local svc.cluster.local cluster.local openstacklocaloptions ndots:5 single-request-reopen援用ndots: 5 示意如果域名蕴含的 "." 少于5个，则先增加 search 后缀，再应用相对域名；如果域名蕴含的 "." 大于等于5个，则先应用相对域名，再增加 search 后缀。起因是app.default.svc.cluster.local少于5个点，所以先加search后缀。最初再应用app.default.svc.cluster.local进行解析。 ...

背景Kindling-agent是基于eBPF的云原生可观测性开源工具Kindling中采集端的组件，可能通过采集和剖析内核事件，获取运行于同一宿主机上的其余服务的业务、网络等指标。其工作模式是在主机上以独立过程的形式收集所需数据，所以只须要咱们在利用所在主机部署Kindling-agent即可启动相应能力，随后能够通过prometheus和grafana套件对不同机器上探针采集的数据进行整合剖析和查看，当然也能够用其余工具获取数据并进行剖析展现。只管Kindling-agent基于eBPF的形式进行的监控形式缩小了对被监控利用的侵入，但始终还是和用户利用共享同一台宿主机的CPU、内存、磁盘、网络等资源。这使得所有想要应用Kindling-agent的用户都想晓得该工具在实在环境中的性能体现以及预期资源应用状况。Kindling我的项目进行了一系列的测试来验证该采集工具的性能体现，这些测试反馈了Kindling-agent在不同压力下良好的性能体现和可靠性。 测试指标测验高负载(5000 TPS)场景下，Kindling-agent对利用的性能影响和agent自身的资源应用状况。测验惯例负载(1000 TPS)场景下，Kindling-agent对利用的性能影响和agent自身的资源应用状况。测试环境内核版本3.10.0-1160.53.1CPUIntel(R) Xeon(R) Platinum 8269CY CPU @ 2.50GHz，8C内存16GJmeter和Kindling-agent以K8S工作负载的形式进行部署，测试利用和Jmeter别离运行在两台CentOS7(fedora)上。 后果阐明基线指测试利用在无探针装置时的进行压力测试取得的指标，包含以下信息:• machine-cpu: 机器总CPU应用总体百分比• machine-mem: 机器总内存应用总体百分比• application-cpu: 测试利用CPU应用核数• application-memory: 测试利用内存应用• application-latency: 测试利用申请提早• application-tps：测试利用每秒事务数装置探针后的测试利用在压力测试时的性能指标。探针本身的性能损耗，包含CPU和内存应用，在一些较低内核版本的机器中，Kindling应用内核模块代替eBPF实现了雷同的性能，你将会在测试中看到两种实现下不同的性能体现。测试用例用例1为了验证Kindling-agent在高负载下的性能体现，用例1应用了Skywalking的benchmark1程序。该程序为一个惯例的Springboot利用，对外提供HTTP服务，其预期TPS为5000，预期延时为85ms。Kindling会捕捉该程序的异样/慢的申请数据(即Trace)，并统计程序运行时间段内的关键性指标(Metric)，如均匀响应工夫、错误率、申请字节数和申请数等。这些Trace和Metric可能无效的保障程序的可观测性。上面的测试后果中是待测程序在5000TPS下的性能体现，baseline示意未启用agent下的资源开销和性能体现。在资源应用上，Kindling-agent 一共耗费了约0.64C来解决并统计 5000 TPS下的要害性能指标，并通过Prometheus裸露在HTTP接口上。对于应用程序的资源应用，在基线测试中，应用程序须要破费2.5C解决现有的业务申请，在部署了探针后，程序须要应用2.6C解决现有的业务申请，即绝对于基线减少了4%的额定开销，内存方面则简直没有影响。对于应用程序的服务体现，能够看到，在5000TPS的负载下，Kindling-agent对应用程序的响应工夫和TPS的影响都十分小。大多数失常的业务都蕴含肯定的解决逻辑，单节点吞吐量很少可能达到5000TPS。因而，对于大多数的业务利用来说，不须要放心Kindling-agent对利用自身的解决能力造成影响。 用例2如之前所述，用例1中的TPS显著高于失常的用户利用。为此，测试用例2减少了解决每个申请时的CPU应用，并下调了申请压力，使该场景更靠近于生产环境下的惯例压力。在资源应用上，Kindling-agent 一共耗费了 0.12C 用于数据处理和统计。对于利用的资源应用，在1000TPS下，基线应用1.37C 解决现有的申请，装置agent后相较于基线简直没有额定开销。服务体现方面，在1000TPS下，基线的响应工夫为272ms , TPS为 1044 ; 装置agent后相较于基线简直不变。总的来说，在惯例负载下，Kindling-agent对用户利用简直没有影响。 总结上述用例阐明Kindling能够在较低的资源开销下反对轻量化部署，且易于治理；可能深入分析申请到协定栈在内核执行状况；可能提供语言无关，利用无侵入的监控体验，为您的利用带来新一代的可观测能力。测试原始数据详见：原始数据 对云原生感兴趣的小伙伴欢送分割咱们：退出咱们关注咱们

注，原文来自 https://blog.mygraphql.com/zh... 。如你看到的转载图片不清，请回到原文。 为何现代人如同都很忙，忙着跟边远的人社交，却很容易漠视眼前的人事，更别提那些不间接体现出价值的根底认知了。要花工夫认真看一编文章前，都要问一个问题：WHY。这才会有 TLDR; 的呈现。一生学习是个口号，但也仅仅是个口号。看看身边的那些放満书的人，有几个真去浏览？社会人大都有事实地认为，继续学习只应该产生在考试前。在社会卷时，就好好做个社会人。 故事是这样的：话说，在风口上的微服务(Micro-Service)很美妙，云原生(Cloud Native) 很美妙，服务网格(Istio) 很美妙，旧爱非阻塞事件响应编程(epoll)很美妙。但呈现性能优化需要的时候，性能工程师会把下面的“美妙”会替换为“简单”。是的，没太多人在架构设计或重构前会花太多工夫在性能上和那些开箱即用的基础架构上。直到一天遇到问题要救火…… 终于，为救火，咱们还要看基础架构是如何工作的。但从何动手？间接看源码？ git clone，开始读源码？ 很大可能，最初会迷失在源码的陆地中。 YYDS，Linus Torvalds 说过： https://lwn.net/Articles/193245/In fact, I'm a huge proponent(支持者) of designing your code around the data, rather than the other way around, and I think it's one of the reasons git has been fairly successful (*) ... (*) I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships. ...

引言真正意义上的eBPF技术尽管诞生还不到十年工夫(2014年首次提出eBPF概念)，但曾经倒退成为当下煊赫一时的技术。去年8月，由微软、谷歌、Facebook(已更名为meta) 等公司联结成立了eBPF基金会，大力发展eBPF技术。最近几年，eBPF技术在国内也失去了广泛应用，很多大厂也开始关注并采纳eBPF技术。 eBPF简介eBPF是extended BPF的缩写，而BPF是Berkeley Packet Filter的缩写。对linux网络比拟相熟的小伙伴对BPF应该比拟理解，它通过特定的语法规定应用基于寄存器的虚拟机来形容包过滤的行为。比拟罕用的性能是通过过滤来统计流量，tcpdump就是基于BPF实现的。而eBPF对它进行了扩大来实现更多的性能。eBPF 技术支持在不同的集成点动静地将 eBPF 字节码插入到 Linux 内核中，例如: 网络 IO、利用套接字和跟踪点，以实现安全性、网络和可见性逻辑。eBPF 具备高效率和灵活性。要理解更多对于 eBPF 的信息，可拜访eBPF.io和性能剖析大神brendan gregg的主页。 开源我的项目traceetracee是一款易于应用的轻量级零碎追踪工具，在该工具的帮忙下，开发人员能够实时监控零碎调用和其余零碎事件。它只会追踪新创建的过程和容器，也就是Tracee运行之后所开启的过程和容器，这样就能够帮忙用户将注意力放在相干事件上，而不是零碎中所产生的每一件事件。向Tracee增加新事件(尤其是零碎调用)也非常简单，而且无需手写任何代码。除了追踪性能之外，Tracee还可能捕捉到写入磁盘或内存的文件，并提取动静加载至应用程序内存中的代码。在这些性能的帮忙下，咱们将可能获取到运行过程的外部状况。 bpftracebpftrace是 Linux 高级追踪工具和语言。该工具基于 eBPF 和 BCC 实现了通过探针机制采集内核和程序运行的信息，而后用图表等形式将信息展现进去，帮忙开发者找到暗藏较深的 Bug、平安问题和性能瓶颈。 FalcoFalco是sysdig的平安我的项目，它应用eBPF和Linux模块作为内核跟踪库开发。Sysdig Falco是一种旨在检测异样流动开源的零碎行为监控程序。作为Linux主机入侵检测零碎，对Docker也很有用，因为它反对容器上下文，如container.id、container.image或其规定的命名空间。 CiliumCilium次要用于提供并通明地爱护网络连接和应用程序工作负载(如应用程序容器或过程)之间的负载平衡。在第3/4层运行，提供传统的网络和平安服务，以及第7层爱护和平安应用利用协定，如 HTTP、 gRPC 和 Kafka。Cilium 被集成到常见的配器框架中，比方 Kubernetes。 KatranKatran是一个 c + + 库和 BPF 程序，用于构建高性能的第四层负载平衡转发平台。Katran 利用内核中的 XDP 基础设施为疾速数据包的解决提供内核设施。Katran 是 Facebook 开源的高性能第 4 层负载均衡器，目前在 Facebook 外部处于孵化阶段。其次要性能个性在于： 疾速（特地是在驱动模式下的 w/ XDP）性能与多个 NIC 的 RX 队列呈线性关系RSS 敌对的封ElkeidElkeid是用Linux模式技术栈开发的内核事件捕捉工具，由字节跳动率先开源。其次要性能个性有： 对于同一类事件会有不同的syscall数据形容，进而取得不同的数据信息起源。采集的数据具备清晰的过程链信息。Driver和Agent会追溯以后过程的父过程和先人过程，默认driver配置反对最高上溯8个先人过程，实际中根本能够将绝大部分过程的残缺过程链采集下来。会记录内核中的模块变动以及异常情况。Elkeid 装置后，对后续尝试内核批改的过程均能够间接发现并上报相应数据，同时如果存在任何暗藏内核模块，对/proc/目录的Hook，对过程进行ptrace等行为均能够间接发现并生成数据上报。针对平安场景减少了独有数据获取和记录维度kubectl-tracekubectl-trace是IO Visor开源的，帮忙用户在Kubernetes集群中安顿执行BPF程序的kubectl插件，能够用来剖析零碎的性能问题，装置便捷。 eHIDSeHIDS是一个HIDS的雏形。HIDS全称是Host-based Intrusion Detection System，即基于主机型入侵检测零碎，部署在主机内的，次要是对主机的异样行为进行检测，比方新建文件，创立过程，连贯等。 KindlingKindling是一款基于 eBPF 的云原生可观测性开源我的项目，旨在帮忙用户了解从内核到代码堆栈的应用程序行为。目前，它提供了一种简略的办法来获取 Kubernetes 环境中的网络流视图，以及许多内置的网络监督仪表板，如重传、 DNS、吞吐量、 TPS等。相比于bcc等小工具型产品，它突出了无侵入式地进行7*24小时观测的个性。Kindling集成了sysdig的agent-lib层，但丰盛了更多的hook点，退出了kprobe的应用并将在后续开发uprobe性能。Kindling提供了两个具备不同性能然而具备雷同agent的版本。轻量级版本集成到了Prometheus中，它应用PromQL来查问来自Prometheus的数据，因而很容易集成。然而因为Prometheus的基数限度，无奈存储详细信息。对于规范版本，Kindling提供了更为具体的信息，并应用ElasticSearch作为后端来存储原始信息。 ...

Kindling是一款基于eBPF技术的云原生可观测性开源我的项目。本文将次要介绍如何通过Kindling对HTTP协定进行解析。在故障排查过程中，咱们通常对申请性能、申请内容和返回内容感兴趣。这使咱们能晓得申请和接管了什么内容，是否有异样等根本信息。如何获取申请的具体详细信息，传统形式是通过tcpdump获取申请包数据，而后通过wireshark查看其具体协定内容。tcpdump尽管在生产环境中常常应用，但因为获取的数据量和大小限度，不适宜始终开启，只有在排查问题时应用。而获取的数据也无奈间接查看，需下载到本地通过wireshark剖析查看。基于tcp的诸多问题，所以Kindling通过eBPF形式实现申请的具体分析。那么Kindling是如何实现实时可用的协定解析性能呢？次要波及3块性能：• 数据采集• 申请/响应关联• 申请/响应解析协定解析流程图 1 数据采集先来查看下一个简略的HTTP服务HTTP服务伪代码 当接管到申请时会有accept/read/write/close等函数执行，这些函数最终执行内核的零碎调用。HTTP服务接管申请流程图 应用strace命令查看一次申请的零碎调用状况• read接管HTTP申请/test• 第一个write日志输入• 第二个write 返回HTTP后果 从日志中可剖析出，申请通过read零碎调用，日志和响应都是通过write零碎调用。Kindling已实现对系统事件调用进行抓取，并将相干的read和write零碎调用转换为Kindling事件，最终生成3条事件。事件格局定义可参见kindling_event.proto。零碎调用与Kindling事件映射 参数阐明：• fd 读写申请的文件描述符• size 申请报文大小• res 返回大小• data 申请报文内容• latency 读/写操作耗时• category 事件类型，NET是指网络事件，FILE是文件读写事件 2 申请/响应关联惯例的TCP申请都会用同一个FD进行通信，只需依据过程号和FD就能关联同一个申请和响应。申请-响应关联 3 申请/响应解析尽管有了报文，但不同的协定定义的标准也不同。那么如何晓得该报文是什么协定，并且用该协定进行解析呢？次要波及2块内容：• 协定辨认• 协定解析申请-响应解析流程图 3.1 协定辨认通过特色或关键字疾速匹配协定，缩小协定解析的次数，晋升整体解析的性能。HTTP报文标准对于HTTP申请来说，通过HTTP版本号(HTTP/1.0或HTTP/1.1)能够疾速辨认协定。但因为抓包大小限度，如果一个申请的URL长度超过包的大小，那么无奈获取后续的HTTP版本号，于是采纳端口协定配置形式也能辨认协定。 3.2协定解析协定解析是为了产生指标用于后续剖析，在解析过程中需依据协定本身的格局进行解析。因为报文内容是byte数组格局，Kindling提供了封装好的API用于解析。以HTTP协定为例，可解析出如下信息：• 申请行 - 办法、URL信息• HTTP头信息 - traceId信息• 状态行 - 状态码信息HTTP解析样例 3.2.1 解析HTTP申请解析申请过程就是对申请进行逐帧解析，读取到对应的属性后最终将值存储到attribute中 3.2.2 解析HTTP响应解析响应跟解析申请相似，也是逐帧解析，将解析出的属性存储到attribute中。此外，需思考报文非法场景（状态码非数值），确保解析失常完结。 退出咱们关注咱们

这里是在本科毕业ing的准研究生，将来实验室是做云边协同钻研的。保研后分割了我导，我导让我先钻研钻研eBPF，能够用在云原生可观测畛域。于是看到了开源我的项目kindling，并上手尝试了一番。因为这是第一次接触云原生概念、第一次接触可观测工具，在装置部署时遇到过一些问题。写下这篇踩坑汇合心愿对大家上手kindling有帮忙~ 问题一 第一次看installation的时候，第一句通知我有些ebpf相干的内核配置要关上。我过后在网上找了很久没有找到批改内核配置的办法，大多数材料通知我要下载一个新的内核源码另外编译。 Solution:起初晓得了在部署配置执行脚本的时候就会主动帮我检测的。个别内核是默认关上的。如果没有找到CONFIG_BPF=y的选项，兴许是版本较低，问题不大，先跑了装置脚本再说。 kindling反对对较低版本的内核采纳预编译内核模块的形式。对linux版本的反对参看kindling的Requirements。 问题二执行完脚本后查看，有个在node51上的kindling-agent pod 产生crashbackoff。FailedPostStartHook？容器刚创立立即进行？ **排错步骤：#先describe一下。kubectl describe po kindling-agent-xxx#而后执行命令看具体日志：kubectl logs --tail=100 -f kindling-agent-xxxx -c kindling-probe -n kindling** Solution: step1： 那么要搞清楚kindling简略架构。 kindling-probe从内核中采集事件，并为事件补充过程、容器、网络等信息，最初依照预约义的事件格局通过Unix domain socket将事件发送到kindling-collector。kindling-collector接管事件并对事件做业务解决，生成预期的指标和单次申请数据，最终将数据输入到内部存储中做长久化。 能够看出，collector是依赖probe的。问题不在于打出日志的kindling-collector，而在于没有打出日志的kindling-probe。probe没有起来，collector才会报错在排查Pod为什么创立失败时，首先看 Pod 容器退出状态码是十分有用的，能疾速的定位问题起因。 step2： 再来查看probe。Error: Precompiled module at /opt/.kindling/ is not found 原来是预编译的模块在 /opt/.kindling/目录下没有找到，导致probe起不来。须要到这个Node上，手动下载内核头文件并从新编译模块。编译完打成镜像，替换对应node上的镜像为本人的新版本。 参见FAQ的第一个问题http://www.kindling.space:332... 兴许会找不到对应的rpm包，FAQ中提供了一些下载内核头文件的安装包。 1、ml是支流反对版本，lt是长期反对版本尽量不要用ml版本。因为不同人编译的抉择的选项不同，咱们要无ml版本(尽管我最初没找到4.19的lt版本，还是用了ml胜利了)2、查看已装置的内核版本的命令：uname -a ; rpm -qa kernel请增加图片形容 问题三grafana插件部署。报错 Solution:发现是复制文本不全，呈现缩进谬误。当初的装置脚本曾经把yaml文件的细节封装了，不会在这里遇到问题。不过这是常见谬误，能够留神一下。 问题四grafana插件部署，报上面的错 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 26s (x3 over 87s) default-scheduler 0/3 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 2 pod has unbound immediate PersistentVolumeClaims.Solution:给master节点容忍能力，让它能够调度。https://blog.frognew.com/2018... ...