Merge pull request #588 from didi/dev_v3.0.0-beta.2

合并v3.0.0 beta.2

Author: ZQKC

Releases_Notes.md

@@ -1,4 +1,59 @@
 
+
+## v3.0.0-beta.2
+
+**文档**
+- 新增登录系统对接文档
+- 优化前端工程打包构建部分文档说明
+- FAQ补充KnowStreaming连接特定JMX IP的说明
+
+
+**Bug修复**
+- 修复logi_security_oplog表字段过短，导致删除Topic等操作无法记录的问题
+- 修复ES查询时，抛java.lang.NumberFormatException: For input string: "{"value":0,"relation":"eq"}" 问题
+- 修复LogStartOffset和LogEndOffset指标单位错误问题
+- 修复进行副本变更时，旧副本数为NULL的问题
+- 修复集群Group列表，在第二页搜索时，搜索时返回的分页信息错误问题
+- 修复重置Offset时，返回的错误信息提示不一致的问题
+- 修复集群查看，系统查看，LoadRebalance等页面权限点缺失问题
+- 修复查询不存在的Topic时，错误信息提示不明显的问题
+- 修复Windows用户打包前端工程报错的问题
+- package-lock.json锁定前端依赖版本号，修复因依赖自动升级导致打包失败等问题
+- 系统管理子应用，补充后端返回的Code码拦截，解决后端接口返回报错不展示的问题
+- 修复用户登出后，依旧可以访问系统的问题
+- 修复巡检任务配置时，数值显示错误的问题
+- 修复Broker/Topic Overview 图表和图表详情问题
+- 修复Job扩缩副本任务明细数据错误的问题
+- 修复重置Offset时，分区ID，Offset数值无限制问题
+- 修复扩缩/迁移副本时，无法选中Kafka系统Topic的问题
+- 修复Topic的Config页面，编辑表单时不能正确回显当前值的问题
+- 修复Broker Card返回数据后依旧展示加载态的问题
+
+
+
+**体验优化**
+- 缩短新增集群后，集群信息加载的耗时
+- 集群Broker列表，增加Controller角色信息
+- 优化默认密码为admin/admin
+- 副本变更任务结束后，增加进行优先副本选举的操作
+- Task模块任务分为Metrics、Common、Metadata三类任务，每类任务配备独立线程池，减少对Job模块的线程池，以及不同类任务之间的相互影响
+- 删除代码中存在的多余无用文件
+- 自动新增ES索引模版及近7天索引，减少用户搭建时需要做的事项
+- 优化前端工程打包流程
+- 优化登录页文案，页面左侧栏内容，单集群详情样式，Topic列表趋势图等
+- 首次进入Broker/Topic图表详情时，进行预缓存数据从而优化体验
+- 优化Topic详情Partition Tab的展示
+- 多集群列表页增加编辑功能
+- 优化副本变更时，迁移时间支持分钟级别粒度
+- logi-security版本升级至2.10.13
+- logi-elasticsearch-client版本升级至1.0.24
+
+
+**能力提升**
+- 支持Ldap登录认证
+
+---
+
 ## v3.0.0-beta.1
 
 **文档**
@@ -35,6 +90,7 @@
 - 增加周期任务，用于主动创建缺少的ES模版及索引的能力，减少额外的脚本操作
 - 增加JMX连接的Broker地址可选择的能力
 
+---
 
 ## v3.0.0-beta.0
 

docs/install_guide/源码编译打包手册.md

@@ -1,7 +1,5 @@
-
 ![Logo](https://user-images.githubusercontent.com/71620349/185368586-aed82d30-1534-453d-86ff-ecfa9d0f35bd.png)
 
-
 # `Know Streaming` 源码编译打包手册
 
 ## 1、环境信息
@@ -11,7 +9,7 @@
 `windows7+`、`Linux`、`Mac`
 
 **环境依赖**
-	
+
 - Maven 3.6.3 （后端）
 - Node v12.20.0/v14.17.3 （前端）
 - Java 8+ （后端）
@@ -25,27 +23,23 @@
 
 具体见下面描述。
 
-
-
 ### 2.1、前后端合并打包
 
 1. 下载源码；
 2. 进入 `KS-KM` 工程目录，执行 `mvn -Prelease-package -Dmaven.test.skip=true clean install -U` 命令；
 3. 打包命令执行完成后，会在 `km-dist/target` 目录下面生成一个 `KnowStreaming-*.tar.gz` 的安装包。
 
-
-### 2.2、前端单独打包 
+### 2.2、前端单独打包
 
 1. 下载源码；
-2. 进入 `KS-KM/km-console` 工程目录；
-3. 执行 `npm run build`命令，会在 `KS-KM/km-console` 目录下生成一个名为 `pub` 的前端静态资源包；
-
+2. 跳转到 [前端打包构建文档](https://github.com/didi/KnowStreaming/blob/master/km-console/README.md) 按步骤进行。打包成功后，会在 `km-rest/src/main/resources` 目录下生成名为 `templates` 的前端静态资源包;
+3. 如果上一步过程中报错，请查看 [FAQ](https://github.com/didi/KnowStreaming/blob/master/docs/user_guide/faq.md) 第 8.10 条;
 
-
-### 2.3、后端单独打包 
+### 2.3、后端单独打包
 
 1. 下载源码；
 2. 修改顶层 `pom.xml` ，去掉其中的 `km-console` 模块，如下所示；
+
 ```xml
     <modules>
 <!--        <module>km-console</module>-->
@@ -62,10 +56,7 @@
         <module>km-rest</module>
         <module>km-dist</module>
     </modules>
-   ```
-3. 执行 `mvn -U clean package -Dmaven.test.skip=true`命令；
-4. 执行完成之后会在 `KS-KM/km-rest/target` 目录下面生成一个 `ks-km.jar` 即为KS的后端部署的Jar包，也可以执行 `mvn -Prelease-package -Dmaven.test.skip=true clean install -U` 生成的tar包也仅有后端服务的功能；
-
-
-
+```
 
+3. 执行 `mvn -U clean package -Dmaven.test.skip=true`命令；
+4. 执行完成之后会在 `KS-KM/km-rest/target` 目录下面生成一个 `ks-km.jar` 即为 KS 的后端部署的 Jar 包，也可以执行 `mvn -Prelease-package -Dmaven.test.skip=true clean install -U` 生成的 tar 包也仅有后端服务的功能；

docs/install_guide/版本升级手册.md

@@ -4,6 +4,43 @@
 
 ### 6.2.0、升级至 `master` 版本
 
+暂无
+
+### 6.2.1、升级至 `v3.0.0-beta.2`版本
+
+**配置变更**
+
+```yaml
+
+# 新增配置
+spring:
+  logi-security: # know-streaming 依赖的 logi-security 模块的数据库的配置，默认与 know-streaming 的数据库配置保持一致即可
+    login-extend-bean-name: logiSecurityDefaultLoginExtendImpl # 使用的登录系统Service的Bean名称，无需修改
+
+# 线程池大小相关配置，在task模块中，新增了三类线程池，
+# 从而减少不同类型任务之间的相互影响，以及减少对logi-job内的线程池的影响
+thread-pool:
+  task:                             # 任务模块的配置
+    metrics:                        # metrics采集任务配置
+      thread-num: 18                # metrics采集任务线程池核心线程数
+      queue-size: 180               # metrics采集任务线程池队列大小
+    metadata:                       # metadata同步任务配置
+      thread-num: 27                # metadata同步任务线程池核心线程数
+      queue-size: 270               # metadata同步任务线程池队列大小
+    common:                         # 剩余其他任务配置
+      thread-num: 15                # 剩余其他任务线程池核心线程数
+      queue-size: 150               # 剩余其他任务线程池队列大小
+
+# 删除配置，下列配置将不再使用
+thread-pool:
+  task:                             # 任务模块的配置
+    heaven:                         # 采集任务配置
+      thread-num: 20                # 采集任务线程池核心线程数
+      queue-size: 1000              # 采集任务线程池队列大小
+
+```
+
+
 **SQL变更**
 
 ```sql
@@ -41,7 +78,7 @@ ALTER TABLE `logi_security_oplog`
 
 ---
 
-### 6.2.1、升级至 `v3.0.0-beta.1`版本
+### 6.2.2、升级至 `v3.0.0-beta.1`版本
 
 
 **SQL变更**
@@ -62,7 +99,7 @@ ALTER COLUMN `operation_methods` set default '';
 ---
 
 
-### 6.2.2、`2.x`版本 升级至 `v3.0.0-beta.0`版本
+### 6.2.3、`2.x`版本 升级至 `v3.0.0-beta.0`版本
 
 **升级步骤：**
 

docs/user_guide/faq.md

@@ -1,5 +1,4 @@
-
-# FAQ 
+# FAQ
 
 ## 8.1、支持哪些 Kafka 版本？
 
@@ -110,20 +109,60 @@ SECURITY.TRICK_USERS
 
 但是还有一点需要注意，绕过的用户仅能调用他有权限的接口，比如一个普通用户，那么他就只能调用普通的接口，不能去调用运维人员的接口。
 
-##  8.8、Specified key was too long; max key length is 767 bytes 
+## 8.8、Specified key was too long; max key length is 767 bytes
 
-**原因：**不同版本的InoDB引擎，参数‘innodb_large_prefix’默认值不同，即在5.6默认值为OFF，5.7默认值为ON。
+**原因：** 不同版本的 InoDB 引擎，参数‘innodb_large_prefix’默认值不同，即在 5.6 默认值为 OFF，5.7 默认值为 ON。
 
-对于引擎为InnoDB，innodb_large_prefix=OFF，且行格式为Antelope即支持REDUNDANT或COMPACT时，索引键前缀长度最大为 767 字节。innodb_large_prefix=ON，且行格式为Barracuda即支持DYNAMIC或COMPRESSED时，索引键前缀长度最大为3072字节。
+对于引擎为 InnoDB，innodb_large_prefix=OFF，且行格式为 Antelope 即支持 REDUNDANT 或 COMPACT 时，索引键前缀长度最大为 767 字节。innodb_large_prefix=ON，且行格式为 Barracuda 即支持 DYNAMIC 或 COMPRESSED 时，索引键前缀长度最大为 3072 字节。
 
 **解决方案：**
 
-- 减少varchar字符大小低于767/4=191。
-- 将字符集改为latin1（一个字符=一个字节）。
-- 开启‘innodb_large_prefix’，修改默认行格式‘innodb_file_format’为Barracuda，并设置row_format=dynamic。
+- 减少 varchar 字符大小低于 767/4=191。
+- 将字符集改为 latin1（一个字符=一个字节）。
+- 开启‘innodb_large_prefix’，修改默认行格式‘innodb_file_format’为 Barracuda，并设置 row_format=dynamic。
+
+## 8.9、出现 ESIndexNotFoundEXception 报错
+
+**原因 ：**没有创建 ES 索引模版
+
+**解决方案：**执行 init_es_template.sh 脚本，创建 ES 索引模版即可。
+
+## 8.10、km-console 打包构建失败
+
+首先，**请确保您正在使用最新版本**，版本列表见 [Tags](https://github.com/didi/KnowStreaming/tags)。如果不是最新版本，请升级后再尝试有无问题。
+
+常见的原因是由于工程依赖没有正常安装，导致在打包过程中缺少依赖，造成打包失败。您可以检查是否有以下文件夹，且文件夹内是否有内容
+
+```
+KnowStreaming/km-console/node_modules
+KnowStreaming/km-console/packages/layout-clusters-fe/node_modules
+KnowStreaming/km-console/packages/config-manager-fe/node_modules
+```
+
+如果发现没有对应的 `node_modules` 目录或着目录内容为空，说明依赖没有安装成功。请按以下步骤操作，
+
+1. 手动删除上述三个文件夹（如果有）
+
+2. 如果之前是通过 `mvn install` 打包 `km-console`，请到项目根目录（KnowStreaming）下重新输入该指令进行打包。观察打包过程有无报错。如有报错，请见步骤 4。
+
+3. 如果是通过本地独立构建前端工程的方式（指直接执行 `npm run build`），请进入 `KnowStreaming/km-console` 目录，执行下述步骤（注意：执行时请确保您在使用 `node v12` 版本）
+
+   a. 执行 `npm run i`。如有报错，请见步骤 4。
+
+   b. 执行 `npm run build`。如有报错，请见步骤 4。
+
+4. 麻烦联系我们协助解决。推荐提供以下信息，方面我们快速定位问题，示例如下。
+
+```
+操作系统: Mac
+命令行终端：bash
+Node 版本: v12.22.12
+复现步骤: 1. -> 2.
+错误截图:
+```
 
-## 8.9、出现ESIndexNotFoundEXception报错
+## 8.11、在 `km-console` 目录下执行 `npm run start` 时看不到应用构建和热加载过程？如何启动单个应用？
 
-**原因 ：**没有创建ES索引模版
+需要到具体的应用中执行 `npm run start`，例如 `cd packages/layout-clusters-fe` 后，执行 `npm run start`。
 
-**解决方案：**执行init_es_template.sh脚本，创建ES索引模版即可。 
+应用启动后需要到基座应用中查看（需要启动基座应用，即 layout-clusters-fe）。

km-console/README.md

@@ -1,12 +1,16 @@
 ## 前提
 
-正常情况下，您应该通过 [本地源码启动手册](https://github.com/didi/KnowStreaming/blob/master/docs/dev_guide/%E6%9C%AC%E5%9C%B0%E6%BA%90%E7%A0%81%E5%90%AF%E5%8A%A8%E6%89%8B%E5%86%8C.md) 来打包工程。如果您有需要在本地独立启动前端服务，请参考以下手册。
+通常情况下，您可以通过 [本地源码启动手册](https://github.com/didi/KnowStreaming/blob/master/docs/dev_guide/%E6%9C%AC%E5%9C%B0%E6%BA%90%E7%A0%81%E5%90%AF%E5%8A%A8%E6%89%8B%E5%86%8C.md) 来打包工程。如果您需要在本地独立启动或打包前端服务，请参考以下手册。
 
-在进行以下的步骤之前，首先确保您已经安装了 `node`。如已安装，可以通过在终端执行 `node -v` 来获取到 node 版本，项目推荐使用 `node v12` 版本运行。
+在进行以下的步骤之前，首先确保您已经安装了 `node`。如已安装，可以通过在终端执行 `node -v` 来获取到 node 版本，项目推荐使用 `node v12` 版本运行（例如 `node v12.22.12`）。
 
 另外，`windows` 用户请在 `git bash` 下运行下面的命令。
 
-## 一、安装项目依赖（必须）
+## 一、进入 km-console 目录
+
+在终端执行以下步骤时，需要先进入 `KnowStreaming/km-console` 目录。
+
+## 二、安装项目依赖（必须）
 
 1. 安装 lerna（可选，安装后可以直接通过 lerna 的全局指令管理项目，如果不了解 lerna 可以不安装）
 
@@ -20,9 +24,9 @@ npm install -g lerna
 npm run i
 ```
 
-我们默认保留了 `package-lock.json` 文件，以防止可能的依赖包自动升级导致的问题。依赖默认会通过 `https://registry.npmjs.org` 服务下载，如果您无法连通该服务器，请删除当前目录及 `packages/*` 子目录下的 `package-lock.json` 后，在当前目录下使用 `node v12` 版本执行命令 `npm run i`。
+我们默认保留了 `package-lock.json` 文件，以防止可能的依赖包自动升级导致的问题。依赖默认会通过 taobao 镜像 `https://registry.npmmirror.com/` 服务下载。
 
-## 二、启动项目
+## 三、启动项目（可选，打包构建请直接看步骤三）
 
 ```
 npm run start
@@ -37,11 +41,10 @@ npm run start
 
 如果启动失败，可以参见另外一种本地启动方式 [本地源码启动手册](https://github.com/didi/KnowStreaming/blob/master/docs/dev_guide/%E6%9C%AC%E5%9C%B0%E6%BA%90%E7%A0%81%E5%90%AF%E5%8A%A8%E6%89%8B%E5%86%8C.md)
 
-## 三、构建项目
+## 四、构建项目
 
 ```
 npm run build
-
 ```
 
 项目构建成功后，会存放到 km-rest/src/main/resources/tamplates 目录下。
@@ -53,8 +56,10 @@ npm run build
   - config-manager-fe: 子应用 - 系统管理
 - ...
 
-## 常见问题
+## QA
 
 Q: 在 `km-console` 目录下执行 `npm run start` 时看不到应用构建和热加载过程？如何启动单个应用？
 
 A: 需要到具体的应用中执行 `npm run start`，例如 `cd packages/layout-clusters-fe` 后，执行 `npm run start`。
+
+如遇到其它问题，请见 [faq](https://github.com/didi/KnowStreaming/blob/master/docs/user_guide/faq.md)。