[特别任务]Kuscia End-to-End 网络监控指标采集

[Candicepan]

此 ISSUE 为 隐语开源共建计划（SecretFlow Open Source Contribution Plan，简称 SF OSCP）第二期任务 ISSUE，欢迎社区开发者参与共建～ 若有感兴趣想要认领的任务，但还未报名，辛苦先完成报名进行哈～

任务介绍

• 任务名称：Kuscia End-to-End网络监控指标采集
• 技术方向：监控报警、可观测性
• 任务难度：挑战🌟🌟🌟

背景

在隐私计算场景中，不同节点通常是跨域部署的，我们希望能够监测两个节点之间端到端的网络质量。 为了描述清楚问题，假设有三个机构分别部署了三个自治节点 alice、bob、joke；alice 与 bob、alice 与 joke均有联合计算项目。 在 alice 这一侧，需要分别统计 alice 与 bob、alice 与 joke 的之间的网络链路的带宽、健康度指标。由于节点的入口和出口流量都会经过 Envoy，因此我们将需求转换为统计 alice 侧的 Envoy 与 bob 侧的 Envoy 之间的 tcp connections 的健康度、传输速率。 另一方面，考虑到入口流量通常经由机构网关转发到Envoy，即Envoy作为Server端时，Envoy看到的tcp链接的client side并非Remote节点的出口ip而是本节点所属机构的网关。因此我们只统计Envoy作为Client端(主动打开)的tcp链接上的指标。

How

1. 了解 Envoy
2. 如何知道 local 节点是哪个节点？ 在节点容器内执行curl 127.0.0.1:1054，可以看到例如下面的返回值，从而解析出namespace，即节点的DomainID。 {"namespace":"alice"}
3. 如何知道 local 节点连接了哪些节点？节点的入口地址是什么？ curl 127.0.0.1:10000/config_dump从中解析出cluster_name前缀匹配${localDomainID}-to-${RemoteDomainID}-Protocol的的cluster。如下图所示，其中endpoints[i].lb_endpoints中address和port即为Remote节点域名和端口，域名可能对应多个ip。
4. 需要统计哪些指标？ 统计包括但不限于重传超时 rto、重传率 retrans、delivery_rate、send_bps、recv_bps、total_conenctions、重传率(超过阈值)异常的Conenctions占比。 以及envoy statistics提供的upstream_rq_rx_reset、upstream_rq_tx_reset、rq_pending_open、rq_open等。 有些指标可能需要利用两次统计的差值来计算。
5. 如何获取local节点与remote节点之间的tcp connections statistics? 参考socket statistics，注意需要按照3中的Destination Address将connection statistics分组。 以及envoy statistics，包含tcp_statistics、tls_statistics、circuit-breakers-statistics等，已经是按cluster聚合过的，需要评估下仅envoy statistics是否覆盖socket statistics能够提供的信息。

详细要求

• 功能性：
  • 要求控制采集脚本本身的计算资源使用率，分别给出【5S、15S、30S】采集周期、[1W、5W、10W、20W、100W】Active conenctions下的Memory、CPU、NetIO的使用量的趋势图。
  • 支持采集指标项可配置，以便于增删Envoy或采集工具已经支持的指标
  • 考虑到中心化模式下，指标会从Lite节点推动到Master，需要控制推送的指标数据量，我们希望推送的指标已经是在本地聚合过后的指标；若采用socket statistics方案，需要支持sum、avg、max、min、rate等聚合函数，并支持可配置聚合函数。
  • 你可以直接基于prometheus提供的client来实现按照prometheus的格式来暴露指标。
  • 产出文档，包括脚本使用文档；指标说明文档，包括含义和使用说明。
• 代码规范：https://github.com/uber-go/guide/blob/master/style.md
• 提交说明：
  • 关联该 ISSUE 并先准备详细的设计方案文档，包括具体指标项和方案，请在 ISSUE 下评论提交方案，经过确认后进行开发。
  • 功能开发完成后，关联该 ISSUE 并提交代码至 https://github.com/secretflow/kuscia
  • 建议使用 go 或 python 语言开发，不建议使用 shell 语言开发。

能力要求

• 熟悉 Kuscia、Envoy。
• 熟悉 golang或python。

[Vancasola]

Vancasola Give it to me

[Vancasola]

Kuscia End-to-End 网络监控指标采集

概述：获取 TCP 统计信息，获取CPU、Memory usage、Net I/O 的系统资源信息。目前已初步完成go程序代码，未集成到kuscia中。

1. 利用 envoy 获取统计信息，指标包括 envoy states中TCP、TLS、circuit-breakers-statistics的内容。

   • 识别 localDomainID 在go程序向 127.0.0.1:1054 发送 http 请求，解析出 localDomainID

   • 在go程序向 envoy的stats发送http请求获取.json的列表，找到localDomainID下endpoints[i].lb_endpoints中address和port，在.json列表中选择需要收集的指标：

2. 利用 ss 获取统计信息，envoy未能完全覆盖ss的统计信息（例如, rto、delivery_rate等）。通过在go程序通过命令调用ss，过滤出需要收集的指标。指标包括

指标	含义	使用说明
rto	tcp 重传超时值	直接通过配置文件获取
retrans	重传发生次数	直接通过配置文件获取
delivery_rate	即 cwnd/rtt, cwnd:congestion window size, rtt: rtt is the average round trip time	直接通过配置文件获取
send_bps	每秒发送的bit数	直接通过配置文件获取
recv_bps	每秒收到的bit数	直接通过配置文件获取
total_conenctions	总连接数	直接通过配置文件获取

2. 获取系统资源信息：CPU使用量、Memory使用量、网络I/O。

• CPU: 利用Linux 系统工具 mpstat 获取 ，在go程序通过命令调用mpstat，过滤出需要收集的指标

指标	含义
User	%user: Percentage of CPU time spent by user processes
Nice	%nice: Percentage of CPU time spent by user processes with adjusted "nice" value
System	%system: Percentage of CPU time spent by the kernel
Iowait	%iowait: Percentage of time the CPU is idle but waiting for I/O operations to complete
IRQ	%irq: Percentage of CPU time spent servicing hardware interrupts
SoftIRQ	%softirq: Percentage of CPU time spent servicing software interrupts
Steal	%steal: Percentage of CPU time in a virtualized environment, stolen by other virtual machines
Guest	%guest: Percentage of CPU time spent running guest operating systems
Idle	%idle: Percentage of CPU time that is idle

• Memory: 利用Go自带runtime.MemStats 获取，收集Total Memory、Allocated Memory、System Memory Usage、Allocated Times、Memory Free Times。

• 功能性对应的设计方案

  • 要求控制采集脚本本身的计算资源使用率，分别给出【5S、15S、30S】采集周期、[1W、5W、10W、20W、100W】Active conenctions下的Memory、CPU、NetIO的使用量的趋势图：每隔【5S、15S、30S】获取一次指标，用iperf3发tcp包，go-echarts画出使用量趋势图。

  • 支持采集指标项可配置，以便于增删Envoy或采集工具已经支持的指标：通过修改配置文件中需要采集的指标以支持采集指标项可配置。

  • 考虑到中心化模式下，指标会从Lite节点推动到Master，需要控制推送的指标数据量，我们希望推送的指标已经是在本地聚合过后的指标；若采用socket statistics方案，需要支持sum、avg、max、min、rate等聚合函数，并支持可配置聚合函数：获取socket信息后，这些信息作为聚合函数的输入，输出结合结果。

  • 你可以直接基于prometheus提供的client来实现按照prometheus的格式来暴露指标：导出prometheus格式的指标。

• 问题

  • 【控制采集脚本本身的计算资源使用率，分别给出不同采集周期、下的资源使用量的趋势图】：是否需要集成到kuscia？还是只是实验性的功能，用于观察采集脚本本身的计算资源使用率？）

  • 【考虑到入口流量通常经由机构网关转发到Envoy，即Envoy作为Server端时，Envoy看到的tcp链接的client side并非Remote节点的出口ip而是本节点所属机构的网关】：这条的意思是不是这样：remote结点的数据包发送到机构的网关之后，由于机构网关的NAT，docker能看到的只是机构网关的IP？我们能否主动获取机构网关的的ip信息，以收集端到端的网络信息？

[Eiji911]

关于CPU、Memory、IOWAIT的统计，我们可以另一个ISSUE，因为这些任务容器也需要采集的。本issue聚焦在端到端网络监控。 问题1：期望测试脚本可以提交到Kuscia，连接数和采集周期可以是脚本参数。 问题2：不是的。Alice和BOB通信，在Alice侧，Alice做为Server端时，看到的ClientIP可能是Alice机构的网关的IP，而不是BOB的出口IP。

[Vancasola]

关于CPU、Memory、IOWAIT的统计，我们可以另一个ISSUE，因为这些任务容器也需要采集的。本issue聚焦在端到端网络监控。 问题1：期望测试脚本可以提交到Kuscia，连接数和采集周期可以是脚本参数。 问题2：不是的。Alice和BOB通信，在Alice侧，Alice做为Server端时，看到的ClientIP可能是Alice机构的网关的IP，而不是BOB的出口IP。

1. 好的，系统参数的统计先不加入，主要放在针对连接数和采集周期的测试脚本中。
2. “Alice 作为 Server 端时，看到的 ClientIP 可能是 Alice 机构的网关的 IP”：请问产生这样现象的原因主要是什么呢？这样的情况下，我们通常要如何获取udp包丢包率这样的指标？
3. 其他部分是否符合要求？如果可以的话，我就继续完成开发了哈。

[Eiji911]

关于CPU、Memory、IOWAIT的统计，我们可以另一个ISSUE，因为这些任务容器也需要采集的。本issue聚焦在端到端网络监控。 问题1：期望测试脚本可以提交到Kuscia，连接数和采集周期可以是脚本参数。 问题2：不是的。Alice和BOB通信，在Alice侧，Alice做为Server端时，看到的ClientIP可能是Alice机构的网关的IP，而不是BOB的出口IP。

1. 好的，系统参数的统计先不加入，主要放在针对连接数和采集周期的测试脚本中。
2. “Alice 作为 Server 端时，看到的 ClientIP 可能是 Alice 机构的网关的 IP”：请问产生这样现象的原因主要是什么呢？这样的情况下，我们通常要如何获取udp包丢包率这样的指标？
3. 其他部分是否符合要求？如果可以的话，我就继续完成开发了哈。

2.因为机构的入口流量是从网关进来的呀，网关可能是七层代理、四层代理，转发后源地址就从机构地址变成网关地址了。

[Vancasola]

好的！目前的进展如下，功能已基本实现：

1. 统计和参与方相关的集群网络信息，包括：

   • 使用ss获取：使用ss收集tcp流的基础测量信息, 即 rto、rtt、delivery_rate、bytes_send、min_rtt、bytes_received。通过对基础测量信息聚合（sum、rate、avg等），获取指标retrans，total_conenctions、重传率(超过阈值)异常。
   • 使用envoy获取：包括集群指标，如General、Circuit breakers statistics、Load balancer statistics (问题：是否需要收集TCP statistics指标？使用 curl http://127.0.0.1:10000/stats, 未发现 TCP statistics 指标。是否需要支持更多指标？)

2. 测量指标可配置：

   • 给出yaml配置文件，配置需要采集的指标（如delivery_rate: true, bool 变量表示需要/不需要），指标类型（如 upstream_rq_retry_overflow: “Counter"，指标名称及汇聚到promethrus的指标类型）。

3. 测量开销分析：

   • 呈现形式：使用单独的分析脚本，获取系统资源使用量，生成分析趋势图。
   • 系统资源获取：利用mpstat（linux工具）获取CPU使用量、runtime（golang的package）获取内存使用量、ss（linux工具）收集本参与方的网络信息获取NetIO使用率。
   • 趋势图生成：使用 go-echarts绘制tcp主动连接数和计算资源使用量的使用趋势（但由于网络问题package不易下载成功）。

4. 测量信息汇聚：

   • 汇聚方法：使用 prometheus的client api将获取到的指标上报prometheus统一收集。

[Vancasola]

目前的进展如下：

1. 阅读了envoy的代码，了解两个指标的具体含义 1) upstream_rq_rx_reset应该指的是：被remote结点reset的连接的个数
   2) upstream_rq_tx_reset应该指的是：被local结点reset的连接的个数
2. 完成指标差值计算的开发
3. 完成按照Destination Address将connection statistics分组
4. 完成prometheus的配置，成功在prometheus重收集到自定义的指标
5. 系统性测试不同采集周期、Active conenctions、不同指标个数、不同参与方，在一个参与方中收集数据，本地聚合并上报prometheus，使用pid测量程序资源使用量10分钟 （1）（exp#1）【5S、15S、30S】采集周期：内存使用量保持在4MB上下轻微波动，CPU使用量保持在0.03%基本不变，十分钟内NetIO总量不超过1MB。 （2）（exp#2）【1W、5W、10W、20W、100W】Active conenctions：在两个参与方之间发送主动链接，每两秒构建10k个主动连接，在测量过程中逐渐构建 。【1W、5W、10W、20W、100W】个主动连接。内存使用量保持在4MB上下轻微波动（偶尔升至25MB左右），CPU使用量保持在0.03%基本不变，十分钟内NetIO总量呈阶梯状上升，400s内IO总量到达300MB左右(❓使用pid测量程序，构建主动连接的程序和测量程序分开，不知道为什么netIO使用量突然变高)。 （3）（exp#3）【10，50，117】个指标个数：内存使用量保持在4MB上下轻微波动，CPU使用量保持在0.03%基本不变，十分钟内NetIO总量不超过1MB。 （4）（exp#4）测量prometheus的资源使用：未画图，一个参与方开启或不开启监控程序，对prometheus的资源使用几乎无影响。

缺陷：1. 仍然无法成功配置出tcp_stats的指标信息