本文整理自民生银行总行科技部网络管理中心高级工程师冯晶晶在「清华大学 &云杉网络·可观测性技术论坛」的演讲实录。
民生银行通过 DeepFlow 构建了容器/云全路径网络观测能力、eBPF 零侵扰应用观测能力、应用函数监控能力、容器系统指标观测能力，并借助 WebAssembly 技术探索业务观测能力的建设。通过应用、系统、网络的全栈统一观测，民生银行的网络运维团队从网络监控时代迈向全栈主动观测时代，有效提升运维监控能力，提供更加全面、精准、有效、安全的监控服务能力，整体提升了故障定位和根因分析水平。本文讲述了民生银行的网络运维团队的工程师们在企业全面拥抱云原生的过程中，如何与云杉 DeepFlow 团队携手以 vTap 流量分发为起点，逐步改变传统网络运维思路，拥抱分布式流量采集方案，引入 eBPF 零侵扰应用追踪技术，并积极探索更多观测能力的发展历程。
1、前序
今天我们的主题是“以网络为中心的可观测性”，听到这个主题之后我特别激动和感慨，作为一名资深的网络运维工程师，多年来积累了大量网络相关的技术经验和心得体会，所以我现在站在台上，是以一种非常激动的心情向大家分享民生银行多年来从网络出发在云原生可观测性领域的建设实践。
在开始之前，我想对个人工作经历向大家做一个分享，刚才多次提到我是一名网络运维工程师，2006 年大学毕业以后就一直在银行做网络运维工作，在银行做网络运维其实是一个很艰难、压力很大的工作，为什么呢？因为银行对业务的连续性和稳定性要求极高，任何一次故障或业务中断就可能会直接带来用户的资金损失，无论是监管机构考核，还是部门内部要求，均是以安全生产为第一要务，在第一时间恢复安全生产是对我们运维工作的基本要求、底线要求，所以每一次故障处理的时候，运维人员都是背负极大的心理压力。
网络本质上就是用来为业务搭桥，当业务发生问题的时候，大家首先会怀疑网络有问题。当有业务中断时，大家的第一反应总是“网络哪里出问题了”、“现在业务中断了，抓紧查一下网络”、“是不是网络断了导致业务中断”；当有业务慢了的时候，大家总是说“查一下网络，是不是网络哪块抖动了，导致我们业务慢了”；当业务有异常的时候，大家总会说“我们这笔查询失败了，看看是不是网络哪块有问题”……所有的问题首先想到的都是网络问题，所以网络工程师总是背锅侠，不是在背锅中，就是在背锅的路上。
2、民生银行可观测平台概况
我们怎么去解决故障边界不清晰这样的问题呢，流量分析观测平台给我们提供了一个很好的方案，民生银行在 7、8 年前开始建设流量分析观测平台，在传统环境中，通过交换机旁路镜像采集网络流量的方式，将流量输送到流量汇聚平台，过滤、标记后输出到流量分析观测平台，实现全网络的流量视图监控。
通过流量分析观测平台，极大的缩短了故障定位的时间，同时我们把网络流量数据通过数据服务的方式输出给各运维平台，比如交易监控平台、安全运维平台、态势感知平台、大数据平台，提供网络流量数据服务。
在传统网络环境下我们很好的解决了这些问题，但随着云原生时代的到来，新的问题产生了。所有人都在讲，我们的业务要敏态交付，所有的应用向微服务化转变，云原生时代来了以后，对流量分析工作造成了什么困扰呢？大量的业务流量都在计算节点内部直接交换，不会进入到物理交换机，那我们怎么去分析容器内部、虚机内部的业务交互情况呢，那么当然感谢我们的 DeepFlow 产品，通过我们与云杉的深度合作，利用第一代的 vTap 技术，在每一个计算节点内分布式的采集容器内部、虚机内部的东西向流量，从而弥补虚拟网络监控的观测盲区，同时通过 eBPF 的零侵扰采集能力，把应用数据采集并输出来，实现了我们真正的从设备级运维，转变到基于用户、基于业务交互、基于用户体验、基于安全合规的场景化运维服务及数据服务能力。
3、建设历程
民生银行的可观测性平台是通过我们的逐步摸索，分为四个阶段一点一点丰富能力而稳步建设起来。
在第一阶段，我们基本沿着传统的流量采集、流量分发的技术思路，采用 vTap 流量分发方案，通过部署采集器在计算节点上把容器内部、虚拟机内部的流量采集并分发出来，解决容器网络东西向流量的监控需求，这就是这个平台建设初期的目标。
在第一阶段建设完成后，我们发现通过采集器采集出来的容器内部东西向流量特别大，在流量突发的情况下，对流量汇聚平台产生很大的压力，于是我们进入了发展的第二个阶段，采用分布式采集的理念，在采集器中直接进行分布式的数据采集计算，再把采集计算后的结构化数据上送到数据分析节点，解决了整个流量分析系统分发带宽瓶颈的问题，同时也实现了整个云原生容器网络的全路径的流量追踪能力。
到了第三个阶段，我们积极采用 eBPF 技术，通过底层 Linux 内核提供的 eBPF 编程能力捕获应用进程调用相关的数据，实现应用调用链的零侵扰追踪，将我们从网络观测能力提升到了应用的观测能力。
现在我们进入新的探索期，在这个时期我们将大力拓展 eBPF 的潜力，并积极引入 Prometheus、Skywalking、听云等数据，构建包含应用、网络、系统的统一观测平台数据底座，并延伸到业务观测。
初期——延续传统思路，vTap 打开云网黑盒
在传统的物理网络运维中，我们通过对交换机镜像操作以获取负载均衡、防火墙、核心/边界、接入/汇聚的南北向流量，并输送到统一流量汇聚平台，通过统一流量汇聚平台按需输出到网络监控，安全监控，交易监控，以及场景化数据服务。
到了云原生时代，我们在计算节点上部署 DeepFlow 采集器（实现 vTap 的能力），利用 Linux 的 cBPF 能力把容器内部，以及虚拟机内部的流量采集，通过 VxLAN 隧道把虚拟网络流量分发到统一流量汇聚平台，弥补虚拟化环境的流量监控空白。现在虚拟网络流量的分发能力已经完整覆盖了总行和分行的全部测试集群、生产集群。
发展——拥抱新理念，分布式采集增强网络观测
在传统物理网络环境中，交换机等位置的南北向流量其实并不是很大，相比较来说容器化以后所有计算节点内部的东西向流量规模则非常巨大，如果全部输送出来会对中间流量汇聚平台造成很大的压力，尤其是在流量突发时，会导致中间的流量采集层产生丢包，影响监控服务质量。
因此我们通过分布式采集的方式增强整体的网络观测能力，也就是在已部署采集器的流量分发能力基础上，在采集器内部采集到所有 Pod 或虚拟机的流量后直接分布式计算生成流量的指标、流量的日志、流量的追踪信息，然后把这些数据上送到云原生流量分析节点，通过分析节点统一分析、展示，可以提供的运维能力包括整个云原生网络的流量全景分析、流量监控、云网络故障诊断分析，同时在这个基础之上，还可以识别容器、虚拟机的扩缩容、资源迁移等变更事件。
在这个阶段我们落地的技术关键点包括：
分布式采集：在采集端分布式采集流量性能指标、流量日志，从而解决流量分发方案 CPU 需求瓶颈、物理网络带宽瓶颈；
全路径采集：在容器网络全路径实现数据采集，获取同一条 TCP 流从客户端 Pod 网卡到服务端网卡 4 个关键位置的性能数据；
全路径关联：对流量数据标记位置信息，对任意 TCP 流端到端路径实现全路径关联分析。
分布式采集给我们带来了什么收益呢？首先让我们从无到有的打开了容器和云的虚拟化网络的全路径，其次将容器内部的交互情况进行可视化分析、展示，然后把容器网络的流量性能数据通过自服务的方式提供给其他部门。
创新——落地新技术，eBPF 实现应用观测
实现了容器网络观测能力之后，我们又进入到了一个新的建设阶段，即创新阶段，在这个阶段我们的技术实现了从 cBPF 到 eBPF 的跳跃，我们的观测能力实现了从网络观测、系统观测向应用观测的跳跃。
我们通过 eBPF 技术，对应用程序零侵扰的方式从 Linux 内核捕获应用进程的函数调用，采集到应用进程的调用指标、调用日志、调用追踪数据，并上送到云原生可观测性分析节点，从而在原有的网络观测能力基础上，实现了包括应用全景分析、调用链追踪、调用回溯、进程 CPU 剖析等应用观测能力。
在这个阶段我们具体实现的能力包括：
eBPF 应用数据采集：通过 eBPF 技术，实现了对 Nginx、DNS、Redis 等无法插码位置的数据获取能力和观测能力；
观测延伸至进程：对应用调用（HTTP、DNS、MySQL…）的观测能力从虚拟网卡延伸到客户端、服务端进程；
零侵扰调用链追踪：无干扰、对入侵，对任意一次应用调用的全链路进行追踪。
通过这一阶段的能力建设，我们的数据不仅可以满足网络监控的需求，还能够输出到应用运维部门，应用运维人员可以通过链路追踪、指标数据第一时间观测到整个应用程序的运行情况。通过 eBPF 的能力消除了 Nginx、DNS、MySQL、Redis 等应用服务的监控盲区，并且将追踪能力由网络扩展到应用进程，实现应用、网络的统一追踪、统一观测，大幅度提高了问题定位和处置效率。
下面做个简单的过程对比，直观感受通过 eBPF 实现的应用观测能力如何提升运维的效率。大家可能都会在运维过程中遇到这样的问题，比如某个系统报障说某个服务突然响应慢了，在传统物理网络环境中，网络运维会通过流量分析平台人工分析应用的响应时延指标，定位到问题以后通过人工下载 Pcap 并读包的方式，追溯整个业务的交互情况，确定慢在哪一个环节。有了 eBPF 技术实现的调用链追踪以后，我们可以通过火焰图形式的调用链追踪，第一步输入服务名称，第二步找到慢响应，第三步点击调用链追踪，就自动把慢响应的整个调用链过程包括网卡、进程在视图上展示，并清晰的看出到底是哪个位置、哪个服务占用的时间比较长。
以下是 4 个通过 eBPF 实现的应用调用链追踪处理的经典案例供参考。
案例 1：业务运营系统 Web 服务慢响应根因锁定
在某一个业务排障中我们发现 Web 服务的某次服务响应时延长达 3.04 秒，使用基于 eBPF 的零侵扰应用调用链追踪能力，可以一键调阅这次 3.04 秒的应用调用的完整链条，并快速、直观的在火焰图中通过不同 span 的长度确定慢响应的根因 span 是后端的 oms-app Pod。
案例 2：零售综合服务系统慢响应根因锁定
在另外一个服务系统的排障中，我们发现部分响应时延接近 500ms，使用基于 eBPF 的零侵扰应用调用链追踪能力，一键调阅慢响应的完整调用链，从火焰图中可以快速发现，是由于后端的 acuiagwapp 服务响应慢导致。
相比较，使用传统的物理网络的定位模式，类似的问题需要多次抓包，然后逐跳分析，逐跳定位，逐个 IP 跟踪，才能定位到具体哪一个服务出现了问题，但是通过我们实现的调用链追踪能力，它可以直接可视化展示到具体的是哪一个服务、哪一个位置慢了。
案例 3：零售综合服务系统慢响应根因锁定
在案例 3 中是我们的决策分析平台客户端反馈出现了 HTTP 502 报错，但是客户端不知道到底是哪一个服务导致的一个 502 报错，通过我们的调用链追踪可以直接发现在服务端向 DNS Server 请求域名解析的时候，发生了 DNS 请求失败的异常，从而确定 DNS 服务的失败导致了此次 HTTP 服务的失败。
案例 4：支付通道整合系统容器 DNS 潜在隐患发现
在我们对支付通道整合系统进行运维观测时，发现大量 DNS 异常，对异常 DNS 调用一键点开调用链追踪，发现 tpp-pay-* 的 Pod 高频查询外部域名，并且由于 kube-dns 的 DNS 查询机制导致需要多次遍历解析内部域名，潜在影响交易性能，从而发现了容器集群中 DNS 配置一些可以优化提升的技术点，指导系统运维对容器 DNS 配置进行优化。
通过这些案例会发现，借助于 eBPF 实现的应用观测能力，我们的网络运维不仅具备了对网络问题的分析诊断能力，还具备了对应用的追踪诊断能力，具备了对 DNS、Nginx、Redis 等公共服务的追踪诊断能力。
探索——拓展新功能，构建数据底座
现在，我们进入到了可观测性系统建设的第四个阶段，即探索阶段。在这个阶段我们要做一个整体的观测数据底座，把尽可能多的数据（比如系统的 Prometheus 数据、应用的数据）融入到数据底座中，实现一个覆盖网络、应用、系统的统一观测平台，消除整个数据鸿沟，然后提高整体运维的效率。
同时我们计划对 eBPF 能力进行增强，实现应用进程的 CPU Perf 数据采集能力，深入剖析包括应用进程内部的内核函数、库函数、业务函数在内的 CPU 消耗分布。通过这个能力，我们的开发人员可以快速定位到有哪些函数执行效率比较低，并针对性提升或者优化程序代码。
4、总结
可观测性为我们带来了什么
可观测性到底给我们带来了什么收益呢？
在传统物理网络时代，我们通过网络流量分析平台，首先实现了全流量网络监控能力，其次实现了网络问题排障能力，最后为其他部门提供了交易流量数据服务、网络性能数据服务。到了云原生时代，我们通过 eBPF 的零侵扰可观测性，实现了主动的、全栈的观测能力。监控能力从网络的监控延伸到了系统监控、应用监控。数据服务能力除了面向网络人员的数据服务，增加了面向系统运维、应用运维，以及交易数据的输出。
我们从网络监控迈向了全栈、主动观测！
未来展望
下一步除了网络监控、系统监控、应用监控之外，我们还需要对业务进行监控，包括基于某笔交易流水号、某一类业务返回码、或者某个交易类型进行观测分析，所以我们计划通过 Wasm 技术对数据包和系统调用进行深度的解码分析，识别交易流水的情况，从而实现面向业务交易的全景监控和可观测性分析能力输出。
其次 eBPF 的强大能力为我们提供了很多新的运维观测能力，但它需要操作系统内核达到一定的版本，目前我们并不是所有的操作系统内核版本都支持 eBPF，由于 eBPF 给我们运维能力带来的巨大提升，在 2024 年我们会把所有的系统升级到新的内核版本，实现 eBPF 能力 100% 全覆盖。
另外在 2024 年的一个重要工作就是逐渐的融入 skywalking、听云的 APM 数据，然后做一个数据整合，在此基础上向开发部门提供更多的性能监控数据服务、业务监控数据服务的能力输出。
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论