8x48/KnowStreaming
1
0
Fork 0
mirror of https://github.com/didi/KnowStreaming.git synced 2025-12-24 11:52:08 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

初始化3.0.0版本

Browse Source
This commit is contained in:
zengqiao
2022-08-18 17:04:05 +08:00
parent 462303fca0
commit 51832385b1
2446 changed files with 93177 additions and 127211 deletions
Download Patch File Download Diff File Expand all files Collapse all files

47
docs/dev_guide/LogiKM单元测试和集成测试.md
View File

@@ -1,47 +0,0 @@
---
![kafka-manager-logo](../assets/images/common/logo_name.png)
**一站式`Apache Kafka`集群指标监控与运维管控平台**
---
# LogiKM单元测试和集成测试
## 1、单元测试
### 1.1 单元测试介绍
单元测试又称模块测试，是针对软件设计的最小单位——程序模块进行正确性检验的测试工作。
其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，
发现各模块内部可能存在的各种错误。单元测试需要从程序的内部结构出发设计测试用例。
多个模块可以平行地独立进行单元测试。
### 1.2 LogiKM单元测试思路
LogiKM单元测试思路主要是测试Service层的方法，通过罗列方法的各种参数，
判断方法返回的结果是否符合预期。单元测试的基类加了@SpringBootTest注解，即每次运行单测用例都启动容器
### 1.3 LogiKM单元测试注意事项
1. 单元测试用例在kafka-manager-core以及kafka-manager-extends下的test包中
2. 配置在resources/application.yml，包括运行单元测试用例启用的数据库配置等等
3. 编译打包项目时，加上参数-DskipTests可不执行测试用例，例如使用命令行mvn -DskipTests进行打包
## 2、集成测试
### 2.1 集成测试介绍
集成测试又称组装测试，是一种黑盒测试。通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。
集成测试是检验程序单元或部件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统。
### 2.2 LogiKM集成测试思路
LogiKM集成测试主要思路是对Controller层的接口发送Http请求。
通过罗列测试用例，模拟用户的操作，对接口发送Http请求，判断结果是否达到预期。
本地运行集成测试用例时，无需加@SpringBootTest注解（即无需每次运行测试用例都启动容器）
### 2.3 LogiKM集成测试注意事项
1. 集成测试用例在kafka-manager-web的test包下
2. 因为对某些接口发送Http请求需要先登陆，比较麻烦，可以绕过登陆，方法可见教程见docs -> user_guide -> call_api_bypass_login
3. 集成测试的配置在resources/integrationTest-settings.properties文件下，包括集群地址，zk地址的配置等等
4. 如果需要运行集成测试用例，需要本地先启动LogiKM项目
5. 编译打包项目时，加上参数-DskipTests可不执行测试用例，例如使用命令行mvn -DskipTests进行打包

BIN
docs/dev_guide/assets/dynamic_config_manager/sync_topic_to_db.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 270 KiB

BIN
docs/dev_guide/assets/increase_the_indicators_reported_to_monitor_system/collect_topic_metrics.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 785 KiB

BIN
docs/dev_guide/assets/increase_the_indicators_reported_to_monitor_system/sink_metrcis.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 2.5 MiB

BIN
docs/dev_guide/assets/kcm/kcm_principle.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 69 KiB

BIN
docs/dev_guide/assets/monitor_system_integrate_with_self/change_config.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 589 KiB

BIN
docs/dev_guide/assets/monitor_system_integrate_with_self/integrate_ms.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 652 KiB

BIN
docs/dev_guide/assets/monitor_system_integrate_with_self/open_sink_schedule.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 511 KiB

BIN
docs/dev_guide/assets/monitor_system_integrate_with_self/sink_metrics.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 672 KiB

BIN
docs/dev_guide/assets/multi_version_compatible/registerHandler.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 600 KiB

BIN
docs/dev_guide/assets/startup_using_source_code/IDEA配置.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 228 KiB

89
docs/dev_guide/drawio/KCM实现原理.drawio
View File

@@ -1,89 +0,0 @@
<mxfile host="65bd71144e">
<diagram id="bhaMuW99Q1BzDTtcfRXp" name="Page-1">
<mxGraphModel dx="1138" dy="830" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="1169" pageHeight="827" math="0" shadow="0">
<root>
<mxCell id="0"/>
<mxCell id="1" parent="0"/>
<mxCell id="11" value="待部署Kafka-Broker的机器" style="rounded=0;whiteSpace=wrap;html=1;absoluteArcSize=1;arcSize=14;strokeWidth=1;labelPosition=center;verticalLabelPosition=bottom;align=center;verticalAlign=top;dashed=1;" vertex="1" parent="1">
<mxGeometry x="380" y="240" width="320" height="240" as="geometry"/>
</mxCell>
<mxCell id="24" value="" style="rounded=0;whiteSpace=wrap;html=1;absoluteArcSize=1;arcSize=14;strokeWidth=1;labelPosition=center;verticalLabelPosition=bottom;align=center;verticalAlign=top;dashed=1;fillColor=#eeeeee;strokeColor=#36393d;" vertex="1" parent="1">
<mxGeometry x="410" y="310" width="260" height="160" as="geometry"/>
</mxCell>
<mxCell id="6" style="edgeStyle=none;html=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" edge="1" parent="1" source="2" target="3">
<mxGeometry relative="1" as="geometry"/>
</mxCell>
<mxCell id="7" value="调用夜莺接口，&lt;br&gt;创建集群安装部署任务" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];" vertex="1" connectable="0" parent="6">
<mxGeometry x="-0.0875" y="1" relative="1" as="geometry">
<mxPoint x="9" y="1" as="offset"/>
</mxGeometry>
</mxCell>
<mxCell id="9" style="edgeStyle=none;html=1;" edge="1" parent="1" source="2" target="4">
<mxGeometry relative="1" as="geometry"/>
</mxCell>
<mxCell id="10" value="通过版本管理，将Kafka的安装包，&lt;br&gt;server配置上传到s3中" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];" vertex="1" connectable="0" parent="9">
<mxGeometry x="0.0125" y="2" relative="1" as="geometry">
<mxPoint as="offset"/>
</mxGeometry>
</mxCell>
<mxCell id="2" value="LogiKM" style="rounded=0;whiteSpace=wrap;html=1;absoluteArcSize=1;arcSize=14;strokeWidth=1;fillColor=#dae8fc;strokeColor=#6c8ebf;" vertex="1" parent="1">
<mxGeometry x="40" y="100" width="120" height="40" as="geometry"/>
</mxCell>
<mxCell id="12" style="edgeStyle=none;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" edge="1" parent="1" source="3" target="5">
<mxGeometry relative="1" as="geometry"/>
</mxCell>
<mxCell id="13" value="1、下发任务脚本(kcm_script.sh)；&lt;br&gt;2、下发任务操作命令；" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];" vertex="1" connectable="0" parent="12">
<mxGeometry x="-0.0731" y="2" relative="1" as="geometry">
<mxPoint x="-2" y="-16" as="offset"/>
</mxGeometry>
</mxCell>
<mxCell id="3" value="夜莺——任务中心" style="rounded=0;whiteSpace=wrap;html=1;absoluteArcSize=1;arcSize=14;strokeWidth=1;fillColor=#cdeb8b;strokeColor=#36393d;" vertex="1" parent="1">
<mxGeometry x="480" y="100" width="120" height="40" as="geometry"/>
</mxCell>
<mxCell id="4" value="S3" style="rounded=0;whiteSpace=wrap;html=1;absoluteArcSize=1;arcSize=14;strokeWidth=1;fillColor=#ffe6cc;strokeColor=#d79b00;" vertex="1" parent="1">
<mxGeometry x="40" y="310" width="120" height="40" as="geometry"/>
</mxCell>
<mxCell id="5" value="夜莺——Agent(&lt;font color=&quot;#ff3333&quot;&gt;代理执行kcm_script.sh脚本&lt;/font&gt;)" style="rounded=0;whiteSpace=wrap;html=1;absoluteArcSize=1;arcSize=14;strokeWidth=1;fillColor=#d5e8d4;strokeColor=#82b366;" vertex="1" parent="1">
<mxGeometry x="400" y="260" width="280" height="40" as="geometry"/>
</mxCell>
<mxCell id="22" style="edgeStyle=orthogonalEdgeStyle;html=1;entryX=1;entryY=0.5;entryDx=0;entryDy=0;fontColor=#FF3333;exitX=0;exitY=0.5;exitDx=0;exitDy=0;" edge="1" parent="1" source="14" target="4">
<mxGeometry relative="1" as="geometry"/>
</mxCell>
<mxCell id="25" value="下载安装包" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontColor=#000000;" vertex="1" connectable="0" parent="22">
<mxGeometry x="0.2226" y="-2" relative="1" as="geometry">
<mxPoint x="27" y="2" as="offset"/>
</mxGeometry>
</mxCell>
<mxCell id="14" value="执行kcm_script.sh脚本：下载安装包" style="rounded=0;whiteSpace=wrap;html=1;absoluteArcSize=1;arcSize=14;strokeWidth=1;fillColor=#eeeeee;strokeColor=#36393d;" vertex="1" parent="1">
<mxGeometry x="425" y="320" width="235" height="20" as="geometry"/>
</mxCell>
<mxCell id="18" value="执行kcm_script.sh脚本：安装" style="rounded=0;whiteSpace=wrap;html=1;absoluteArcSize=1;arcSize=14;strokeWidth=1;fillColor=#eeeeee;strokeColor=#36393d;" vertex="1" parent="1">
<mxGeometry x="425" y="350" width="235" height="20" as="geometry"/>
</mxCell>
<mxCell id="19" value="执行kcm_script.sh脚本：检查安装结果" style="rounded=0;whiteSpace=wrap;html=1;absoluteArcSize=1;arcSize=14;strokeWidth=1;fillColor=#eeeeee;strokeColor=#36393d;" vertex="1" parent="1">
<mxGeometry x="425" y="380" width="235" height="20" as="geometry"/>
</mxCell>
<mxCell id="23" style="edgeStyle=orthogonalEdgeStyle;html=1;entryX=0.5;entryY=0;entryDx=0;entryDy=0;fontColor=#FF3333;exitX=1;exitY=0.5;exitDx=0;exitDy=0;" edge="1" parent="1" source="20" target="2">
<mxGeometry relative="1" as="geometry">
<Array as="points">
<mxPoint x="770" y="420"/>
<mxPoint x="770" y="40"/>
<mxPoint x="100" y="40"/>
</Array>
</mxGeometry>
</mxCell>
<mxCell id="26" value="检查副本同步状态" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontColor=#000000;" vertex="1" connectable="0" parent="23">
<mxGeometry x="-0.3344" relative="1" as="geometry">
<mxPoint as="offset"/>
</mxGeometry>
</mxCell>
<mxCell id="20" value="执行kcm_script.sh脚本：检查副本同步" style="rounded=0;whiteSpace=wrap;html=1;absoluteArcSize=1;arcSize=14;strokeWidth=1;fillColor=#eeeeee;strokeColor=#36393d;" vertex="1" parent="1">
<mxGeometry x="425" y="410" width="235" height="20" as="geometry"/>
</mxCell>
<mxCell id="21" value="执行kcm_script.sh脚本：结束" style="rounded=0;whiteSpace=wrap;html=1;absoluteArcSize=1;arcSize=14;strokeWidth=1;fillColor=#eeeeee;strokeColor=#36393d;" vertex="1" parent="1">
<mxGeometry x="425" y="440" width="235" height="20" as="geometry"/>
</mxCell>
</root>
</mxGraphModel>
</diagram>
</mxfile>

169
docs/dev_guide/dynamic_config_manager.md
View File

@@ -1,169 +0,0 @@
---
![kafka-manager-logo](../assets/images/common/logo_name.png)
**一站式`Apache Kafka`集群指标监控与运维管控平台**
---
# 动态配置管理
## 0、目录
- 1、Topic定时同步任务
- 2、专家服务——Topic分区热点
- 3、专家服务——Topic分区不足
- 4、专家服务——Topic资源治理
- 5、账单配置
## 1、Topic定时同步任务
### 1.1、配置的用途
`Logi-KafkaManager`在设计上，所有的资源都是挂在应用(app)下面。 如果接入的Kafka集群已经存在Topic了，那么会导致这些Topic不属于任何的应用，从而导致很多管理上的不便。
因此，需要有一个方式将这些无主的Topic挂到某个应用下面。
这里提供了一个配置，会定时自动将集群无主的Topic挂到某个应用下面下面。
### 1.2、相关实现
就是一个定时任务，该任务会定期做同步的工作。具体代码的位置在`com.xiaojukeji.kafka.manager.task.dispatch.op`包下面的`SyncTopic2DB`类。
### 1.3、配置说明
**步骤一：开启该功能**
在application.yml文件中，增加如下配置，已经有该配置的话，直接把false修改为true即可
```yml
# 任务相关的开关
task:
op:
sync-topic-enabled: true # 无主的Topic定期同步到DB中
```
**步骤二：配置管理中指定挂在那个应用下面**
配置的位置：
![sync_topic_to_db](./assets/dynamic_config_manager/sync_topic_to_db.jpg)
配置键：`SYNC_TOPIC_2_DB_CONFIG_KEY`
配置值(JSON数组)：
- clusterId：需要进行定时同步的集群ID
- defaultAppId：该集群无主的Topic将挂在哪个应用下面
- addAuthority：是否需要加上权限, 默认是false。因为考虑到这个挂载只是临时的，我们不希望用户使用这个App，同时后续可能移交给真正的所属的应用，因此默认是不加上权限。
**注意，这里的集群ID，或者是应用ID不存在的话，会导致配置不生效。该任务对已经在DB中的Topic不会进行修改**
```json
[
{
"clusterId": 1234567,
"defaultAppId": "ANONYMOUS",
"addAuthority": false
},
{
"clusterId": 7654321,
"defaultAppId": "ANONYMOUS",
"addAuthority": false
}
]
```
---
## 2、专家服务——Topic分区热点
在`Region`所圈定的Broker范围内，某个Topic的Leader数在这些圈定的Broker上分布不均衡时，我们认为该Topic是存在热点的Topic。
备注：单纯的查看Leader数的分布，确实存在一定的局限性，这块欢迎贡献更多的热点定义于代码。
Topic分区热点相关的动态配置(页面在运维管控->平台管理->配置管理)：
配置Key：
```
REGION_HOT_TOPIC_CONFIG
```
配置Value：
```json
{
"maxDisPartitionNum": 2, # Region内Broker间的leader数差距超过2时，则认为是存在热点的Topic
"minTopicBytesInUnitB": 1048576, # 流量低于该值的Topic不做统计
"ignoreClusterIdList": [ # 忽略的集群
50
]
}
```
---
## 3、专家服务——Topic分区不足
总流量除以分区数，超过指定值时，则我们认为存在Topic分区不足。
Topic分区不足相关的动态配置(页面在运维管控->平台管理->配置管理)：
配置Key：
```
TOPIC_INSUFFICIENT_PARTITION_CONFIG
```
配置Value：
```json
{
"maxBytesInPerPartitionUnitB": 3145728, # 单分区流量超过该值, 则认为分区不去
"minTopicBytesInUnitB": 1048576, # 流量低于该值的Topic不做统计
"ignoreClusterIdList": [ # 忽略的集群
50
]
}
```
## 4、专家服务——Topic资源治理
首先，我们认为在一定的时间长度内，Topic的分区offset没有任何变化的Topic，即没有数据写入的Topic，为过期的Topic。
Topic分区不足相关的动态配置(页面在运维管控->平台管理->配置管理)：
配置Key：
```
EXPIRED_TOPIC_CONFIG
```
配置Value：
```json
{
"minExpiredDay": 30, #过期时间大于此值才显示,
"filterRegex": ".*XXX\\s+", #忽略符合此正则规则的Topic
"ignoreClusterIdList": [ # 忽略的集群
50
]
}
```
## 5、账单配置
Logi-KafkaManager除了作为Kafka运维管控平台之外，实际上还会有一些资源定价相关的功能。
当前定价方式：当月Topic的maxAvgDay天的峰值的均值流量作为Topic的使用额度。使用的额度 * 单价 * 溢价(预留buffer) 就等于当月的费用。
详细的计算逻辑见：com.xiaojukeji.kafka.manager.task.dispatch.biz.CalKafkaTopicBill; 和 com.xiaojukeji.kafka.manager.task.dispatch.biz.CalTopicStatistics;
这块在计算Topic的费用的配置如下所示：
配置Key：
```
KAFKA_TOPIC_BILL_CONFIG
```
配置Value：
```json
{
"maxAvgDay": 10, # 使用额度的计算规则
"quotaRatio": 1.5, # 溢价率
"priseUnitMB": 100 # 单价，即单MB/s流量多少钱
}
```

10
docs/dev_guide/gateway_config_manager.md
View File

@@ -1,10 +0,0 @@
---
![kafka-manager-logo](../assets/images/common/logo_name.png)
**一站式`Apache Kafka`集群指标监控与运维管控平台**
---
# Kafka-Gateway 配置说明

42
docs/dev_guide/monitor_system_integrate_with_n9e.md
View File

@@ -1,42 +0,0 @@
---
![kafka-manager-logo](../assets/images/common/logo_name.png)
**一站式`Apache Kafka`集群指标监控与运维管控平台**
---
# 监控系统集成——夜莺
- `Kafka-Manager`通过将 监控的数据 以及 监控的规则 都提交给夜莺，然后依赖夜莺的监控系统从而实现监控告警功能。
- 监控数据上报 & 告警规则的创建等能力已经具备。但类似查看告警历史，告警触发时的监控数据等正在集成中(暂时可以到夜莺系统进行查看)，欢迎有兴趣的同学进行共建 或 贡献代码。
## 1、配置说明
```yml
# 配置文件中关于监控部分的配置
monitor:
enabled: false
n9e:
nid: 2
user-token: 123456
# 夜莺 mon监控服务 地址
mon:
base-url: http://127.0.0.1:8006
# 夜莺 transfer上传服务 地址
sink:
base-url: http://127.0.0.1:8008
# 夜莺 rdb资源服务 地址
rdb:
base-url: http://127.0.0.1:80
# enabled: 表示是否开启监控告警的功能, true: 开启, false: 不开启
# n9e.nid: 夜莺的节点ID
# n9e.user-token: 用户的密钥，在夜莺的个人设置中
# n9e.mon.base-url: 监控地址
# n9e.sink.base-url: 数据上报地址
# n9e.rdb.base-url: 用户资源中心地址
```

54
docs/dev_guide/monitor_system_integrate_with_self.md
View File

@@ -1,54 +0,0 @@
---
![kafka-manager-logo](../assets/images/common/logo_name.png)
**一站式`Apache Kafka`集群指标监控与运维管控平台**
---
# 监控系统集成
- 监控系统默认与 [夜莺] (https://github.com/didi/nightingale) 进行集成；
- 对接自有的监控系统需要进行简单的二次开发，即实现部分监控告警模块的相关接口即可；
- 集成会有两块内容，一个是指标数据上报的集成，还有一个是监控告警规则的集成；
## 1、指标数据上报集成
仅完成这一步的集成之后，即可将监控数据上报到监控系统中，此时已能够在自己的监控系统进行监控告警规则的配置了。
**步骤一：实现指标上报的接口**
- 按照自己内部监控系统的数据格式要求，将数据进行组装成符合自己内部监控系统要求的数据进行上报，具体的可以参考夜莺集成的实现代码。
- 至于会上报哪些指标，可以查看有哪些地方调用了该接口。
![sink_metrics](./assets/monitor_system_integrate_with_self/sink_metrics.jpg)
**步骤二：相关配置修改**
![change_config](./assets/monitor_system_integrate_with_self/change_config.jpg)
**步骤三：开启上报任务**
![open_sink_schedule](./assets/monitor_system_integrate_with_self/open_sink_schedule.jpg)
## 2、监控告警规则集成
完成**1、指标数据上报集成**之后，即可在自己的监控系统进行监控告警规则的配置了。完成该步骤的集成之后，可以在`Logi-KafkaManager`中进行监控告警规则的增删改查等等。
大体上和**1、指标数据上报集成**一致，
**步骤一：实现相关接口**
![integrate_ms](./assets/monitor_system_integrate_with_self/integrate_ms.jpg)
实现完成步骤一之后，接下来的步骤和**1、指标数据上报集成**中的步骤二、步骤三一致，都需要进行相关配置的修改即可。
## 3、总结
简单介绍了一下监控告警的集成，嫌麻烦的同学可以仅做 **1、指标数据上报集成** 这一节的内容即可满足一定场景下的需求。
**集成过程中，有任何觉得文档没有说清楚的地方或者建议，欢迎入群交流，也欢迎贡献代码，觉得好也辛苦给个star。**

41
docs/dev_guide/use_mysql_8.md
View File

@@ -1,41 +0,0 @@
---
![kafka-manager-logo](../assets/images/common/logo_name.png)
**一站式`Apache Kafka`集群指标监控与运维管控平台**
---
# 使用`MySQL 8`
感谢 [herry-hu](https://github.com/herry-hu) 提供的方案。
当前因为无法同时兼容`MySQL 8`与`MySQL 5.7`，因此代码中默认的版本还是`MySQL 5.7`。
当前如需使用`MySQL 8`，则需按照下述流程进行简单修改代码。
- Step1. 修改application.yml中的MySQL驱动类
```shell
# 将driver-class-name后面的驱动类修改为:
# driver-class-name: com.mysql.jdbc.Driver
driver-class-name: com.mysql.cj.jdbc.Driver
```
- Step2. 修改MySQL依赖包
```shell
# 将根目录下面的pom.xml文件依赖的`MySQL`依赖包版本调整为
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
# <version>5.1.41</version>
<version>8.0.20</version>
</dependency>
```

98
docs/dev_guide/健康巡检.md Normal file
View File

@@ -0,0 +1,98 @@
![Logo](../assets/KnowStreamingLogo.png)
# 健康巡检
## 1、前言
---
## 2、已有巡检
### 2.1、Cluster健康巡检(1个)
#### 2.1.1、集群Controller数错误
**说明**
- 集群Controller数不等于1，表明集群集群无Controller或者出现了多个Controller，该
**配置**
---
### 2.2、Broker健康巡检(2个)
#### 2.2.1、Broker-RequestQueueSize被打满
**说明**
- Broker的RequestQueueSize，被打满；
**配置**
---
#### 2.2.2、Broker-NetworkProcessorAvgIdle过低
**说明**
- Broker的NetworkProcessorAvgIdle指标，当前过低；
**配置**
---
### 2.3、Topic健康巡检(2个)
#### 2.3.1、Topic 无Leader数
**说明**
- 当前Topic的无Leader分区数超过一定值；
**配置**
#### 2.3.1、Topic 长期处于未同步状态
**说明**
- 指定的一段时间内，Topic一直处于未同步的状态；
**配置**
---
### 2.4、Group健康巡检(1个)
#### 2.4.1、Group Re-Balance太频繁
**说明**
- 指定的一段时间内，Group Re-Balance的次数是否过多；
**配置**
---
## 3、自定义增强
如何增加想要的巡检？

43
docs/dev_guide/免登录调用接口.md Normal file
View File

@@ -0,0 +1,43 @@
![Logo](../assets/KnowStreamingLogo.png)
## 登录绕过
### 背景
现在除了开放出来的第三方接口，其他接口都需要走登录认证。
但是第三方接口不多，开放出来的能力有限，但是登录的接口又需要登录，非常的麻烦。
因此，新增了一个登录绕过的功能，为一些紧急临时的需求，提供一个调用不需要登录的能力。
### 使用方式
步骤一：接口调用时，在header中，增加如下信息：
```shell
# 表示开启登录绕过
Trick-Login-Switch : on
# 登录绕过的用户, 这里可以是admin, 或者是其他的, 但是必须在运维管控->平台管理->用户管理中设置了该用户。
Trick-Login-User : admin
```
&nbsp;
步骤二：在运维管控->平台管理->平台配置上，设置允许了该用户以绕过的方式登录
```shell
# 设置的key，必须是这个
SECURITY.TRICK_USERS
# 设置的value，是json数组的格式，例如
[ "admin", "logi"]
```
&nbsp;
步骤三：解释说明
设置完成上面两步之后，就可以直接调用需要登录的接口了。
但是还有一点需要注意，绕过的用户仅能调用他有权限的接口，比如一个普通用户，那么他就只能调用普通的接口，不能去调用运维人员的接口。

39
docs/dev_guide/周期任务说明文档.md
View File

@@ -1,39 +0,0 @@
---
![kafka-manager-logo](../assets/images/common/logo_name.png)
**一站式`Apache Kafka`集群指标监控与运维管控平台**
---
| 定时任务名称或方法名 | 所在类 | 详细说明 | cron | cron说明 | 线程数量 |
| -------------------------------------- | -------------------------------------- | ------------------------------------------ | --------------- | --------------------------------------- | -------- |
| calKafkaBill | CalKafkaTopicBill | 计算Kafka使用账单 | 0 0 1 * * ？ | 每天凌晨1点执行一次 | 1 |
| calRegionCapacity | CalRegionCapacity | 计算Region容量 | 0 0 0/12 * * ？ | 每隔12小时执行一次，在0分钟0秒时触发 | 1 |
| calTopicStatistics | CalTopicStatistics | 定时计算Topic统计数据 | 0 0 0/4 * * ? | 每隔4小时执行一次，在0分钟0秒时触发 | 5 |
| flushBrokerTable | FlushBrokerTable | 定时刷新BrokerTable数据 | 0 0 0/1 * * ? | 每隔1小时执行一次，在0分钟0秒时触发 | 1 |
| flushExpiredTopic | FlushExpiredTopic | 定期更新过期Topic | 0 0 0/5 * * ? | 每隔5小时执行一次，在0分钟0秒时触发 | 1 |
| syncClusterTaskState | SyncClusterTaskState | 同步更新集群任务状态 | 0 0/1 * * * ? | 每隔1分钟执行一次，在每分钟的0秒时触发 | 1 |
| newCollectAndPublishCGData | CollectAndPublishCGData | 收集并发布消费者指标数据 | 30 0/1 * * * ? | 每隔1分钟执行一次，在每分钟的30秒时触发 | 10 |
| collectAndPublishCommunityTopicMetrics | CollectAndPublishCommunityTopicMetrics | Topic社区指标收集 | 31 0/1 * * * ? | 每隔1分钟执行一次，在每分钟的30秒时触发 | 5 |
| collectAndPublishTopicThrottledMetrics | CollectAndPublishTopicThrottledMetrics | 收集和发布Topic限流信息 | 11 0/1 * * * ? | 每隔1分钟执行一次，在每分钟的11秒时触发 | 5 |
| deleteMetrics | DeleteMetrics | 定期删除Metrics信息 | 0 0/2 * * * ? | 每隔2分钟执行一次，在每分钟的0秒时触发 | 1 |
| storeDiDiAppTopicMetrics | StoreDiDiAppTopicMetrics | JMX中获取appId维度的流量信息存DB | 41 0/1 * * * ? | 每隔1分钟执行一次，在每分钟的41秒时触发 | 5 |
| storeDiDiTopicRequestTimeMetrics | StoreDiDiTopicRequestTimeMetrics | JMX中获取的TopicRequestTimeMetrics信息存DB | 51 0/1 * * * ? | 每隔1分钟执行一次，在每分钟的51秒时触发 | 5 |
| autoHandleTopicOrder | AutoHandleTopicOrder | 定时自动处理Topic相关工单 | 0 0/1 * * * ? | 每隔1分钟执行一次，在每分钟的0秒时触发 | 1 |
| automatedHandleOrder | AutomatedHandleOrder | 工单自动化审批 | 0 0/1 * * * ? | 每隔1分钟执行一次，在每分钟的0秒时触发 | 1 |
| flushReassignment | FlushReassignment | 定时处理分区迁移任务 | 0 0/1 * * * ? | 每隔1分钟执行一次，在每分钟的0秒时触发 | 1 |
| syncTopic2DB | SyncTopic2DB | 定期将未落盘的Topic刷新到DB中 | 0 0/2 * * * ? | 每隔2分钟执行一次，在每分钟的0秒时触发 | 1 |
| sinkCommunityTopicMetrics2Monitor | SinkCommunityTopicMetrics2Monitor | 定时上报Topic监控指标 | 1 0/1 * * * ? | 每隔1分钟执行一次，在每分钟的1秒时触发 | 5 |
| flush方法 | LogicalClusterMetadataManager | 定时刷新逻辑集群元数据到缓存中 | 0/30 * * * * ? | 每隔30秒执行一次 | 1 |
| flush方法 | AccountServiceImpl | 定时刷新account信息到缓存中 | 0/5 * * * * ? | 每隔5秒执行一次 | 1 |
| ipFlush方法 | HeartBeat | 定时获取管控平台所在机器IP等信息到DB | 0/10 * * * * ? | 每隔10秒执行一次 | 1 |
| flushTopicMetrics方法 | FlushTopicMetrics | 定时刷新topic指标到缓存中 | 5 0/1 * * * ? | 每隔1分钟执行一次，在每分钟的5秒时触发 | 1 |
| schedule方法 | FlushBKConsumerGroupMetadata | 定时刷新broker上消费组信息到缓存中 | 15 0/1 * * * ? | 每隔1分钟执行一次，在每分钟的15秒时触发 | 1 |
| flush方法 | FlushClusterMetadata | 定时刷新物理集群元信息到缓存中 | 0/30 * * * * ? | 每隔30秒执行一次 | 1 |
| flush方法 | FlushTopicProperties | 定时刷新物理集群配置到缓存中 | 25 0/1 * * * ? | 每隔1分钟执行一次，在每分钟的25秒时触发 | 1 |
| schedule方法 | FlushZKConsumerGroupMetadata | 定时刷新zk上的消费组信息到缓存中 | 35 0/1 * * * ? | 每隔1分钟执行一次，在每分钟的35秒时触发 | 1 |

42
docs/dev_guide/多版本兼容方案.md Normal file
View File

@@ -0,0 +1,42 @@
## 3.2、Kafka 多版本兼容方案
&emsp;&emsp;当前 KnowStreaming 支持纳管多个版本的 kafka 集群，由于不同版本的 kafka 在指标采集、接口查询、行为操作上有些不一致，因此 KnowStreaming 需要一套机制来解决多 kafka 版本的纳管兼容性问题。
### 3.2.1、整体思路
&emsp;&emsp;由于需要纳管多个 kafka 版本，而且未来还可能会纳管非 kafka 官方的版本，kafka 的版本号会存在着多种情况，所以首先要明确一个核心思想：KnowStreaming 提供尽可能多的纳管能力，但是不提供无限的纳管能力，每一个版本的 KnowStreaming 只纳管其自身声明的 kafka 版本，后续随着 KnowStreaming 自身版本的迭代，会逐步支持更多 kafka 版本的纳管接入。
### 3.2.2、构建版本兼容列表
&emsp;&emsp;每一个版本的 KnowStreaming 都声明一个自身支持纳管的 kafka 版本列表，并且对 kafka 的版本号进行归一化处理，后续所有 KnowStreaming 对不同 kafka 集群的操作都和这个集群对应的版本号严格相关。
&emsp;&emsp;KnowStreaming 对外提供自身所支持的 kafka 版本兼容列表，用以声明自身支持的版本范围。
&emsp;&emsp;对于在集群接入过程中，如果希望接入当前 KnowStreaming 不支持的 kafka 版本的集群，KnowStreaming 建议在于的过程中选择相近的版本号接入。
### 3.2.3、构建版本兼容性字典
&emsp;&emsp;在构建了 KnowStreaming 支持的 kafka 版本列表的基础上，KnowStreaming 在实现过程中，还会声明自身支持的所有兼容性，构建兼容性字典。
&emsp;&emsp;当前 KnowStreaming 支持的 kafka 版本兼容性字典包括三个维度：
- 指标采集：同一个指标在不同 kafka 版本下可能获取的方式不一样，不同版本的 kafka 可能会有不同的指标，因此对于指标采集的处理需要构建兼容性字典。
- kafka api：同一个 kafka 的操作处理的方式在不同 kafka 版本下可能存在不一致，如：topic 的创建，因此 KnowStreaming 针对不同 kafka-api 的处理需要构建兼容性字典。
- 平台操作：KnowStreaming 在接入不同版本的 kafka 集群的时候，在平台页面上会根据不同的 kafka 版。
兼容性字典的核心设计字段如下：
| 兼容性维度 | 兼容项名称 | 最小 Kafka 版本号（归一化） | 最大 Kafka 版本号（归一化） | 处理器 |
| ---------- | ---------- | --------------------------- | --------------------------- | ------ |
KS-KM 根据其需要纳管的 kafka 版本，按照上述三个维度构建了完善了兼容性字典。
### 3.2.4、兼容性问题
&emsp;&emsp;KS-KM 的每个版本针对需要纳管的 kafka 版本列表，事先分析各个版本的差异性和产品需求，同时 KS-KM 构建了一套专门处理兼容性的服务，来进行兼容性的注册、字典构建、处理器分发等操作，其中版本兼容性处理器是来具体处理不同 kafka 版本差异性的地方。
​ ![registerHandler](./assets/multi_version_compatible/registerHandler.png)
&emsp;&emsp;如上图所示，KS-KM 的 topic 服务在面对不同 kafka 版本时，其 topic 的创建、删除、扩容由于 kafka 版本自身的差异，导致 KnowStreaming 的处理也不一样，所以需要根据不同的 kafka 版本来实现不同的兼容性处理器，同时向 KnowStreaming 的兼容服务进行兼容性的注册，构建兼容性字典，后续在 KnowStreaming 的运行过程中，针对不同的 kafka 版本即可分发到不同的处理器中执行。
&emsp;&emsp;后续随着 KnowStreaming 产品的发展，如果有新的兼容性的地方需要增加，只需要实现新版本的处理器，增加注册项即可。

89
docs/dev_guide/如何使用集群安装部署功能.md
View File

@@ -1,89 +0,0 @@
---
![kafka-manager-logo](../assets/images/common/logo_name.png)
**一站式`Apache Kafka`集群指标监控与运维管控平台**
---
# 如何使用集群安装部署功能？
[TOC]
## 1、实现原理
![KCM实现原理](./assets/kcm/kcm_principle.png)
- LogiKM上传安装包到S3服务；
- LogiKM调用夜莺-Job服务接口，创建执行[kcm_script.sh](https://github.com/didi/LogiKM/blob/master/kafka-manager-extends/kafka-manager-kcm/src/main/resources/kcm_script.sh)脚本的任务，kcm_script.sh脚本是安装部署Kafka集群的脚本；
- 夜莺将任务脚本下发到具体的机器上，通过夜莺Agent执行该脚本；
- kcm_script.sh脚本会进行Kafka-Broker的安装部署；
---
## 2、使用方式
### 2.1、第一步：修改配置
**配置application.yml文件**
```yaml
#
kcm:
enabled: false # 是否开启，将其修改为true
s3: # s3 存储服务
endpoint: s3.didiyunapi.com
access-key: 1234567890
secret-key: 0987654321
bucket: logi-kafka
n9e: # 夜莺
base-url: http://127.0.0.1:8004 # 夜莺job服务地址
user-token: 12345678 # 用户的token
timeout: 300 # 单台操作的超时时间
account: root # 操作时使用的账号
script-file: kcm_script.sh # 脚本，已内置好，在源码的kcm模块内，此处配置无需修改
logikm-url: http://127.0.0.1:8080 # logikm部署地址，部署时kcm_script.sh会调用logikm检查部署中的一些状态，这里只需要填写 http://IP:PORT 就可以了
account:
jump-login:
gateway-api: false # 网关接口
third-part-api: false # 第三方接口，将其修改为true，即允许未登录情况下调用开放的第三方接口
```
### 2.2、第二步：检查服务
**检查s3服务**
- 测试 "运维管控-》集群运维-》版本管理" 页面的上传，查看等功能是否都正常。如果存在不正常，则需要查看s3的配置是否正确；
- 如果都没有问题，则上传Kafka的以.tgz结尾的安装包以及server.properties文件；
**检查夜莺Job服务**
- 创建一个job任务，机器选择需要安装Kafka集群的机器，然后执行的命令是echo "Hello LogiKM"，看能否被成功执行。如果不行，则需要检查夜莺的安装；
- 如果没有问题则表示夜莺和所需部署的机器之间的交互是没有问题的；
### 2.3、第三步：接入集群
在LogiKM的 “运维管控-》集群列表” 中接入需要安装部署的集群，**PS：此时是允许接入一个没有任何Broker的空的Kafka集群**，其中对的bootstrapServers配置搭建完成后的Kafka集群地址就可以了，而ZK地址必须和集群的server.properties中的ZK地址保持一致；
### 2.4、第四步：部署集群
- 打开LogiKM的 “运维管控-》集群运维-》集群任务” 页面，点击 “新建集群任务” 按钮；
- 选择集群、任务类型、包版本、server配置及填写主机列表，然后点击确认，即可在夜莺的Job服务中心中创建一个任务出来。**PS：如果创建失败，可以看一下日志我为什么创建失败**；
- 随后可以点击详情及状态对任务进行操作；
### 2.5、可能问题
#### 2.5.1、问题一：任务执行超时、失败等
进入夜莺Job服务中心，查看对应的任务的相关日志；
- 提示安装包下载失败，则需要查看对应的s3服务是否可以直接wget下载安装包，如果不可以则需要对kcm_script.sh脚本进行修改；
- 提示调用LogiKM失败，则可以使用postman手动测试一下kcm_script.sh脚本调用LogiKM的那个接口是否有问题，如果存在问题则进行相应的修改；PS：具体接口见kcm_script.sh脚本
## 3、备注说明
- 集群安装部署，仅安装部署Kafka-Broker，不安装Kafka的ZK服务；
- 安装部署中，有任何定制化的需求，例如修改安装的目录等，可以通过修改kcm_script.sh脚本实现；
- kcm_script.sh脚本位置：[kcm_script.sh](https://github.com/didi/LogiKM/blob/master/kafka-manager-extends/kafka-manager-kcm/src/main/resources/kcm_script.sh)；

53
docs/dev_guide/如何增加上报监控系统指标.md
View File

@@ -1,53 +0,0 @@
---
![kafka-manager-logo](../assets/images/common/logo_name.png)
**一站式`Apache Kafka`集群指标监控与运维管控平台**
---
# 如何增加上报监控系统指标？
## 0、前言
LogiKM是 **一站式`Apache Kafka`集群指标监控与运维管控平台** ，当前会将消费Lag，Topic流量等指标上报到监控系统中，从而方便用户在监控系统中对这些指标配置监控告警规则，进而达到监控自身客户端是否正常的目的。
那么，如果我们想增加一个新的监控指标，应该如何做呢，比如我们想监控Broker的流量，监控Broker的存活信息，监控集群Controller个数等等。
在具体介绍之前，我们大家都知道，Kafka监控相关的信息，基本都存储于Broker、Jmx以及ZK中。当前LogiKM也已经具备从这三个地方获取数据的基本能力，因此基于LogiKM我们再获取其他指标，总体上还是非常方便的。
这里我们就以已经获取到的Topic流量信息为例，看LogiKM如何实现Topic指标的获取并上报的。
---
## 1、确定指标位置
基于对Kafka的了解，我们知道Topic流量信息这个指标是存储于Jmx中的，因此我们需要从Jmx中获取。大家如果对于自己所需要获取的指标存储在何处不太清楚的，可以加入我们维护的Kafka中文社区(README中有二维码)中今天沟通交流。
---
## 2、指标获取
Topic流量指标的获取详细见图中说明。
![Topic流量指标采集说明](./assets/increase_the_indicators_reported_to_monitor_system/collect_topic_metrics.jpg)
---
## 3、指标上报
上一步我们已经采集到Topic流量指标了，下一步就是将该指标上报到监控系统，这块只需要按照监控系统要求的格式，将数据上报即可。
LogiKM中有一个monitor模块，具体的如下图所示：
![指标上报](./assets/increase_the_indicators_reported_to_monitor_system/sink_metrcis.png)
## 4、补充说明
监控系统对接的相关内容见：
[监控系统集成](./monitor_system_integrate_with_self.md)
[监控系统集成例子——集成夜莺](./monitor_system_integrate_with_n9e.md)

152
docs/dev_guide/指标说明.md Normal file
View File

@@ -0,0 +1,152 @@
## 2.3、指标说明
&emsp;&emsp;当前 KnowStreaming 支持针对 kafka 集群的多维度指标的采集和展示，同时也支持多个 kafka 版本的指标进行兼容，以下是 KnowStreaming 支持的指标说明。
&emsp;&emsp;现在对当前 KnowStreaming 支持的指标从指标名称、指标单位、指标说明、kafka 版本四个维度进行说明。
### 2.3.1、Cluster 指标
| 指标名称 | 指标单位 | 指标含义 | kafka 版本 | 企业/开源版指标 |
| ------------------------- | -------- | ------------------------------------ | ---------------- | --------------- |
| HealthScore | 分 | 集群总体的健康分 | 全部版本 | 开源版 |
| HealthCheckPassed | 个 | 集群总体健康检查通过数 | 全部版本 | 开源版 |
| HealthCheckTotal | 个 | 集群总体健康检查总数 | 全部版本 | 开源版 |
| HealthScore_Topics | 分 | 集群 Topics 的健康分 | 全部版本 | 开源版 |
| HealthCheckPassed_Topics | 个 | 集群 Topics 健康检查通过数 | 全部版本 | 开源版 |
| HealthCheckTotal_Topics | 个 | 集群 Topics 健康检查总数 | 全部版本 | 开源版 |
| HealthScore_Brokers | 分 | 集群 Brokers 的健康分 | 全部版本 | 开源版 |
| HealthCheckPassed_Brokers | 个 | 集群 Brokers 健康检查通过数 | 全部版本 | 开源版 |
| HealthCheckTotal_Brokers | 个 | 集群 Brokers 健康检查总数 | 全部版本 | 开源版 |
| HealthScore_Groups | 分 | 集群 Groups 的健康分 | 全部版本 | 开源版 |
| HealthCheckPassed_Groups | 个 | 集群 Groups 健康检查总数 | 全部版本 | 开源版 |
| HealthCheckTotal_Groups | 个 | 集群 Groups 健康检查总数 | 全部版本 | 开源版 |
| HealthScore_Cluster | 分 | 集群自身的健康分 | 全部版本 | 开源版 |
| HealthCheckPassed_Cluster | 个 | 集群自身健康检查通过数 | 全部版本 | 开源版 |
| HealthCheckTotal_Cluster | 个 | 集群自身健康检查总数 | 全部版本 | 开源版 |
| TotalRequestQueueSize | 个 | 集群中总的请求队列数 | 全部版本 | 开源版 |
| TotalResponseQueueSize | 个 | 集群中总的响应队列数 | 全部版本 | 开源版 |
| EventQueueSize | 个 | 集群中 Controller 的 EventQueue 大小 | 2.0.0 及以上版本 | 开源版 |
| ActiveControllerCount | 个 | 集群中存活的 Controller 数 | 全部版本 | 开源版 |
| TotalProduceRequests | 个 | 集群中的 Produce 每秒请求数 | 全部版本 | 开源版 |
| TotalLogSize | byte | 集群总的已使用的磁盘大小 | 全部版本 | 开源版 |
| ConnectionsCount | 个 | 集群的连接(Connections)个数 | 全部版本 | 开源版 |
| Zookeepers | 个 | 集群中存活的 zk 节点个数 | 全部版本 | 开源版 |
| ZookeepersAvailable | 是/否 | ZK 地址是否合法 | 全部版本 | 开源版 |
| Brokers | 个 | 集群的 broker 的总数 | 全部版本 | 开源版 |
| BrokersAlive | 个 | 集群的 broker 的存活数 | 全部版本 | 开源版 |
| BrokersNotAlive | 个 | 集群的 broker 的未存活数 | 全部版本 | 开源版 |
| Replicas | 个 | 集群中 Replica 的总数 | 全部版本 | 开源版 |
| Topics | 个 | 集群中 Topic 的总数 | 全部版本 | 开源版 |
| Partitions | 个 | 集群的 Partitions 总数 | 全部版本 | 开源版 |
| PartitionNoLeader | 个 | 集群中的 PartitionNoLeader 总数 | 全部版本 | 开源版 |
| PartitionMinISR_S | 个 | 集群中的小于 PartitionMinISR 总数 | 全部版本 | 开源版 |
| PartitionMinISR_E | 个 | 集群中的等于 PartitionMinISR 总数 | 全部版本 | 开源版 |
| PartitionURP | 个 | 集群中的未同步的 Partition 总数 | 全部版本 | 开源版 |
| MessagesIn | 条/s | 集群每条消息写入条数 | 全部版本 | 开源版 |
| Messages | 条 | 集群总的消息条数 | 全部版本 | 开源版 |
| LeaderMessages | 条 | 集群中 leader 总的消息条数 | 全部版本 | 开源版 |
| BytesIn | byte/s | 集群的每秒写入字节数 | 全部版本 | 开源版 |
| BytesIn_min_5 | byte/s | 集群的每秒写入字节数，5 分钟均值 | 全部版本 | 开源版 |
| BytesIn_min_15 | byte/s | 集群的每秒写入字节数，15 分钟均值 | 全部版本 | 开源版 |
| BytesOut | byte/s | 集群的每秒流出字节数 | 全部版本 | 开源版 |
| BytesOut_min_5 | byte/s | 集群的每秒流出字节数，5 分钟均值 | 全部版本 | 开源版 |
| BytesOut_min_15 | byte/s | 集群的每秒流出字节数，15 分钟均值 | 全部版本 | 开源版 |
| Groups | 个 | 集群中 Group 的总数 | 全部版本 | 开源版 |
| GroupActives | 个 | 集群中 ActiveGroup 的总数 | 全部版本 | 开源版 |
| GroupEmptys | 个 | 集群中 EmptyGroup 的总数 | 全部版本 | 开源版 |
| GroupRebalances | 个 | 集群中 RebalanceGroup 的总数 | 全部版本 | 开源版 |
| GroupDeads | 个 | 集群中 DeadGroup 的总数 | 全部版本 | 开源版 |
| Alive | 是/否 | 集群是否存活，1：存活；0：没有存活 | 全部版本 | 开源版 |
| AclEnable | 是/否 | 集群是否开启 Acl，1：是；0：否 | 全部版本 | 开源版 |
| Acls | 个 | ACL 数 | 全部版本 | 开源版 |
| AclUsers | 个 | ACL-KafkaUser 数 | 全部版本 | 开源版 |
| AclTopics | 个 | ACL-Topic 数 | 全部版本 | 开源版 |
| AclGroups | 个 | ACL-Group 数 | 全部版本 | 开源版 |
| Jobs | 个 | 集群任务总数 | 全部版本 | 开源版 |
| JobsRunning | 个 | 集群 running 任务总数 | 全部版本 | 开源版 |
| JobsWaiting | 个 | 集群 waiting 任务总数 | 全部版本 | 开源版 |
| JobsSuccess | 个 | 集群 success 任务总数 | 全部版本 | 开源版 |
| JobsFailed | 个 | 集群 failed 任务总数 | 全部版本 | 开源版 |
| LoadReBalanceEnable | 是/否 | 是否开启均衡, 1：是；0：否 | 全部版本 | 企业版 |
| LoadReBalanceCpu | 是/否 | CPU 是否均衡, 1：是；0：否 | 全部版本 | 企业版 |
| LoadReBalanceNwIn | 是/否 | BytesIn 是否均衡, 1：是；0：否 | 全部版本 | 企业版 |
| LoadReBalanceNwOut | 是/否 | BytesOut 是否均衡, 1：是；0：否 | 全部版本 | 企业版 |
| LoadReBalanceDisk | 是/否 | Disk 是否均衡, 1：是；0：否 | 全部版本 | 企业版 |
### 2.3.2、Broker 指标
| 指标名称 | 指标单位 | 指标含义 | kafka 版本 | 企业/开源版指标 |
| ----------------------- | -------- | ------------------------------------- | ---------- | --------------- |
| HealthScore | 分 | Broker 健康分 | 全部版本 | 开源版 |
| HealthCheckPassed | 个 | Broker 健康检查通过数 | 全部版本 | 开源版 |
| HealthCheckTotal | 个 | Broker 健康检查总数 | 全部版本 | 开源版 |
| TotalRequestQueueSize | 个 | Broker 的请求队列大小 | 全部版本 | 开源版 |
| TotalResponseQueueSize | 个 | Broker 的应答队列大小 | 全部版本 | 开源版 |
| ReplicationBytesIn | byte/s | Broker 的副本流入流量 | 全部版本 | 开源版 |
| ReplicationBytesOut | byte/s | Broker 的副本流出流量 | 全部版本 | 开源版 |
| MessagesIn | 条/s | Broker 的每秒消息流入条数 | 全部版本 | 开源版 |
| TotalProduceRequests | 个/s | Broker 上 Produce 的每秒请求数 | 全部版本 | 开源版 |
| NetworkProcessorAvgIdle | % | Broker 的网络处理器的空闲百分比 | 全部版本 | 开源版 |
| RequestHandlerAvgIdle | % | Broker 上请求处理器的空闲百分比 | 全部版本 | 开源版 |
| PartitionURP | 个 | Broker 上的未同步的副本的个数 | 全部版本 | 开源版 |
| ConnectionsCount | 个 | Broker 上网络链接的个数 | 全部版本 | 开源版 |
| BytesIn | byte/s | Broker 的每秒数据写入量 | 全部版本 | 开源版 |
| BytesIn_min_5 | byte/s | Broker 的每秒数据写入量，5 分钟均值 | 全部版本 | 开源版 |
| BytesIn_min_15 | byte/s | Broker 的每秒数据写入量，15 分钟均值 | 全部版本 | 开源版 |
| BytesOut | byte/s | Broker 的每秒数据流出量 | 全部版本 | 开源版 |
| BytesOut_min_5 | byte/s | Broker 的每秒数据流出量，5 分钟均值 | 全部版本 | 开源版 |
| BytesOut_min_15 | byte/s | Broker 的每秒数据流出量，15 分钟均值 | 全部版本 | 开源版 |
| ReassignmentBytesIn | byte/s | Broker 的每秒数据迁移写入量 | 全部版本 | 开源版 |
| ReassignmentBytesOut | byte/s | Broker 的每秒数据迁移流出量 | 全部版本 | 开源版 |
| Partitions | 个 | Broker 上的 Partition 个数 | 全部版本 | 开源版 |
| PartitionsSkew | % | Broker 上的 Partitions 倾斜度 | 全部版本 | 开源版 |
| Leaders | 个 | Broker 上的 Leaders 个数 | 全部版本 | 开源版 |
| LeadersSkew | % | Broker 上的 Leaders 倾斜度 | 全部版本 | 开源版 |
| LogSize | byte | Broker 上的消息容量大小 | 全部版本 | 开源版 |
| Alive | 是/否 | Broker 是否存活，1：存活；0：没有存活 | 全部版本 | 开源版 |
### 2.3.3、Topic 指标
| 指标名称 | 指标单位 | 指标含义 | kafka 版本 | 企业/开源版指标 |
| --------------------- | -------- | ------------------------------------- | ---------- | --------------- |
| HealthScore | 分 | 健康分 | 全部版本 | 开源版 |
| HealthCheckPassed | 个 | 健康项检查通过数 | 全部版本 | 开源版 |
| HealthCheckTotal | 个 | 健康项检查总数 | 全部版本 | 开源版 |
| TotalProduceRequests | 条/s | Topic 的 TotalProduceRequests | 全部版本 | 开源版 |
| BytesRejected | 个/s | Topic 的每秒写入拒绝量 | 全部版本 | 开源版 |
| FailedFetchRequests | 个/s | Topic 的 FailedFetchRequests | 全部版本 | 开源版 |
| FailedProduceRequests | 个/s | Topic 的 FailedProduceRequests | 全部版本 | 开源版 |
| ReplicationCount | 个 | Topic 总的副本数 | 全部版本 | 开源版 |
| Messages | 条 | Topic 总的消息数 | 全部版本 | 开源版 |
| MessagesIn | 条/s | Topic 每秒消息条数 | 全部版本 | 开源版 |
| BytesIn | byte/s | Topic 每秒消息写入字节数 | 全部版本 | 开源版 |
| BytesIn_min_5 | byte/s | Topic 每秒消息写入字节数，5 分钟均值 | 全部版本 | 开源版 |
| BytesIn_min_15 | byte/s | Topic 每秒消息写入字节数，15 分钟均值 | 全部版本 | 开源版 |
| BytesOut | byte/s | Topic 每秒消息流出字节数 | 全部版本 | 开源版 |
| BytesOut_min_5 | byte/s | Topic 每秒消息流出字节数，5 分钟均值 | 全部版本 | 开源版 |
| BytesOut_min_15 | byte/s | Topic 每秒消息流出字节数，15 分钟均值 | 全部版本 | 开源版 |
| LogSize | byte | Topic 的大小 | 全部版本 | 开源版 |
| PartitionURP | 个 | Topic 未同步的副本数 | 全部版本 | 开源版 |
### 2.3.4、Partition 指标
| 指标名称 | 指标单位 | 指标含义 | kafka 版本 | 企业/开源版指标 |
| -------------- | -------- | ----------------------------------------- | ---------- | --------------- |
| LogEndOffset | 条 | Partition 中 leader 副本的 LogEndOffset | 全部版本 | 开源版 |
| LogStartOffset | 条 | Partition 中 leader 副本的 LogStartOffset | 全部版本 | 开源版 |
| Messages | 条 | Partition 总的消息数 | 全部版本 | 开源版 |
| BytesIn | byte/s | Partition 的每秒消息流入字节数 | 全部版本 | 开源版 |
| BytesOut | byte/s | Partition 的每秒消息流出字节数 | 全部版本 | 开源版 |
| LogSize | byte | Partition 的大小 | 全部版本 | 开源版 |
### 2.3.5、Group 指标
| 指标名称 | 指标单位 | 指标含义 | kafka 版本 | 企业/开源版指标 |
| ----------------- | -------- | -------------------------- | ---------- | --------------- |
| HealthScore | 分 | 健康分 | 全部版本 | 开源版 |
| HealthCheckPassed | 个 | 健康检查通过数 | 全部版本 | 开源版 |
| HealthCheckTotal | 个 | 健康检查总数 | 全部版本 | 开源版 |
| OffsetConsumed | 条 | Consumer 的 CommitedOffset | 全部版本 | 开源版 |
| LogEndOffset | 条 | Consumer 的 LogEndOffset | 全部版本 | 开源版 |
| Lag | 条 | Group 消费者的 Lag 数 | 全部版本 | 开源版 |
| State | 个 | Group 组的状态 | 全部版本 | 开源版 |

87
docs/dev_guide/本地源码启动手册.md Normal file
View File

@@ -0,0 +1,87 @@
## 6.1、本地源码启动手册
### 6.1.1、打包方式
`Know Streaming` 采用前后端分离的开发模式，使用 Maven 对项目进行统一的构建管理。maven 在打包构建过程中，会将前后端代码一并打包生成最终的安装包。
`Know Streaming` 除了使用安装包启动之外，还可以通过本地源码启动完整的带前端页面的项目，下面我们正式开始介绍本地源码如何启动 `Know Streaming`。
### 6.1.2、环境要求
**系统支持**
`windows7+`、`Linux`、`Mac`
**环境依赖**
- Maven 3.6.3
- Node v12.20.0
- Java 8+
- MySQL 5.7
- Idea
- Elasticsearch 7.6
### 6.1.3、环境初始化
安装好环境信息之后，还需要初始化 MySQL 与 Elasticsearch 信息，包括：
- 初始化 MySQL 表及数据
- 初始化 Elasticsearch 索引
具体见：[快速开始](./1-quick-start.md) 中的最后一步，部署 KnowStreaming 服务中的初始化相关工作。
### 6.1.4、本地启动
**第一步：本地打包**
执行 `mvn install` 可对项目进行前后端同时进行打包，通过该命令，除了可以对后端进行打包之外，还可以将前端相关的静态资源文件也一并打包出来。
**第二步：修改配置**
```yaml
# 修改 km-rest/src/main/resources/application.yml 中相关的配置
# 修改MySQL的配置，中间省略了一些非必需修改的配置
spring:
datasource:
know-streaming:
jdbc-url: 修改为实际MYSQL地址
username: 修改为实际MYSQL用户名
password: 修改为实际MYSQL密码
logi-job:
jdbc-url: 修改为实际MYSQL地址
username: 修改为实际MYSQL用户名
password: 修改为实际MYSQL密码
logi-security:
jdbc-url: 修改为实际MYSQL地址
username: 修改为实际MYSQL用户名
password: 修改为实际MYSQL密码
# 修改ES的配置，中间省略了一些非必需修改的配置
es.client.address: 修改为实际ES地址
```
**第三步：配置 IDEA**
`Know streaming`的 Main 方法在：
```java
km-rest/src/main/java/com/xiaojukeji/know/streaming/km/rest/KnowStreaming.java
```
IDEA 更多具体的配置如下图所示：
![IDEA配置](./assets/startup_using_source_code/IDEA配置.jpg)
**第四步：启动项目**
最后就是启动项目，在本地 console 中输出了 `KnowStreaming-KM started` 则表示我们已经成功启动 `Know streaming` 了。
### 6.1.5、本地访问
`Know streaming` 启动之后，可以访问一些信息，包括：
- 产品页面：http://localhost:8080 ，默认账号密码：`admin` / `admin2022_` 进行登录。
- 接口地址：http://localhost:8080/swagger-ui.html 查看后端提供的相关接口。
更多信息，详见：[KnowStreaming 官网](http://116.85.24.211/)

114
docs/dev_guide/登录系统对接.md Normal file
View File

@@ -0,0 +1,114 @@
![Logo](../assets/KnowStreamingLogo.png)
## 登录系统对接
### 前言
KnowStreaming 除了实现基于本地MySQL的用户登录认证方式外，还实现了基于Ldap的登录认证。
但是，登录认证系统并非仅此两种，因此本文将介绍 KnowStreaming 如何对接自有的用户登录认证系统。
下面我们正式开始介绍登录系统的对接。
### 如何对接？
- 实现Log-Common中的LoginService的三个接口即可；
```Java
// LoginService三个方法
public interface LoginService {
/**
* 验证登录信息，同时记住登录状态
*/
UserBriefVO verifyLogin(AccountLoginDTO loginDTO, HttpServletRequest request, HttpServletResponse response) throws LogiSecurityException;
/**
* 登出接口，清楚登录状态
*/
Result<Boolean> logout(HttpServletRequest request, HttpServletResponse response);
/**
* 检查是否已经登录
*/
boolean interceptorCheck(HttpServletRequest request, HttpServletResponse response,
String requestMappingValue,
List<String> whiteMappingValues) throws IOException;
}
```
没错，登录就是如此的简单，仅仅只需要实现上述的三个接口即可。说了半天，具体如何做呢，能不能给个例子？
### 有没有例子？
我们以Ldap对接为例，说明KnowStreaming如何对接登录认证系统。
```Java
// 继承 LoginService 接口
public class LdapLoginServiceImpl implements LoginService {
private static final Logger LOGGER = LoggerFactory.getLogger(LdapLoginServiceImpl.class);
// Ldap校验
@Autowired
private LdapAuthentication ldapAuthentication;
@Override
public UserBriefVO verifyLogin(AccountLoginDTO loginDTO,
HttpServletRequest request,
HttpServletResponse response) throws LogiSecurityException {
String decodePasswd = AESUtils.decrypt(loginDTO.getPw());
// 去LDAP验证账密
LdapPrincipal ldapAttrsInfo = ldapAuthentication.authenticate(loginDTO.getUserName(), decodePasswd);
if (ldapAttrsInfo == null) {
// 用户不存在，正常来说上如果有问题，上一步会直接抛出异常
throw new LogiSecurityException(ResultCode.USER_NOT_EXISTS);
}
// 进行业务相关操作
// 记录登录状态，Ldap因为无法记录登录状态，因此有KnowStreaming进行记录
initLoginContext(request, response, loginDTO.getUserName(), user.getId());
return CopyBeanUtil.copy(user, UserBriefVO.class);
}
@Override
public Result<Boolean> logout(HttpServletRequest request, HttpServletResponse response) {
request.getSession().invalidate();
response.setStatus(REDIRECT_CODE);
return Result.buildSucc(Boolean.TRUE);
}
@Override
public boolean interceptorCheck(HttpServletRequest request, HttpServletResponse response, String requestMappingValue, List<String> whiteMappingValues) throws IOException {
// 其他处理
// 检查是否已经登录
String userName = HttpRequestUtil.getOperator(request);
if (StringUtils.isEmpty(userName)) {
// 未登录，则进行登出
logout(request, response);
return Boolean.FALSE;
}
// 其他业务处理
return Boolean.TRUE;
}
}
```
### 背后原理是？
- KnowStreaming 会拦截所有的接口请求；
- 拦截到请求之后，如果是登录的请求，则调用LoginService.verifyLogin();
- 拦截到请求之后，如果是登出的请求，则调用LoginService.logout();
- 拦截到请求之后，如果是其他请求，则调用LoginService.interceptorCheck();

20
docs/dev_guide/connect_jmx_failed.md → docs/dev_guide/解决连接JMX失败.md
View File

@@ -1,14 +1,14 @@
---
![Logo](../assets/KnowStreamingLogo.png)
![kafka-manager-logo](../assets/images/common/logo_name.png)
**一站式`Apache Kafka`集群指标监控与运维管控平台**
---
## JMX-连接失败问题解决
- [JMX-连接失败问题解决](#jmx-连接失败问题解决)
- [1、问题&说明](#1问题说明)
- [2、解决方法](#2解决方法)
- [3、解决方法 —— 认证的JMX](#3解决方法--认证的jmx)
集群正常接入Logi-KafkaManager之后，即可以看到集群的Broker列表，此时如果查看不了Topic的实时流量，或者是Broker的实时流量信息时，那么大概率就是JMX连接的问题了。
下面我们按照步骤来一步一步的检查。
@@ -29,7 +29,6 @@
- `JMX`配置错误：见`2、解决方法`。
- 存在防火墙或者网络限制：网络通的另外一台机器`telnet`试一下看是否可以连接上。
- 需要进行用户名及密码的认证：见`3、解决方法 —— 认证的JMX`。
- 当logikm和kafka不在同一台机器上时,kafka的Jmx端口不允许其他机器访问:见`4、解决方法`。
错误日志例子：
@@ -99,9 +98,4 @@ fi
SQL的例子：
```sql
UPDATE cluster SET jmx_properties='{ "maxConn": 10, "username": "xxxxx", "password": "xxxx", "openSSL": false }' where id={xxx};
```
### 4、解决方法 —— 不允许其他机器访问
![1971b46243fe1d547063ee55b1505ed](https://user-images.githubusercontent.com/2869938/154413486-f6531946-8c4c-447e-aa2e-b112e5e623d6.png)
该图中的127.0.0.1表明该端口只允许本机访问.
在cdh中可以点击配置->搜索jmx->寻找broker_java_opts 修改com.sun.management.jmxremote.host和java.rmi.server.hostname为本机ip
```