Merge pull request #292 from didi/master

merge master

README.md

@@ -14,7 +14,8 @@
 滴滴Logi-KafkaManager脱胎于滴滴内部多年的Kafka运营实践经验，是面向Kafka用户、Kafka运维人员打造的共享多租户Kafka云平台。专注于Kafka运维管控、监控告警、资源治理等核心场景，经历过大规模集群、海量大数据的考验。内部满意度高达90%的同时，还与多家知名企业达成商业化合作。
 
 ### 1.1 快速体验地址
-- 体验地址 http://117.51.146.109:8080  账号密码 admin/admin
+
+- 体验地址 http://117.51.150.133:8080  账号密码 admin/admin
 
 ### 1.2 体验地图
 相比较于同类产品的用户视角单一（大多为管理员视角），滴滴Logi-KafkaManager建立了基于分角色、多场景视角的体验地图。分别是：**用户体验地图、运维体验地图、运营体验地图**

Releases_Notes.md

@@ -7,6 +7,33 @@
 
 --- 
 
+## v2.4.0
+
+版本上线时间：2021-04-26
+
+
+### 能力提升
+
+- 增加App与Topic自动化审批开关
+- Broker元信息中增加Rack信息
+- 升级MySQL 驱动，支持MySQL 8+
+- 增加操作记录查询界面
+
+### 体验优化
+
+- FAQ告警组说明优化
+- 用户手册共享及 独享集群概念优化
+- 用户管理界面，前端限制用户删除自己
+
+### bug修复
+
+- 修复op-util类中创建Topic失败的接口
+- 周期同步Topic到DB的任务修复，将Topic列表查询从缓存调整为直接查DB
+- 应用下线审批失败的功能修复，将权限为0(无权限)的数据进行过滤
+- 修复登录及权限绕过的漏洞
+- 修复研发角色展示接入集群、暂停监控等按钮的问题
+
+
 ## v2.3.0
 
 版本上线时间：2021-02-08

docs/dev_guide/dynamic_config_manager.md

@@ -119,4 +119,24 @@ TOPIC_INSUFFICIENT_PARTITION_CONFIG
     50
   ]
 }
-```
+```
+## 4、专家服务——Topic资源治理
+
+首先，我们认为在一定的时间长度内，Topic的分区offset没有任何变化的Topic，即没有数据写入的Topic，为过期的Topic。
+
+Topic分区不足相关的动态配置(页面在运维管控->平台管理->配置管理)：
+
+配置Key：
+```
+EXPIRED_TOPIC_CONFIG
+```
+
+配置Value：
+```json
+{
+  "minExpiredDay": 30,  #过期时间大于此值才显示
+  "ignoreClusterIdList": [  # 忽略的集群
+    50
+  ]
+}
+```

docs/user_guide/faq.md

@@ -25,6 +25,8 @@
 - 13、heartbeat表关联业务和使用场景是什么？
 - 14、集群的删除，是否会真正的删除集群？
 - 15、APP(应用)如何被使用起来？
+- 16、为什么下线应用提示operation forbidden？
+- 17、删除Topic成功，为什么过一会儿之后又出现了？
 
 ---
 
@@ -155,3 +157,41 @@ app在Logi-KM中可以近似理解为租户，或者是kafka里面的一个账
 界面中显示的app信息、权限信息等，在平台层面仅仅只是控制Topic或集群在平台上的可见性，如果使用的是社区版本的Kafka，那么实际上是不能真正的管控到客户端对Topic的生产和消费。
 
 但是如果是使用的滴滴的Kafka-Gateway，那么是可以做到对客户端的生产和消费的权限管控。滴滴的Kafka-Gateway暂未开源，属于企业服务，具体的可以入群交流，群地址在README中。
+
+
+### 16、为什么下线应用提示operation forbidden？
+
+**原因一：**
+
+该应用还存在对Topic的权限，因此导致下线失败。具体查看的位置在"Topic管理-》应用管理-》详情"，可以看到应用对哪些Topic还有权限。
+
+只有当权限全部去除之后，才可以下线应用。
+
+**原因二：**
+
+使用的是2.4.0之前的旧版本，旧版本存在缓存更新的BUG，建议升级至最新的版本，或者简单粗暴的就是重启一下KM。
+
+
+### 17、删除Topic成功，为什么过一会儿之后又出现了？
+
+**原因说明：**
+
+Logi-KM会去请求Topic的endoffset信息，要获取这个信息就需要发送metadata请求，发送metadata请求的时候，如果集群允许自动创建Topic，那么当Topic不存在时，就会自动将该Topic创建出来。
+
+
+**问题解决：**
+
+因为在Logi-KM上，禁止Kafka客户端内部元信息获取这个动作非常的难做到，因此短时间内这个问题不好从Logi-KM上解决。
+
+当然，对于不存在的Topic，Logi-KM是不会进行元信息请求的，因此也不用担心会莫名其妙的创建一个Topic出来。
+
+但是，另外一点，对于开启允许Topic自动创建的集群，建议是关闭该功能，开启是非常危险的，如果关闭之后，Logi-KM也不会有这个问题。
+
+最后这里举个开启这个配置后，非常危险的代码例子吧：
+
+```java
+for (int i= 0; i < 100000; ++i) {
+    // 如果是客户端类似这样写的，那么一启动，那么将创建10万个Topic出来，集群元信息瞬间爆炸，controller可能就不可服务了。
+    producer.send(new ProducerRecord<String, String>("logi_km" + i,"hello logi_km"));
+}
+```