云原生 NPM 数据采集和指标计算方法

在之前的一篇文章《云原生 NPM 与传统 NPM 的差异》中，我们了解到，传统 NPM 通过对物理设备的网络流量进行镜像，可以统计出网络层面的各种指标，也可以分析出网络延迟、带宽、重传等性能相关的指标。但是在实际工作中发现，网络层面的异常信息只是第一步，定位到产生异常的服务和原因，才能真正解决问题。本篇我们将讲述如何在云原生 NPM 中获取网络数据及相关网络指标的计算方法，以及如何将网络与具体应用进程进行关联，从而有助于快速地定位到可疑点。

1. 设计数据结构

该结构描述了一条 TCP 网络连接（本篇只关注 TCP 连接的应用）的主要信息，以该数据结构为基础，可以得到以应用/进程为视角的网络状态。除此之外，还可以增加其它字段，如错误报文数、重传报文数、乱序报文数，等等。

2. 获取字段值

• ClientIP, ServerIP, ClientPort, ServerPort

网络连接的四元组。从捕获的网络报文中可以解析出 IP 和 Port 信息。TCP 连接有三次握手的过程，第一次握手的时候由客户端发起 syn 请求，根据这个信息可以确定 Client。

• BytesReceived, BytesSent, PacketsReceived, PacketsSent

对服务端接收和发送的报文数、字节数进行统计。因为服务端接收就等于客户端发送，所以只需要统计一个方向的数据即可。

Rtt, Crt, Art, Ptt 这几个与时间相关的性能指标无法直接从网络报文中获取，需要通过一些算法计算，计算方法如下图所示：

对于旁路抓包，该图中隐含了一个重要信息：传统的 NPM 抓包位置要么靠近 client, 要么靠近 server。而云原生中的 NPM 要么位于 client，要么位于 server。这个抓包位置的变化，导致性能指标的计算方法略有区别。

• Rtt (round trip time)

计算时要区分该连接的目标地址是否为本机地址，如果是，意味着该连接是远端访问本地的一个服务，按照上图中 server 角色来计算：T(ack) – T(synack)；否则，按 client 角色来计算：T(synack) – T(syn)

• Crt (client response time)

按 client 角色来计算：T(http-get) – T(ack)

• Art (application response time)

按 server 角色来计算: T(http-response) – T(http-get)

• Ptt (payload transaction time)

按 client 或 server 角色都可以，数据传输的总时间。

剩下的两个字段，PID 和 UID，分别表示进程 ID 和用户 ID，这两个字段的值无法在网络包中获取，需要从操作系统中获取。下图是 linux 系统下运行 netstat -nopt 的输出。

从中可以看到一条连接的四元组信息，还有 PID 和进程名。 

到此，我们已经获取了本文开头结构中的所有字段的值。很多的应用日志框架都会默认输出 PID 信息，因此，通过 PID 还可以将网络指标与应用的日志进行关联，为相关的故障诊断提供更丰富的上下文信息。

3. 结尾

通过对网络数据的分析，可以计算出一些与网络质量相关的关键指标，用于定位与网络相关的故障根因。TCP 协议栈本身是一个比较复杂的系统，内部 11 种状态之间的转换与开销对于外部来说是一个完全的黑盒，但是对于定位问题有时却很关键。那如何观测这些关键信息呢？后续文章将介绍如何使用 eBPF 来采集内核中的网络指标，敬请期待。