[Chenyu Zhao]: update thought_log

eBPF_Visualization/thought_log.md

@@ -4,73 +4,52 @@
 
 今天开始使用thought log的形式记录项目方案的更迭。
 
-LMP重构前的可视化方案采用的是集成现有的成熟组件，前端 + 后端 + mysql + influxdb + grafana，这样的方案在企业或者生产环境是比较适用的，但是对于个人用户来说，例如说自己的需求就是本地想要一个非常轻量化的ebpf插件可视化工具，不想安装配置mysql、influxdb、grafana这些组件。
+`LMP可视化` 重构前的可视化方案采用的是集成现有的成熟组件，前端 + 后端（golang） + mysql + influxdb + grafana，这样的方案在企业或者生产环境是比较适用的，但是对于个人用户、轻量级用户来说，环境配置本身就比较繁琐。
 
-目前的想法是LMP提供一个最简路径，就是我们提供一个最轻量化的web可视化方案，数据库采用一个内嵌数据库，然后把数据写入、获取这些留出接口，可以对接外部的数据库、可视化工具这些。
+因此目前的想法是把 `LMP可视化` 重构成一个非常轻量的、可配置的工具，不只是设计上，还有使用方法上，数据的存储默认提供一个内嵌数据库，然后把数据写入、获取这些留出接口，可以对接外部的数据库、可视化工具这样。
 
-然后对目前的功能进行重新的梳理，LMP下会单独拆出来一个可视化项目，两个功能，一个是ebpf插件数据可视化，一个是场景化分析可视化，所以在这两部分的核心功能其实是数据的获取和存储，现在只考虑插件数据的可视化，一个草图：
+目前先暂时不考虑 `场景化分析可视化` ，所以核心功能其实是数据的获取和存储，一个草图：
 
 ![](../eBPF_Documentation/static/imgs/LMP-ske.jpg)
 
-插件可视化功能的核心服务是插件的数据存储，前端部分admin是和这个服务交互，`API服务端应用`负责解析前端参数，主要是解析出来需要执行哪个插件，然后将信息传递给`插件数据存储服务`，然后`插件数据存储服务`调用插件并执行，在插件执行后，`插件数据存储服务`会把插件的输出内容进行重定向，解析处理之后存储到内嵌数据库；
+使用方式分为两种，也就是有两个可执行文件会被编译出来：
 
-之后前端每过一段时间访问内嵌数据库的数据来进行数据可视化；
+第一种是命令行工具形式，例如：
 
-然后目前的想法是插件数据存储服务这一块其实是和`admin`部分隔离的，也就是离开`admin`其实是可以独立运行的，所以问题就是定义`插件数据存储服务`的功能范畴，目前看一个是负责插件的执行，因为需要重定向插件的输出，所以必须要由服务来启动插件，然后就是数据的存储；和外部的交互方式也是一个问题，就是`插件数据存储服务`和`API服务端应用`之间怎么交互比较好，（消息队列？），然后就是`API服务端应用`获取数据的时候，是直接和`插件数据存储服务`直接交互好，还是独立出来一个模块比如数据提取模块，和这个独立出来的模块交互比较好，最后就是这种设计有没有一些适用的设计模式或者架构上比较好的设计。
+```bash
+$ lmp run YOUR_BPF_PROGRAM
+```
 
-其实可视化部分的核心还是数据管理，data manager，可视化只是使用数据的一种方法，所以要有命令行执行查件并保存数据的功能，不通过web也可以保存数据；
+执行后就可以把工具的输出进行本地化存储，并自动导出成 csv 格式，以便后续的 ML 算法。
 
+第二种方法是 web 操作方法，前端部分 admin 和核心服务交互，`API服务端应用`负责解析前端参数，主要是解析出来需要执行哪个插件，然后将信息传递给`插件数据存储服务`，然后`插件数据存储服务`调用插件并执行，在插件执行后，`插件数据存储服务`会把插件的输出内容进行重定向，解析处理之后存储到内嵌数据库；
 
+有个问题就是`插件数据存储服务`和`API服务端应用`之间怎么交互比较好，（消息队列？），还有就是这种场景下有没有一些适用的设计模式或者架构上比较好的设计。
 
----
+另外我们想让 BPF 开发者以尽量小的代价完成数据的导出，要求如下：
 
-最新>>>>>>
+- 是一个ELF或者python文件
 
-晚上开完会整理一下思路，就是要把最核心的功能剥离出来，它可以单独执行，而不用依赖于web部分，一定要易用，轻量级；最核心的功能其实就是数据的存储，要完成这一步，需要首先把eBPF程序执行起来，然后把捕获的数据进行存储。对于eBPF程序的要求：首先是一个ELF或者python文件，第二个是输出格式要类似于这样子：
+- 第二个是输出格式要类似于这样子
 
 ```bash
-TIME         READ/s  WRITE/s CREATE/s   OPEN/s  FSYNC/s
-21:07:20:      1368      105        0       61        0
-21:07:21:       136      107        0       59        0
-21:07:22:       132      105        0       58        0
-21:07:23:       132      105        0       58        0
-21:07:24:       134      108        0       58        0
-21:07:25:       131      104        0       58        0
+[TIME|INTEGER         READ/s|INTEGER  WRITE/s|INTEGER ]
+21:07:20                         1368                      105        
+21:07:21                          136                       107       
+21:07:22                          132                       105        
+21:07:23                          132                       105        
+21:07:24                          134                       108       
+21:07:25                          131                       104      
 ```
 
-第一行是指标的名称，下面就是每个指标具体的数据，除此之外，不需要限制输出数据中指标的个数，不需要在 eBPF 代码中加入任何的API，不需要部署mysql、influxdb、grafana之类的组件，不需要部署web环境，不需要通过web形式下发，因此也没有必要使用插件这个说法了，就是eBPF程序。
+第一行是指标的名称只需要指定指标的数据类型，下面就是每个指标具体的数据，除此之外，不需要限制输出数据中指标的个数，不需要在 eBPF 代码中加入任何的API,
 
-最核心的eBPF数据存储服务可以单独编译成一个可执行文件，这样我自己写好一个eBPF程序并且编译成可执行文件，而且按照上面的格式输出后，调用一行命令就可以实现eBPF程序执行并且实现数据持久化，类似于这样：
+--- 
 
-```bash
-$ lmp run vfsstat
-```
+更新：
 
 以上是最核心的部分，而我们也提供外部的组件或者说是模块，例如说web部分，也就是图中的admin，可以接入核心服务，实现web页面下eBPF程序管理、web可视化功能等；
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+---