kindling
kindling copied to clipboard
KindlingProject
Featutre request: dynamic turn on / off probes in runtime.
Is your feature request related to a problem? Please describe. 实现运行时 probe 的启停。
Describe the solution you'd like probe 开关目前只能在kindling启动时初始化。能否实现接口能让用户在运行时开启或者关闭一些 probe.
Describe alternatives you've considered kernel modules 和 bpf probe 可能都需要考虑。
能否具体描述一下使用场景？比如现在已经遇到了什么问题，希望关闭哪些probe？现在是默认关闭了trace-profiling的功能，只开启了网络协议分析。
这是我们的一个测试环境： 宿主机信息 主机信息：虚拟机 CPU: 4C 内存：8G CPU规格：Intel(R) Xeon(R) CPU E5-2678 v3 @ 2.50GHz 内核版本：5.15.0-43-generic 5.15.0-52-generic 4节点；
在测试环境中使用了 nginx / webench 进行压测。发现在 14k 左右的 QPS 下 kindling 的资源开销很大0.9c / 300M (只记录了 userspace 端的应用开销，没有记录 Probe 开销) 我们进行了另外的压测，关闭了其他指标 kprobe-tcp_close、kprobe-tcp_rcv_established、kprobe-tcp_drop、kprobe-tcp_retransmit_skb、syscall_exit-connect、kretprobe-tcp_connect、kprobe-tcp_set_state； 只保留 kindling 基本的网络协议分析的功能需要的 probe。但是这种情况 14k 左右的 QPS 下 kindling 的资源开销也在 0.8c / 300M 左右。
我们希望能在负载较高的节点通过动态关闭一些 probe （或者说关闭当前的资源开销较大网络协议功能，保留资源开销较小的其他功能呢） 来控制 kindling 的资源运行开销控制在 0.5c 以下。 在出现相关的生产问题时 / 节点资源负载小时 能在运行时开启 kindling 相关功能进行排查。
Describe alternatives you've considered 另外我注意到 falco 有在做支持 probe 运行时的动态关闭。https://github.com/falcosecurity/libs/commit/287f867b0cc1670317d796c2e6bb799519484191#diff-12833abd4271488260dae0ba178c6ad3f0bc63642f793a20b06ab4eb10d02cf9R1651 falco 的多数据源 plugin 系统也是一个比较不错的特性 https://github.com/falcosecurity/plugins。 不知道 kindling 后面有没有对应的 roadmap ?
背景了解了，不过据我了解，现在的问题是即使只开启HTTP协议的分析，大概资源也会用这么多，达不到0.5C的要求。这里也没办法单独关一部分probe。要解决这个问题需要对用户态代码进一步做性能优化，优化方向包括：
- 内存复用，减少内存申请（效果最佳）
- DataGroup结构优化，减少组件间传递拷贝
- 协议解析流程优化，减少无用判断
这些是已知的可优化方向，是长期目标（至少几个月时间的目标），最近社区几位核心开发者都比较忙，欢迎其他开发者贡献。
关于falco的改动，我觉得挺有用的（虽然不能解决现在的性能问题），Kindling应该定时与上游做一些功能的同步，也许这个功能可以与事件订阅联动。 @jundizhou @sanyangji 你们怎么看？
我们始终将1w tps 使用1个核的cpu作为kindling的底线，随着功能的丰富，特别是trace-profiling的出现，这个底线也不断被挑战。我们也始终进行着性能优化工作，但是0.5c支持1wtps确实不是我们的短期目标。上文提到的关闭probe来提高性能，关闭k probe后，只剩下了系统调用基础功能情况下使用了0.8c,目前看来这已经是kindling探针现阶段的极限性能了，动态启停probe也无法缩小功能集合了，我认为在大部分场景下这个性能是可接受。因为大部分情况下，当你压测到了1w4tps，常规的应用已经达到5-7核的cpu了，可推算得探针使用这个机器资源的15%，我认为是可接受的。当然代码是有一定的可优化空间的，但我认为这不是现阶段的重点了
关闭k probe后，只剩下了系统调用基础功能情况下使用了0.8c,目前看来这已经是kindling探针现阶段的极限性能了
我们也尝试过关闭 read、write 这样的系统调用，资源开销是有明显下降，当然这是以牺牲功能为前提的。
我认为这里的问题主要问题是实现，“负载较高时动态关闭一些资源开销大的功能”。
场景 1： 业务负载较高 10k qps 左右， 能通过动态配置让 kindling 只提供性能开销小的 metrics 信息例如 tcp retransmit 等。 场景 2: 业务负载较低 几百 qps 左右， 能通过动态配置 kindling 来提供额外能力，例如 网络协议分析、trace-profiling 等，由于在线业务负载小 kindling 开销也不会很大。
默认的启动配置不能同时满足场景1和2的资源开销需求。能否支持用户根据当前在线业务的负载情况动态去修改 kindling 提供的能力，能让其运行在一个较小的资源开销内不影响在线业务？ 当然动态启停 probe 是我想到的一个比较直观的方法。
优化代码是一个方面；kindling 资源开销大小和 kindling挂载的 porbe 数以及节点其他任务的负载成正比。我认为这里提到的动态去加载、卸载 probe 可能也是一个优化资源开销的方面。
关闭k probe后，只剩下了系统调用基础功能情况下使用了0.8c,目前看来这已经是kindling探针现阶段的极限性能了
我们也尝试过关闭 read、write 这样的系统调用，资源开销是有明显下降，当然这是以牺牲功能为前提的。
我认为这里的问题主要问题是实现，“负载较高时动态关闭一些资源开销大的功能”。
场景 1： 业务负载较高 10k qps 左右， 能通过动态配置让 kindling 只提供性能开销小的 metrics 信息例如 tcp retransmit 等。 场景 2: 业务负载较低 几百 qps 左右， 能通过动态配置 kindling 来提供额外能力，例如 网络协议分析、trace-profiling 等，由于在线业务负载小 kindling 开销也不会很大。
默认的启动配置不能同时满足场景1和2的资源开销需求。能否支持用户根据当前在线业务的负载情况动态去修改 kindling 提供的能力，能让其运行在一个较小的资源开销内不影响在线业务？ 当然动态启停 probe 是我想到的一个比较直观的方法。
优化代码是一个方面；kindling 资源开销大小和 kindling挂载的 porbe 数以及节点其他任务的负载成正比。我认为这里提到的动态去加载、卸载 probe 可能也是一个优化资源开销的方面。
我认为write\read这些系统调用是kindling现阶段的基石，没有这些系统调用分析的内容，kindling会变得非常薄弱。抛开trace-profiling来看，失去read/write后 kindling只剩下了4-5个4层指标，就变得可有可无了。
我理解你说的是“功能降级”思路，这个思路一般是通过临时关闭某些次要或复杂的功能，应对系统负荷过高或发生故障的情况，减少系统崩溃的风险，同时保证核心功能的稳定运行。
所以实际要讨论的是“核心功能”是什么？
- 从业务系统角度看，业务本身是核心功能，由于Kindling是一种监控工具，在系统高负荷时，Kindling整体都可以被关闭掉；
- 从Kindling本身的角度看，我们之前认为其中“网络协议分析和统计”是核心功能，如果为了降低Kindling的资源开销而关闭了核心功能，并不符合我们对Kindling的定位。所以我会倾向于持续优化代码来提高性能，尽量降低资源消耗来保证核心功能的运行，而其他部分可以作为功能降级的模块。
你的回复提醒了我，Kindling似乎也不必把“协议分析和请求统计”看成是核心功能，本质上核心功能是“收集各类指标”（当然Kindling还有Trace-profiling这个核心功能，这个部分已经可以动态启停），每类指标都是一个插件，用户可以自由选择启用哪个部分的功能。
我觉得你说的动态启停probe功能是有必要的，只是短期确实没有时间实现，所以这个功能短期还是需要社区来贡献。
关于与上游同步的问题，目前是基于需求来决定，如果有相同的需求就会合并上游代码。例如动态启停probe这个需求，就可以通过合并上游代码来实现，但合并的前提是整体设计好方案，在方案没有确定下来就直接同步上游代码可能会引入不确定的问题。