Daxin Wang

I have successfully changed the font following @ImaCrea's instructions. Thank you! But I encountered a problem as leoplct at the beginning. When editing the file `_custom.scss` in step 7, I...

No special reason, just because the font file I got is `ttf`, and I have no experience with using fonts. By the way, I love the design of doks, thanks...

#291 is exactly the implementation of the feature you request. But I'm wondering why you request this feature. Would you explain the motivation?

请问这个需求的背景是什么？为什么需要动态开关probe？

请问是怎么确定这些数据是“误报”的？这些调用根本不存在还是存在调用但没有发生“建连失败”？

能否具体描述一下使用场景？比如现在已经遇到了什么问题，希望关闭哪些probe？现在是默认关闭了trace-profiling的功能，只开启了网络协议分析。

麻烦打开debug日志，然后把日志发出来，我看一下`tcpconnectanalyzer`中收到的数据情况。 方法为在配置文件中修改`observability.console_level`为`debug`，然后在`observability.debug_selector`增加`tcpconnectanalyzer`。再使用`kubectl logs`将日志重定向到文件中，然后把文件贴出来。 这个日志建议打印5分钟，这段时间内要出现过“误报的建连失败”指标。

背景了解了，不过据我了解，现在的问题是即使只开启HTTP协议的分析，大概资源也会用这么多，达不到0.5C的要求。这里也没办法单独关一部分probe。要解决这个问题需要对用户态代码进一步做性能优化，优化方向包括： - 内存复用，减少内存申请（效果最佳） - DataGroup结构优化，减少组件间传递拷贝 - 协议解析流程优化，减少无用判断 这些是已知的可优化方向，是长期目标（至少几个月时间的目标），最近社区几位核心开发者都比较忙，欢迎其他开发者贡献。 关于falco的改动，我觉得挺有用的（虽然不能解决现在的性能问题），Kindling应该定时与上游做一些功能的同步，也许这个功能可以与事件订阅联动。 @jundizhou @sanyangji 你们怎么看？

我理解你说的是“功能降级”思路，这个思路一般是通过临时关闭某些次要或复杂的功能，应对系统负荷过高或发生故障的情况，减少系统崩溃的风险，同时保证核心功能的稳定运行。 所以实际要讨论的是“核心功能”是什么？ - 从业务系统角度看，业务本身是核心功能，由于Kindling是一种监控工具，在系统高负荷时，Kindling整体都可以被关闭掉； - 从Kindling本身的角度看，我们之前认为其中“网络协议分析和统计”是核心功能，如果为了降低Kindling的资源开销而关闭了核心功能，并不符合我们对Kindling的定位。所以我会倾向于持续优化代码来提高性能，尽量降低资源消耗来保证核心功能的运行，而其他部分可以作为功能降级的模块。 你的回复提醒了我，Kindling似乎也不必把“协议分析和请求统计”看成是核心功能，本质上核心功能是“收集各类指标”（当然Kindling还有Trace-profiling这个核心功能，这个部分已经可以动态启停），每类指标都是一个插件，用户可以自由选择启用哪个部分的功能。 我觉得你说的动态启停probe功能是有必要的，只是短期确实没有时间实现，所以这个功能短期还是需要社区来贡献。

关于与上游同步的问题，目前是基于需求来决定，如果有相同的需求就会合并上游代码。例如动态启停probe这个需求，就可以通过合并上游代码来实现，但合并的前提是整体设计好方案，在方案没有确定下来就直接同步上游代码可能会引入不确定的问题。