架构优化相关 about lmp HOT 5 CLOSED

想法是不错的，但是我们还有几个点需要考虑：
1.目前是只支持bcc，未来希望还能支持纯bpf，gobpf等其它类型的插件，有可能还有非bpf插件，需要抽象这一层，但是不一定非要以独立服务和python开发，单体服务目前对我们来说更合理，未来在分布式架构中是要做一定拆分的，但是整体服务不能引入多种框架开发语言，这对开发门槛要求比较高。
2.目前的bpf内核程序和用户数据采集程序是放到一起的，未来希望是能在这里做个一拆分，内核程序专做内核程序的事情，用户态数据采集程序可以相对独立，对接内核数据采集和数据用户态存储以及展示服务。
3.插件状态信息管理，目前单机版本中还缺失插件状态信息采集，要能够感知到有哪些bpf程序已经加载到内核，可以感知它的收集数据map，可以读取收集的数据到另外的用户态存储，可以卸载等，这方面也是非常需要的。
4.作为一个管理端系统bcc的编译性能目前不是最重要的，而是管理的合理性和便捷性。对性能要求主要是开发的bpf程序在内核中的性能，这是一个强需求，必经加载只需要一次，但是内核中的执行可能是很高评率的事情。所以目前go协程是足够处理。
5.但是对lmp中的各个模块还是要做抽象分离，但是这种分离可以是面向对象的抽象分离，而不是独立为不通的进程，我们希望是进程内调用，而不是进程间调用。一方面会有一些调用损耗，但这不是主要问题，主要问题是系统的部署复杂性和问题排查复杂性高了很多，日志查看也不方便，类似的问题还很多。所以希望是在这里可以做更多抽象设计，但是还是要以单体架构的形式存在。未来在做分布式的时候也是一个模块以master和slaver模式启动就好了。

from lmp.

@helight 大师兄我们目前还是按照上次会议说的方向做，我和@Request2609 沟通完一些点确实是可以优化的，更多是分布式场景下的优化点，性能开销主要还是在ebpf程序上面，优化点后面可以再深入考虑。感谢@helight @Request2609 ^v^

from lmp.

from lmp.

1、不是全部迁移成gobpf，是支持不同类型的ebpf运行方式，比如纯C，bcc，bpftrace、传统工具等等，统一用工厂模式组织。
2、开进程变为开线程是可以减少开销的，是一个优化点，这里还有一个问题就是每一个插件带来的性能开销，可能一次性执行5个，系统开销就会增大很多，系统状态就不支持再开启新的指标了。
3、目前代码没有跳转grafana，使用方法应该是打开lmp页面，再打开grafana，不跳转了，lmp页面只做下发，来回跳转反而不方便。目前正在做指标执行状态。
4、lmp的分布式当然是提取多个节点的性能数据，完全不用实现另外一套逻辑，只用rpc实现节点逻辑就可以了，分布式目前优先级不高。
5、把前端参数处理和执行指标分成两个部分是没问题的，确实是优化点。

from lmp.

from lmp.