关于ebpf:基于eBPF的云原生可观测性开源工具Kindling之Kindlingagent-性能测试评估

56次阅读

共计 2043 个字符,预计需要花费 6 分钟才能阅读完成。

背景

Kindling-agent 是基于 eBPF 的云原生可观测性开源工具 Kindling 中采集端的组件,可能通过采集和剖析内核事件,获取运行于同一宿主机上的其余服务的业务、网络等指标。其工作模式是在主机上以独立过程的形式收集所需数据,所以只须要咱们在利用所在主机部署 Kindling-agent 即可启动相应能力,随后能够通过 prometheus 和 grafana 套件对不同机器上探针采集的数据进行整合剖析和查看,当然也能够用其余工具获取数据并进行剖析展现。只管 Kindling-agent 基于 eBPF 的形式进行的监控形式缩小了对被监控利用的侵入,但始终还是和用户利用共享同一台宿主机的 CPU、内存、磁盘、网络等资源。这使得所有想要应用 Kindling-agent 的用户都想晓得该工具在实在环境中的性能体现以及预期资源应用状况。Kindling 我的项目进行了一系列的测试来验证该采集工具的性能体现,这些测试反馈了 Kindling-agent 在不同压力下良好的性能体现和可靠性。

测试指标

  1. 测验高负载 (5000 TPS) 场景下,Kindling-agent 对利用的性能影响和 agent 自身的资源应用状况。
  2. 测验惯例负载 (1000 TPS) 场景下,Kindling-agent 对利用的性能影响和 agent 自身的资源应用状况。

测试环境

内核版本3.10.0-1160.53.1
CPUIntel(R) Xeon(R) Platinum 8269CY CPU @ 2.50GHz,8C
内存16G

Jmeter 和 Kindling-agent 以 K8S 工作负载的形式进行部署,测试利用和 Jmeter 别离运行在两台 CentOS7(fedora)上。

后果阐明

  1. 基线指测试利用在无探针装置时的进行压力测试取得的指标,包含以下信息:
    • machine-cpu: 机器总 CPU 应用总体百分比
    • machine-mem: 机器总内存应用总体百分比
    • application-cpu: 测试利用 CPU 应用核数
    • application-memory: 测试利用内存应用
    • application-latency: 测试利用申请提早
    • application-tps:测试利用每秒事务数
  2. 装置探针后的测试利用在压力测试时的性能指标。
  3. 探针本身的性能损耗,包含 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 能够在较低的资源开销下反对轻量化部署,且易于治理;可能深入分析申请到协定栈在内核执行状况;可能提供语言无关,利用无侵入的监控体验,为您的利用带来新一代的可观测能力。
测试原始数据详见:原始数据

对云原生感兴趣的小伙伴欢送分割咱们:
退出咱们

关注咱们

正文完
 0