公有云网络问题，是一个老生常谈的事情了。今天主要简单说明下，在内网环境下去分析 & 定位这个问题。也并不是一开始就需要 eBPF 加持的，可以从简单的基础工具到监控配合去相关比较快速的定位问题，解决问题。下面会从发现问题到一步步配合使用 Or 开发一些简单的东西去解决问题的大致思路。

常见的网络相关问题

• 业务负载不均衡：业务系统会越发的复杂，不可能单个服务承接所有流量，一定会逐步迭代为一组服务承接流量，那我们是可以先用一些负载均衡组件去解决这个问题（不推荐一上来就喊，我要自研，图啥呢？），可以使用 HaProxy、Nginx 配合公有云的弹性能力去解决问题。伴随着业务的发展慢慢的当全站使用 K8s 的时候，还会遇到 Kube-Proxy 存在负载不均衡的问题，这个时候就可以应入 Envoy 到最终上线 Istio 去解决问题，做到内部服务的负载均衡（当然服务的健康检查 & 优雅停止需要考虑下）。配合边缘公有云 LB 做入流量控制，到 Kong 这种非常自动化的网关来解决业务整个边缘路由的分流能力。至此 xLB + Kong/Openresty/Apisix/Envoy + Istio(Evnoy) 基本上已经到了天花板了。（应该还有更优的）
• 网络异常抖动：日常会发生抖动的情况大致有几种情况吧。服务间异常、交换机过载、存储系统异常、业务系统 Bug，如上问题都需要专业的同学去帮助解决，并不能也不是每次都是网工的锅是吧。
• 网络延时增大：抛开业务系统问题，Slow Query、Big Key、Hot Key、消费生产（消息队列）延时等问题的话。那只能朝着网络层面去找问题了。（你想，交换机里面也有 CPU）举一个例子，家里 Wifi 为什么没啥人用也会卡，有一个东西叫信道，就好比虽然有很多信道但是呢流量都在一个信道里面跑（1个人干活，一群人看）能不卡吗？（应该能解的，这个就不懂了，不懂不捣乱）

如何定位

Istio

• Istio 监控指标里面其实已经可以发现服务链路之间的调用的情况了，就是会发现为什么有些快有些慢呢，在排除 xDS（服务发现、路由下发等，Envoy API 与 Pilot 交互） 的问题后（其实没几家公司可以触发 Istio 的 Bug 的），依然慢的莫名其妙。

Ping

• 这个是一个好东西哦，简单看看绝对富裕了。闲来无事基于 ping_exporter 加了一个 RESTful API，这样想 Ping 哪里 Ping 哪里，如果需要 K8s 里面互相 Ping 的话，其实只要依靠 K8s API 做自发现 Node 互 Ping 就能一目了然的发现很多问题了（原来网络真的很糟糕）

eBPF

• eBPF(extended Berkeley Packet Filter) 是一种可以在 Linux 内核中运行用户编写的程序，而不需要修改内核代码或加载内核模块的技术。简单说，eBPF 让 Linux 内核变得可编程化了。eBPF 程序是一个事件驱动模型。Linux 内核提供了各种 hook point，比如 system calls, function entry/exit, kernel tracepoints, network events 等。eBPF 程序通过实现想要关注的 hook point 的 callback，并把这些 callback 注册到相应的 hook point 来完成“内核编程”。

  
  
  Linux bcc/BPF Tracing Tools

• bcc 是一个基于 eBPF 的工具包，内部包装了 LLVM。你可以用 C 语言 + Python、Lua 等高级语言编写 eBPF 程序，同时还提供了不少有用的工具。BCC是一个用于跟踪内核和操作程序的工具集，其软件包中包含了一些有用的工具和例子，它扩展了BPF(Berkeley Packet Filters)，通常被称为eBPF , 在Linux3.15中首次引入，但大多数BCC的功能需要Libux4.1及以上版本。（可以话时间研究下下的，基础功能 & BPF 代码里面多有）

• bpftrace 是一门基于 eBPF 的高级追踪语言，可以方便快捷地编写 Linux 追踪程序。

• 工作原理：eBPF 通过 C 语言自由扩展（这些扩展通过 LLVM 转换为 BPF 字节码后，加载到内核中执行。从图中你可以看到，eBPF 的执行需要三步：从用户跟踪程序生成 BPF 字节码；加载到内核中运行；向用户空间输出结果。

  
  
  BPF for Tracing

• 实际上，在 eBPF 执行过程中，编译、加载还有 maps 等操作，对所有的跟踪程序来说都是通用的。把这些过程通过 Python 抽象起来，也就诞生了 BCC（BPF Compiler Collection）。

• BCC 把 eBPF 中的各种事件源（比如 kprobe、uprobe、tracepoint 等）和数据操作（称为 Maps），也都转换成了 Python 接口（也支持 lua）。这样，使用 BCC 进行动态追踪时，编写简单的脚本就可以了。

• 不过要注意，因为需要跟内核中的数据结构交互，真正核心的事件处理逻辑，还是需要我们用 C 语言来编写。

cloudflare/ebpf_exporter

• Prometheus exporter for custom eBPF metrics. 非常棒的一个项目，在与 K8s 结合的时候，以 DaemonSet 的形式运行在集群中，可借鉴 kube-ebpf-exporter。
• 依据 Bcc Tools tcpconnlat，配合 ebpf_exporter 的改写如下（ebpf_exporter 例子中没有网络延时相关的）

programs:
  # See:
  # * https://github.com/iovisor/bcc/blob/master/tools/tcpconnect.py
  # * https://github.com/iovisor/bcc/blob/master/tools/tcpconnlat_example.txt
  - name: tcpconnlat
    metrics:
      counters:
        - name: tcpconnlat_ipv4
          help: tcp4 connection latency(ms)
          table: ipv4_events
          labels:
            - name: pid
              size: 4
              decoders:
                - name: uint
            - name: sst_addr
              size: 4
              decoders:
                - name: inet_ip
            - name: dst_addr
              size: 4
              decoders:
                - name: inet_ip
            - name: lst_port
              size: 2
              decoders:
                - name: uint
            - name: dst_port
              size: 2
              decoders:
                - name: uint
            - name: proc_name
              size: 16
              decoders:
                - name: string
    kprobes:
      tcp_rcv_state_process: trace_tcp_rcv_state_process
      tcp_v4_connect: trace_connect
    code: |
      #include <uapi/linux/ptrace.h>
      #include <net/sock.h>
      #include <net/tcp_states.h>
      #include <bcc/proto.h>

      struct info_t {
          u64 ts;
          u32 pid;
          char task[TASK_COMM_LEN];
      };
      BPF_HASH(start, struct sock *, struct info_t);

      // separate data structs for ipv4
      struct ipv4_data_t {
          u32 pid;
          u32 saddr;
          u32 daddr;
          u16 lport;
          u16 dport;
          char task[TASK_COMM_LEN];
      };
      BPF_HASH(ipv4_events, struct ipv4_data_t);

      int trace_connect(struct pt_regs *ctx, struct sock *sk)
      {
          u32 pid = bpf_get_current_pid_tgid();
          struct info_t info = {.pid = pid};
          info.ts = bpf_ktime_get_ns();
          bpf_get_current_comm(&info.task, sizeof(info.task));
          start.update(&sk, &info);
          return 0;
      };

      // See tcp_v4_do_rcv(). So TCP_ESTBALISHED and TCP_LISTEN
      // are fast path and processed elsewhere, and leftovers are processed by
      // tcp_rcv_state_process(). We can trace this for handshake completion.
      // This should all be switched to static tracepoints when available.
      int trace_tcp_rcv_state_process(struct pt_regs *ctx, struct sock *skp)
      {
          // will be in TCP_SYN_SENT for handshake
          if (skp->__sk_common.skc_state != TCP_SYN_SENT)
              return 0;
          // check start and calculate delta
          struct info_t *infop = start.lookup(&skp);
          if (infop == 0) {
              return 0;   // missed entry or filtered
          }
          u64 ts = infop->ts;
          u64 now = bpf_ktime_get_ns();
          u64 delta_us = (now - ts) / 1000ul;
          u64 delta_ms = delta_us / 1000;
      #ifdef MIN_LATENCY
          if ( delta_us < DURATION_US ) {
              return 0; // connect latency is below latency filter minimum
          }
      #endif

          // pull in details
          u16 family = 0, lport = 0, dport = 0;
          family = skp->__sk_common.skc_family;
          lport = skp->__sk_common.skc_num;
          dport = skp->__sk_common.skc_dport;

          // emit to appropriate data path
          if (family == AF_INET) {
              struct ipv4_data_t data4 = {.pid = infop->pid};
              data4.saddr = skp->__sk_common.skc_rcv_saddr;
              data4.daddr = skp->__sk_common.skc_daddr;
              data4.lport = lport;
              data4.dport = ntohs(dport);
              __builtin_memcpy(&data4.task, infop->task, sizeof(data4.task));
              ipv4_events.increment(data4, delta_ms);
          }
          start.delete(&skp);
          return 0;
      }

基于上面一轮干下来，基本上哪里慢，为什么慢，怎么慢也就差不多定位了。剩下么，该干嘛干嘛。记得调用链还是非常有用的哦，配合网络监测 + 调用链，问题自然而然的就暴露啦（当然调用链接入姿势是另外一个问题啦）

最后推荐几本书吧，BPF之巅：洞悉Linux系统和应用性能 & Linux内核观测技术BPF（狄老出品）