mirror of
https://github.com/didi/KnowStreaming.git
synced 2025-12-24 11:52:08 +08:00
初始化3.0.0版本
This commit is contained in:
zengqiao
BIN
docs/assets/KnowStreamingLogo.png
Normal file
BIN
docs/assets/KnowStreamingLogo.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 41 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 73 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 7.4 KiB |
BIN
docs/assets/readme/KnowStreamingPageDemo.jpg
Normal file
BIN
docs/assets/readme/KnowStreamingPageDemo.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 183 KiB |
BIN
docs/assets/readme/WeChat.png
Normal file
BIN
docs/assets/readme/WeChat.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 50 KiB |
BIN
docs/assets/readme/ZSXQ.jpg
Normal file
BIN
docs/assets/readme/ZSXQ.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 96 KiB |
@@ -1,47 +0,0 @@
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
**一站式`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进行打包
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 270 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 785 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 2.5 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 69 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 589 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 652 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 511 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 672 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 600 KiB |
BIN
docs/dev_guide/assets/startup_using_source_code/IDEA配置.jpg
Normal file
BIN
docs/dev_guide/assets/startup_using_source_code/IDEA配置.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 228 KiB |
@@ -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="调用夜莺接口，<br>创建集群安装部署任务" 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的安装包，<br>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)；<br>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(<font color="#ff3333">代理执行kcm_script.sh脚本</font>)" 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>
|
||||
@@ -1,169 +0,0 @@
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
**一站式`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_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流量多少钱
|
||||
}
|
||||
```
|
||||
@@ -1,10 +0,0 @@
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
**一站式`Apache Kafka`集群指标监控与运维管控平台**
|
||||
|
||||
---
|
||||
|
||||
# Kafka-Gateway 配置说明
|
||||
@@ -1,42 +0,0 @@
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
**一站式`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: 用户资源中心地址
|
||||
```
|
||||
|
||||
@@ -1,54 +0,0 @@
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
**一站式`Apache Kafka`集群指标监控与运维管控平台**
|
||||
|
||||
---
|
||||
|
||||
# 监控系统集成
|
||||
|
||||
- 监控系统默认与 [夜莺] (https://github.com/didi/nightingale) 进行集成；
|
||||
- 对接自有的监控系统需要进行简单的二次开发，即实现部分监控告警模块的相关接口即可；
|
||||
- 集成会有两块内容，一个是指标数据上报的集成，还有一个是监控告警规则的集成；
|
||||
|
||||
## 1、指标数据上报集成
|
||||
|
||||
仅完成这一步的集成之后，即可将监控数据上报到监控系统中，此时已能够在自己的监控系统进行监控告警规则的配置了。
|
||||
|
||||
**步骤一：实现指标上报的接口**
|
||||
|
||||
- 按照自己内部监控系统的数据格式要求，将数据进行组装成符合自己内部监控系统要求的数据进行上报，具体的可以参考夜莺集成的实现代码。
|
||||
- 至于会上报哪些指标，可以查看有哪些地方调用了该接口。
|
||||
|
||||
|
||||
|
||||
**步骤二：相关配置修改**
|
||||
|
||||
|
||||
|
||||
**步骤三：开启上报任务**
|
||||
|
||||
|
||||
|
||||
|
||||
## 2、监控告警规则集成
|
||||
|
||||
完成**1、指标数据上报集成**之后，即可在自己的监控系统进行监控告警规则的配置了。完成该步骤的集成之后，可以在`Logi-KafkaManager`中进行监控告警规则的增删改查等等。
|
||||
|
||||
大体上和**1、指标数据上报集成**一致，
|
||||
|
||||
**步骤一：实现相关接口**
|
||||
|
||||
|
||||
|
||||
实现完成步骤一之后，接下来的步骤和**1、指标数据上报集成**中的步骤二、步骤三一致，都需要进行相关配置的修改即可。
|
||||
|
||||
|
||||
## 3、总结
|
||||
|
||||
简单介绍了一下监控告警的集成，嫌麻烦的同学可以仅做 **1、指标数据上报集成** 这一节的内容即可满足一定场景下的需求。
|
||||
|
||||
|
||||
**集成过程中，有任何觉得文档没有说清楚的地方或者建议，欢迎入群交流，也欢迎贡献代码，觉得好也辛苦给个star。**
|
||||
@@ -1,41 +0,0 @@
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
**一站式`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
98
docs/dev_guide/健康巡检.md
Normal file
@@ -0,0 +1,98 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
# 健康巡检
|
||||
|
||||
## 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、自定义增强
|
||||
|
||||
如何增加想要的巡检？
|
||||
|
||||
@@ -1,15 +1,9 @@
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
## 登录绕过
|
||||
|
||||
**一站式`Apache Kafka`集群指标监控与运维管控平台**
|
||||
|
||||
---
|
||||
|
||||
# 登录绕过
|
||||
|
||||
## 背景
|
||||
### 背景
|
||||
|
||||
现在除了开放出来的第三方接口，其他接口都需要走登录认证。
|
||||
|
||||
@@ -17,7 +11,7 @@
|
||||
|
||||
因此，新增了一个登录绕过的功能，为一些紧急临时的需求，提供一个调用不需要登录的能力。
|
||||
|
||||
## 使用方式
|
||||
### 使用方式
|
||||
|
||||
步骤一：接口调用时，在header中，增加如下信息：
|
||||
```shell
|
||||
@@ -1,39 +0,0 @@
|
||||
---
|
||||
|
||||
|
||||
|
||||
**一站式`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
42
docs/dev_guide/多版本兼容方案.md
Normal file
@@ -0,0 +1,42 @@
|
||||
## 3.2、Kafka 多版本兼容方案
|
||||
|
||||
  当前 KnowStreaming 支持纳管多个版本的 kafka 集群，由于不同版本的 kafka 在指标采集、接口查询、行为操作上有些不一致，因此 KnowStreaming 需要一套机制来解决多 kafka 版本的纳管兼容性问题。
|
||||
|
||||
### 3.2.1、整体思路
|
||||
|
||||
  由于需要纳管多个 kafka 版本，而且未来还可能会纳管非 kafka 官方的版本，kafka 的版本号会存在着多种情况，所以首先要明确一个核心思想：KnowStreaming 提供尽可能多的纳管能力，但是不提供无限的纳管能力，每一个版本的 KnowStreaming 只纳管其自身声明的 kafka 版本，后续随着 KnowStreaming 自身版本的迭代，会逐步支持更多 kafka 版本的纳管接入。
|
||||
|
||||
### 3.2.2、构建版本兼容列表
|
||||
|
||||
  每一个版本的 KnowStreaming 都声明一个自身支持纳管的 kafka 版本列表，并且对 kafka 的版本号进行归一化处理，后续所有 KnowStreaming 对不同 kafka 集群的操作都和这个集群对应的版本号严格相关。
|
||||
|
||||
  KnowStreaming 对外提供自身所支持的 kafka 版本兼容列表，用以声明自身支持的版本范围。
|
||||
|
||||
  对于在集群接入过程中，如果希望接入当前 KnowStreaming 不支持的 kafka 版本的集群，KnowStreaming 建议在于的过程中选择相近的版本号接入。
|
||||
|
||||
### 3.2.3、构建版本兼容性字典
|
||||
|
||||
  在构建了 KnowStreaming 支持的 kafka 版本列表的基础上，KnowStreaming 在实现过程中，还会声明自身支持的所有兼容性，构建兼容性字典。
|
||||
|
||||
  当前 KnowStreaming 支持的 kafka 版本兼容性字典包括三个维度：
|
||||
|
||||
- 指标采集：同一个指标在不同 kafka 版本下可能获取的方式不一样，不同版本的 kafka 可能会有不同的指标，因此对于指标采集的处理需要构建兼容性字典。
|
||||
- kafka api：同一个 kafka 的操作处理的方式在不同 kafka 版本下可能存在不一致，如：topic 的创建，因此 KnowStreaming 针对不同 kafka-api 的处理需要构建兼容性字典。
|
||||
- 平台操作：KnowStreaming 在接入不同版本的 kafka 集群的时候，在平台页面上会根据不同的 kafka 版。
|
||||
|
||||
兼容性字典的核心设计字段如下：
|
||||
|
||||
| 兼容性维度 | 兼容项名称 | 最小 Kafka 版本号（归一化） | 最大 Kafka 版本号（归一化） | 处理器 |
|
||||
| ---------- | ---------- | --------------------------- | --------------------------- | ------ |
|
||||
|
||||
KS-KM 根据其需要纳管的 kafka 版本，按照上述三个维度构建了完善了兼容性字典。
|
||||
|
||||
### 3.2.4、兼容性问题
|
||||
|
||||
  KS-KM 的每个版本针对需要纳管的 kafka 版本列表，事先分析各个版本的差异性和产品需求，同时 KS-KM 构建了一套专门处理兼容性的服务，来进行兼容性的注册、字典构建、处理器分发等操作，其中版本兼容性处理器是来具体处理不同 kafka 版本差异性的地方。
|
||||
|
||||
|
||||
|
||||
  如上图所示，KS-KM 的 topic 服务在面对不同 kafka 版本时，其 topic 的创建、删除、扩容由于 kafka 版本自身的差异，导致 KnowStreaming 的处理也不一样，所以需要根据不同的 kafka 版本来实现不同的兼容性处理器，同时向 KnowStreaming 的兼容服务进行兼容性的注册，构建兼容性字典，后续在 KnowStreaming 的运行过程中，针对不同的 kafka 版本即可分发到不同的处理器中执行。
|
||||
|
||||
  后续随着 KnowStreaming 产品的发展，如果有新的兼容性的地方需要增加，只需要实现新版本的处理器，增加注册项即可。
|
||||
@@ -1,89 +0,0 @@
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
**一站式`Apache Kafka`集群指标监控与运维管控平台**
|
||||
|
||||
---
|
||||
|
||||
# 如何使用集群安装部署功能？
|
||||
|
||||
[TOC]
|
||||
|
||||
## 1、实现原理
|
||||
|
||||
|
||||
|
||||
- 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)；
|
||||
@@ -1,53 +0,0 @@
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
**一站式`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流量指标的获取详细见图中说明。
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 3、指标上报
|
||||
|
||||
上一步我们已经采集到Topic流量指标了，下一步就是将该指标上报到监控系统，这块只需要按照监控系统要求的格式，将数据上报即可。
|
||||
|
||||
LogiKM中有一个monitor模块，具体的如下图所示：
|
||||
|
||||
|
||||
|
||||
|
||||
## 4、补充说明
|
||||
|
||||
监控系统对接的相关内容见：
|
||||
|
||||
[监控系统集成](./monitor_system_integrate_with_self.md)
|
||||
|
||||
[监控系统集成例子——集成夜莺](./monitor_system_integrate_with_n9e.md)
|
||||
152
docs/dev_guide/指标说明.md
Normal file
152
docs/dev_guide/指标说明.md
Normal file
@@ -0,0 +1,152 @@
|
||||
## 2.3、指标说明
|
||||
|
||||
  当前 KnowStreaming 支持针对 kafka 集群的多维度指标的采集和展示，同时也支持多个 kafka 版本的指标进行兼容，以下是 KnowStreaming 支持的指标说明。
|
||||
|
||||
  现在对当前 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
87
docs/dev_guide/本地源码启动手册.md
Normal 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 更多具体的配置如下图所示：
|
||||
|
||||
|
||||
|
||||
**第四步：启动项目**
|
||||
|
||||
最后就是启动项目，在本地 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
114
docs/dev_guide/登录系统对接.md
Normal file
@@ -0,0 +1,114 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 登录系统对接
|
||||
|
||||
### 前言
|
||||
|
||||
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();
|
||||
@@ -1,14 +1,14 @@
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
**一站式`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、解决方法 —— 不允许其他机器访问
|
||||
|
||||
|
||||
该图中的127.0.0.1表明该端口只允许本机访问.
|
||||
在cdh中可以点击配置->搜索jmx->寻找broker_java_opts 修改com.sun.management.jmxremote.host和java.rmi.server.hostname为本机ip
|
||||
```
|
||||
@@ -1,107 +0,0 @@
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
**一站式`Apache Kafka`集群指标监控与运维管控平台**
|
||||
|
||||
---
|
||||
|
||||
# 配置说明
|
||||
|
||||
```yaml
|
||||
server:
|
||||
port: 8080 # 服务端口
|
||||
tomcat:
|
||||
accept-count: 1000
|
||||
max-connections: 10000
|
||||
max-threads: 800
|
||||
min-spare-threads: 100
|
||||
|
||||
spring:
|
||||
application:
|
||||
name: kafkamanager
|
||||
datasource:
|
||||
kafka-manager: # 数据库连接配置
|
||||
jdbc-url: jdbc:mysql://127.0.0.1:3306/kafka_manager?characterEncoding=UTF-8&serverTimezone=GMT%2B8 #数据库的地址
|
||||
username: admin # 用户名
|
||||
password: admin # 密码
|
||||
driver-class-name: com.mysql.jdbc.Driver
|
||||
main:
|
||||
allow-bean-definition-overriding: true
|
||||
|
||||
profiles:
|
||||
active: dev # 启用的配置
|
||||
servlet:
|
||||
multipart:
|
||||
max-file-size: 100MB
|
||||
max-request-size: 100MB
|
||||
|
||||
logging:
|
||||
config: classpath:logback-spring.xml
|
||||
|
||||
custom:
|
||||
idc: cn # 部署的数据中心, 忽略该配置, 后续会进行删除
|
||||
jmx:
|
||||
max-conn: 10 # 和单台 broker 的最大JMX连接数
|
||||
store-metrics-task:
|
||||
community:
|
||||
broker-metrics-enabled: true # 社区部分broker metrics信息收集开关, 关闭之后metrics信息将不会进行收集及写DB
|
||||
topic-metrics-enabled: true # 社区部分topic的metrics信息收集开关, 关闭之后metrics信息将不会进行收集及写DB
|
||||
didi:
|
||||
app-topic-metrics-enabled: false # 滴滴埋入的指标, 社区AK不存在该指标，因此默认关闭
|
||||
topic-request-time-metrics-enabled: false # 滴滴埋入的指标, 社区AK不存在该指标，因此默认关闭
|
||||
topic-throttled-metrics-enabled: false # 滴滴埋入的指标, 社区AK不存在该指标，因此默认关闭
|
||||
save-days: 7 #指标在DB中保持的天数，-1表示永久保存，7表示保存近7天的数据
|
||||
|
||||
# 任务相关的开关
|
||||
task:
|
||||
op:
|
||||
sync-topic-enabled: false # 未落盘的Topic定期同步到DB中
|
||||
order-auto-exec: # 工单自动化审批线程的开关
|
||||
topic-enabled: false # Topic工单自动化审批开关, false:关闭自动化审批, true:开启
|
||||
app-enabled: false # App工单自动化审批开关, false:关闭自动化审批, true:开启
|
||||
|
||||
account: # ldap相关的配置, 社区版本暂时支持不够完善，可以先忽略，欢迎贡献代码对这块做优化
|
||||
ldap:
|
||||
|
||||
kcm: # 集群升级部署相关的功能，需要配合夜莺及S3进行使用，这块我们后续专门补充一个文档细化一下，牵扯到kcm_script.sh脚本的修改
|
||||
enabled: false # 默认关闭
|
||||
storage:
|
||||
base-url: http://127.0.0.1 # 存储地址
|
||||
n9e:
|
||||
base-url: http://127.0.0.1:8004 # 夜莺任务中心的地址
|
||||
user-token: 12345678 # 夜莺用户的token
|
||||
timeout: 300 # 集群任务的超时时间，单位秒
|
||||
account: root # 集群任务使用的账号
|
||||
script-file: kcm_script.sh # 集群任务的脚本
|
||||
|
||||
monitor: # 监控告警相关的功能，需要配合夜莺进行使用
|
||||
enabled: false # 默认关闭，true就是开启
|
||||
n9e:
|
||||
nid: 2
|
||||
user-token: 1234567890
|
||||
mon:
|
||||
# 夜莺 mon监控服务 地址
|
||||
base-url: http://127.0.0.1:8032
|
||||
sink:
|
||||
# 夜莺 transfer上传服务 地址
|
||||
base-url: http://127.0.0.1:8006
|
||||
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: 用户资源中心地址
|
||||
|
||||
notify: # 通知的功能
|
||||
kafka: # 默认通知发送到kafka的指定Topic中
|
||||
cluster-id: 95 # Topic的集群ID
|
||||
topic-name: didi-kafka-notify # Topic名称
|
||||
order: # 部署的KM的地址
|
||||
detail-url: http://127.0.0.1
|
||||
```
|
||||
@@ -1,93 +0,0 @@
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
**一站式`Apache Kafka`集群指标监控与运维管控平台**
|
||||
|
||||
---
|
||||
|
||||
# 安装手册
|
||||
|
||||
## 1、环境依赖
|
||||
|
||||
如果是以Release包进行安装的，则仅安装`Java`及`MySQL`即可。如果是要先进行源码包进行打包，然后再使用，则需要安装`Maven`及`Node`环境。
|
||||
|
||||
- `Java 8+`(运行环境需要)
|
||||
- `MySQL 5.7`(数据存储)
|
||||
- `Maven 3.5+`(后端打包依赖)
|
||||
- `Node 10+`(前端打包依赖)
|
||||
|
||||
---
|
||||
|
||||
## 2、获取安装包
|
||||
|
||||
**1、Release直接下载**
|
||||
|
||||
这里如果觉得麻烦，然后也不想进行二次开发，则可以直接下载Release包，下载地址：[Github Release包下载地址](https://github.com/didi/Logi-KafkaManager/releases)
|
||||
|
||||
如果觉得Github的下载地址太慢了，也可以进入`Logi-KafkaManager`的用户群获取，群地址在README中。
|
||||
|
||||
|
||||
**2、源代码进行打包**
|
||||
|
||||
下载好代码之后，进入`Logi-KafkaManager`的主目录，执行`mvn -Prelease-kafka-manager -Dmaven.test.skip=true clean install -U `命令即可，
|
||||
执行完成之后会在`distribution/target`目录下面生成一个`kafka-manager-*.tar.gz`。
|
||||
和一个`kafka-manager-*.zip` 文件,随便任意一个压缩包都可以;
|
||||
当然此时同级目录有一个已经解压好的文件夹;
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 3. 解压安装包
|
||||
解压完成后; 在文件目录中可以看到有`kafka-manager/conf/create_mysql_table.sql` 有个mysql初始化文件
|
||||
先初始化DB
|
||||
|
||||
|
||||
## 4、MySQL-DB初始化
|
||||
|
||||
执行[create_mysql_table.sql](../../distribution/conf/create_mysql_table.sql)中的SQL命令，从而创建所需的MySQL库及表，默认创建的库名是`logi_kafka_manager`。
|
||||
|
||||
```
|
||||
# 示例：
|
||||
mysql -uXXXX -pXXX -h XXX.XXX.XXX.XXX -PXXXX < ./create_mysql_table.sql
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5.修该配置
|
||||
请将`conf/application.yml.example` 文件复制一份出来命名为`application.yml` 放在同级目录:conf/application.yml ;
|
||||
并且修改配置; 当然不修改的话 就会用默认的配置;
|
||||
至少 mysql配置成自己的吧
|
||||
|
||||
|
||||
## 6、启动/关闭
|
||||
解压包中有启动和关闭脚本
|
||||
`kafka-manager/bin/shutdown.sh`
|
||||
`kafka-manager/bin/startup.sh`
|
||||
|
||||
执行 sh startup.sh 启动
|
||||
执行 sh shutdown.sh 关闭
|
||||
|
||||
|
||||
|
||||
### 6、使用
|
||||
|
||||
本地启动的话，访问`http://localhost:8080`，输入帐号及密码(默认`admin/admin`)进行登录。更多参考：[kafka-manager 用户使用手册](../user_guide/user_guide_cn.md)
|
||||
|
||||
### 7. 升级
|
||||
|
||||
如果是升级版本,请查看文件 [kafka-manager 升级手册](../../distribution/upgrade_config.md)
|
||||
在您下载的启动包(V2.5及其后)中也有记录,在 kafka-manager/upgrade_config.md 中
|
||||
|
||||
|
||||
### 8. 在IDE中启动
|
||||
> 如果想参与开发或者想在IDE中启动的话
|
||||
> 先执行 `mvn -Dmaven.test.skip=true clean install -U `
|
||||
>
|
||||
> 然后这个时候可以选择去 [pom.xml](../../pom.xml) 中将`kafka-manager-console`模块注释掉;
|
||||
> 注释是因为每次install的时候都会把前端文件`kafka-manager-console`重新打包进`kafka-manager-web`
|
||||
>
|
||||
> 完事之后,只需要直接用IDE启动运行`kafka-manager-web`模块中的
|
||||
> com.xiaojukeji.kafka.manager.web.MainApplication main方法就行了
|
||||
@@ -1,132 +0,0 @@
|
||||
---
|
||||
|
||||
|
||||
|
||||
**一站式`Apache Kafka`集群指标监控与运维管控平台**
|
||||
|
||||
---
|
||||
|
||||
|
||||
## 基于Docker部署Logikm
|
||||
|
||||
为了方便用户快速的在自己的环境搭建Logikm，可使用docker快速搭建
|
||||
|
||||
### 部署Mysql
|
||||
|
||||
```shell
|
||||
docker run --name mysql -p 3306:3306 -d registry.cn-hangzhou.aliyuncs.com/zqqq/logikm-mysql:5.7.37
|
||||
```
|
||||
|
||||
可选变量参考[文档](https://hub.docker.com/_/mysql)
|
||||
|
||||
默认参数
|
||||
|
||||
* MYSQL_ROOT_PASSWORD：root
|
||||
|
||||
|
||||
|
||||
### 部署Logikm Allinone
|
||||
|
||||
> 前后端部署在一起
|
||||
|
||||
```shell
|
||||
docker run --name logikm -p 8080:8080 --link mysql -d registry.cn-hangzhou.aliyuncs.com/zqqq/logikm:2.6.0
|
||||
```
|
||||
|
||||
参数详解：
|
||||
|
||||
* -p 映射容器8080端口至宿主机的8080
|
||||
* --link 连接mysql容器
|
||||
|
||||
|
||||
|
||||
### 部署前后端分离
|
||||
|
||||
#### 部署后端 Logikm-backend
|
||||
|
||||
```shell
|
||||
docker run --name logikm-backend --link mysql -d registry.cn-hangzhou.aliyuncs.com/zqqq/logikm-backend:2.6.0
|
||||
```
|
||||
|
||||
可选参数：
|
||||
|
||||
* -e LOGI_MYSQL_HOST mysql连接地址，默认mysql
|
||||
* -e LOGI_MYSQL_PORT mysql端口，默认3306
|
||||
* -e LOGI_MYSQL_DATABASE 数据库，默认logi_kafka_manager
|
||||
* -e LOGI_MYSQL_USER mysql用户名，默认root
|
||||
* -e LOGI_MYSQL_PASSWORD mysql密码，默认root
|
||||
|
||||
#### 部署前端 Logikm-front
|
||||
|
||||
```shell
|
||||
docker run --name logikm-front -p 8088:80 --link logikm-backend -d registry.cn-hangzhou.aliyuncs.com/zqqq/logikm-front:2.6.0
|
||||
```
|
||||
|
||||
|
||||
|
||||
### Logi后端可配置参数
|
||||
|
||||
docker run 运行参数 -e 可指定环境变量如下
|
||||
|
||||
| 环境变量 | 变量解释 | 默认值 |
|
||||
| ------------------- | ------------- | ------------------ |
|
||||
| LOGI_MYSQL_HOST | mysql连接地址 | mysql |
|
||||
| LOGI_MYSQL_PORT | mysql端口 | 3306 |
|
||||
| LOGI_MYSQL_DATABASE | 数据库 | logi_kafka_manager |
|
||||
| LOGI_MYSQL_USER | mysql用户名 | root |
|
||||
| LOGI_MYSQL_PASSWORD | mysql密码 | root |
|
||||
|
||||
|
||||
|
||||
|
||||
## 基于Docker源码构建
|
||||
|
||||
根据此文档用户可自行通过Docker 源码构建 Logikm
|
||||
|
||||
### 构建Mysql
|
||||
|
||||
```shell
|
||||
docker build -t mysql:{TAG} -f container/dockerfiles/mysql/Dockerfile container/dockerfiles/mysql
|
||||
```
|
||||
|
||||
### 构建Allinone
|
||||
|
||||
将前后端打包在一起
|
||||
|
||||
```shell
|
||||
docker build -t logikm:{TAG} .
|
||||
```
|
||||
|
||||
可选参数 --build-arg ：
|
||||
|
||||
* MAVEN_VERSION maven镜像tag
|
||||
* JAVA_VERSION java镜像tag
|
||||
|
||||
|
||||
|
||||
### 构建前后端分离
|
||||
|
||||
前后端分离打包
|
||||
|
||||
#### 构建后端
|
||||
|
||||
```shell
|
||||
docker build --build-arg CONSOLE_ENABLE=false -t logikm-backend:{TAG} .
|
||||
```
|
||||
|
||||
参数：
|
||||
|
||||
* MAVEN_VERSION maven镜像tag
|
||||
* JAVA_VERSION java镜像tag
|
||||
|
||||
* CONSOLE_ENABLE=false 不构建console模块
|
||||
|
||||
#### 构建前端
|
||||
|
||||
```shell
|
||||
docker build -t logikm-front:{TAG} -f kafka-manager-console/Dockerfile kafka-manager-console
|
||||
```
|
||||
|
||||
可选参数：
|
||||
|
||||
* --build-arg：OUTPUT_PATH 修改默认打包输出路径，默认当前目录下的dist
|
||||
@@ -1,94 +0,0 @@
|
||||
---
|
||||
|
||||
|
||||
|
||||
**一站式`Apache Kafka`集群指标监控与运维管控平台**
|
||||
|
||||
---
|
||||
|
||||
## nginx配置-安装手册
|
||||
|
||||
# 一、独立部署
|
||||
|
||||
请参考参考：[kafka-manager 安装手册](install_guide_cn.md)
|
||||
|
||||
# 二、nginx配置
|
||||
|
||||
## 1、独立部署配置
|
||||
|
||||
```
|
||||
#nginx 根目录访问配置如下
|
||||
location / {
|
||||
proxy_pass http://ip:port;
|
||||
}
|
||||
```
|
||||
|
||||
## 2、前后端分离&配置多个静态资源
|
||||
|
||||
以下配置解决`nginx代理多个静态资源`，实现项目前后端分离，版本更新迭代。
|
||||
|
||||
### 1、源码下载
|
||||
|
||||
根据所需版本下载对应代码，下载地址：[Github 下载地址](https://github.com/didi/Logi-KafkaManager)
|
||||
|
||||
### 2、修改webpack.config.js 配置文件
|
||||
|
||||
修改`kafka-manager-console`模块 `webpack.config.js`
|
||||
以下所有<font color='red'>xxxx</font>为nginx代理路径和打包静态文件加载前缀,<font color='red'>xxxx</font>可根据需求自行更改。
|
||||
|
||||
```
|
||||
cd kafka-manager-console
|
||||
vi webpack.config.js
|
||||
|
||||
# publicPath默认打包方式根目录下，修改为nginx代理访问路径。
|
||||
let publicPath = '/xxxx';
|
||||
```
|
||||
|
||||
### 3、打包
|
||||
|
||||
```
|
||||
|
||||
npm cache clean --force && npm install
|
||||
|
||||
```
|
||||
|
||||
ps：如果打包过程中报错，运行`npm install clipboard@2.0.6`，相反请忽略！
|
||||
|
||||
### 4、部署
|
||||
|
||||
#### 1、前段静态文件部署
|
||||
|
||||
静态资源 `../kafka-manager-web/src/main/resources/templates`
|
||||
|
||||
上传到指定目录，目前以`root目录`做demo
|
||||
|
||||
#### 2、上传jar包并启动，请参考：[kafka-manager 安装手册](install_guide_cn.md)
|
||||
|
||||
#### 3、修改nginx 配置
|
||||
|
||||
```
|
||||
location /xxxx {
|
||||
# 静态文件存放位置
|
||||
alias /root/templates;
|
||||
try_files $uri $uri/ /xxxx/index.html;
|
||||
index index.html;
|
||||
}
|
||||
|
||||
location /api {
|
||||
proxy_pass http://ip:port;
|
||||
}
|
||||
#后代端口建议使用/api，如果冲突可以使用以下配置
|
||||
#location /api/v2 {
|
||||
# proxy_pass http://ip:port;
|
||||
#}
|
||||
#location /api/v1 {
|
||||
# proxy_pass http://ip:port;
|
||||
#}
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
237
docs/install_guide/单机部署手册.md
Normal file
237
docs/install_guide/单机部署手册.md
Normal file
@@ -0,0 +1,237 @@
|
||||
## 前言
|
||||
|
||||
- 本文以 Centos7 系统为例，系统基础配置要求：4 核 8G
|
||||
- 按照本文可以快速部署一套单机模式的 KnowStreaming 环境
|
||||
- 本文以 v3.0.0-bete 版本为例进行部署，如需其他版本请关注[官网](https://knowstreaming.com/)
|
||||
- 部署完成后可以通过浏览器输入 IP:PORT 进行访问，默认用户名密码: admin/admin2022\_
|
||||
- KnowStreaming 同样支持分布式集群模式，如需部署高可用集群，[请联系我们](https://knowstreaming.com/support-center)
|
||||
|
||||
## 1.1、软件版本及依赖
|
||||
|
||||
| 软件名 | 版本要求 | 默认端口 |
|
||||
| ------------- | -------- | -------- |
|
||||
| Mysql | v5.7+ | 3306 |
|
||||
| Elasticsearch | v6+ | 8060 |
|
||||
| JDK | v8+ | - |
|
||||
| Centos | v6+ | - |
|
||||
| Ubantu | v16+ | - |
|
||||
|
||||
## 1.2、部署方式选择
|
||||
|
||||
- Shell 部署（单机版本）
|
||||
|
||||
- 容器化部署（需准备 K8S 环境）
|
||||
|
||||
- 根据操作手册进行手动部署
|
||||
|
||||
## 1.3、Shell 部署
|
||||
|
||||
### 1.3.1、在线方式安装
|
||||
|
||||
#在服务器中下载安装脚本,脚本中会重新安装Mysql
|
||||
wget https://s3-gzpu.didistatic.com/pub/knowstreaming/deploy_KnowStreaming.sh
|
||||
|
||||
#执行脚本
|
||||
sh deploy_KnowStreaming.sh
|
||||
|
||||
#访问测试
|
||||
127.0.0.1:8080
|
||||
|
||||
### 1.3.2、离线方式安装
|
||||
|
||||
#将安装包下载到本地且传输到目标服务器
|
||||
wget https://s3-gzpu.didistatic.com/pub/knowstreaming/KnowStreaming-3.0.0-beta—offline.tar.gz
|
||||
|
||||
#解压安装包
|
||||
tar -zxf KnowStreaming-3.0.0-beta—offline.tar.gz
|
||||
|
||||
#执行安装脚本
|
||||
sh deploy_KnowStreaming-offline.sh
|
||||
|
||||
#访问测试
|
||||
127.0.0.1:8080
|
||||
|
||||
## 1.4、容器化部署
|
||||
|
||||
### 1.4.1、环境依赖及版本要求
|
||||
|
||||
- Kubernetes >= 1.14 ，Helm >= 2.17.0
|
||||
|
||||
- 默认配置为全部安装（elasticsearch + mysql + knowstreaming）
|
||||
|
||||
- 如果使用已有的 elasticsearch(7.6.x) 和 mysql(5.7) 只需调整 values.yaml 部分参数即可
|
||||
|
||||
### 1.4.2、安装方式
|
||||
|
||||
#下载安装包
|
||||
wget https://s3-gzpu.didistatic.com/pub/knowstreaming/knowstreaming-3.0.0-hlem.tgz
|
||||
|
||||
#解压安装包
|
||||
tar -zxf knowstreaming-3.0.0-hlem.tgz
|
||||
|
||||
#执行命令(NAMESPACE需要更改为已存在的)
|
||||
helm install -n [NAMESPACE] knowstreaming knowstreaming-manager/
|
||||
|
||||
#获取KnowStreaming前端ui的service. 默认nodeport方式.(http://nodeIP:nodeport，默认用户名密码：admin/admin2022_)
|
||||
|
||||
## 1.5、手动部署
|
||||
|
||||
### 1.5.1、部署流程
|
||||
|
||||
基础依赖服务部署 ——> KnowStreaming 模块
|
||||
|
||||
### 1.5.2、基础依赖服务部署
|
||||
|
||||
#### 如现有环境中已经有相关服务，可跳过对其的安装
|
||||
|
||||
#### 基础依赖：JAVA11、Mysql、Elasticsearch
|
||||
|
||||
#### 1.5.2.1、安装 Mysql 服务
|
||||
|
||||
##### 1.5.2.1.1 yum 方式安装
|
||||
|
||||
#配置yum源
|
||||
wget https://dev.mysql.com/get/mysql57-community-release-el7-9.noarch.rpm
|
||||
rpm -ivh mysql57-community-release-el7-9.noarch.rpm
|
||||
|
||||
#执行安装
|
||||
yum -y install mysql-server mysql-client
|
||||
|
||||
#服务启动
|
||||
systemctl start mysqld
|
||||
|
||||
#获取初始密码并修改
|
||||
old_pass=`grep 'temporary password' /var/log/mysqld.log | awk '{print $NF}' | tail -n 1`
|
||||
|
||||
mysql -NBe "alter user USER() identified by 'Didi_km_678';" --connect-expired-password -uroot -p$old_pass
|
||||
|
||||
##### 1.5.2.1.2、rpm 包方式安装
|
||||
|
||||
#下载安装包
|
||||
wget https://s3-gzpu.didistatic.com/knowsearch/mysql5.7.tar.gz
|
||||
|
||||
#解压到指定目录
|
||||
tar -zxf mysql5.7.tar.gz -C /tmp/
|
||||
|
||||
#执行安装
|
||||
yum -y localinstall /tmp/libaio-*.rpm /tmp/mysql-*.rpm
|
||||
|
||||
#服务启动
|
||||
systemctl start mysqld
|
||||
|
||||
|
||||
#获取初始密码并修改
|
||||
old_pass=`grep 'temporary password' /var/log/mysqld.log | awk '{print $NF}' | tail -n 1`
|
||||
|
||||
mysql -NBe "alter user USER() identified by 'Didi_km_678';" --connect-expired-pa
|
||||
ssword -uroot -p$old_pass
|
||||
|
||||
#### 1.5.2.2、配置 JAVA 环境
|
||||
|
||||
#下载安装包
|
||||
wget https://s3-gzpu.didistatic.com/pub/jdk11.tar.gz #解压到指定目录
|
||||
tar -zxf jdk11.tar.gz -C /usr/local/ #更改目录名
|
||||
mv /usr/local/jdk-11.0.2 /usr/local/java11 #添加到环境变量
|
||||
echo "export JAVA_HOME=/usr/local/java11" >> ~/.bashrc
|
||||
echo "export CLASSPATH=/usr/java/java11/lib" >> ~/.bashrc
|
||||
echo "export PATH=\$JAVA_HOME/bin:\$PATH:\$HOME/bin" >> ~/.bashrc
|
||||
source ~/.bashrc
|
||||
|
||||
#### 1.5.2.3、Elasticsearch 实例搭建
|
||||
|
||||
#### Elasticsearch 元数据集群来支持平台核心指标数据的存储，如集群维度指标、节点维度指标等
|
||||
|
||||
#### 以下安装示例为单节点模式，如需集群部署可以参考[Elasticsearch 官方文档](https://www.elastic.co/guide/en/elasticsearch/reference/7.6/elasticsearch-intro.html)
|
||||
|
||||
#下载安装包
|
||||
wget https://s3-gzpu.didistatic.com/pub/elasticsearch.tar.gz
|
||||
|
||||
#创建ES数据存储目录
|
||||
mkdir -p /data/es_data
|
||||
|
||||
#创建ES所属用户
|
||||
useradd arius
|
||||
|
||||
#配置用户的打开文件数
|
||||
echo "arius soft nofile 655350" >>/etc/security/limits.conf
|
||||
echo "arius hard nofile 655350" >>/etc/security/limits.conf
|
||||
echo "vm.max_map_count = 655360" >>/etc/sysctl.conf
|
||||
sysctl -p
|
||||
|
||||
#解压安装包
|
||||
tar -zxf elasticsearch.tar.gz -C /data/
|
||||
|
||||
#更改目录所属组
|
||||
chown -R arius:arius /data/
|
||||
|
||||
#修改配置文件(参考以下配置)
|
||||
vim /data/elasticsearch/config/elasticsearch.yml
|
||||
cluster.name: km_es
|
||||
node.name: es-node1
|
||||
node.master: true
|
||||
node.data: true
|
||||
path.data: /data/es_data
|
||||
http.port: 8060
|
||||
discovery.seed_hosts: ["127.0.0.1:9300"]
|
||||
|
||||
#修改内存配置
|
||||
vim /data/elasticsearch/config/jvm.options
|
||||
-Xms2g
|
||||
-Xmx2g
|
||||
|
||||
#启动服务
|
||||
su - arius
|
||||
export JAVA_HOME=/usr/local/java11
|
||||
sh /data/elasticsearch/control.sh start
|
||||
|
||||
#确认状态
|
||||
sh /data/elasticsearch/control.sh status
|
||||
|
||||
### 1.5.3、KnowStreaming 服务部署
|
||||
|
||||
#### 以 KnowStreaming 为例
|
||||
|
||||
#下载安装包
|
||||
wget wget https://s3-gzpu.didistatic.com/pub/knowstreaming/KnowStreaming-3.0.0-beta.tar.gz
|
||||
|
||||
#解压安装包到指定目录
|
||||
tar -zxf KnowStreaming-3.0.0-beta.tar.gz -C /data/
|
||||
|
||||
#修改启动脚本并加入systemd管理
|
||||
cd /data/KnowStreaming/
|
||||
|
||||
#创建相应的库和导入初始化数据
|
||||
mysql -uroot -pDidi_km_678 -e "create database know_streaming;"
|
||||
mysql -uroot -pDidi_km_678 know_streaming < ./init/sql/ddl-ks-km.sql
|
||||
mysql -uroot -pDidi_km_678 know_streaming < ./init/sql/ddl-logi-job.sql
|
||||
mysql -uroot -pDidi_km_678 know_streaming < ./init/sql/ddl-logi-security.sql
|
||||
mysql -uroot -pDidi_km_678 know_streaming < ./init/sql/dml-ks-km.sql
|
||||
mysql -uroot -pDidi_km_678 know_streaming < ./init/sql/dml-logi.sql
|
||||
|
||||
#创建elasticsearch初始化数据
|
||||
sh ./init/template/template.sh
|
||||
|
||||
#修改配置文件
|
||||
vim ./conf/application.yml
|
||||
|
||||
#监听端口
|
||||
server:
|
||||
|
||||
port: 8080 # web 服务端口
|
||||
tomcat:
|
||||
accept-count: 1000
|
||||
max-connections: 10000
|
||||
|
||||
#elasticsearch地址
|
||||
es.client.address: 127.0.0.1:8060
|
||||
|
||||
#数据库配置（一共三处地方，修改正确的mysql地址和数据库名称以及用户名密码）
|
||||
jdbc-url: jdbc:mariadb://127.0.0.1:3306/know-streaming?.....
|
||||
username: root
|
||||
password: Didi_km_678
|
||||
|
||||
#启动服务
|
||||
cd /data/KnowStreaming/bin/
|
||||
sh startup.sh
|
||||
|
||||
#### 打开浏览器输入 IP 地址+端口测试(默认端口 8080)，用户名密码: admin/admin2022\_
|
||||
70
docs/install_guide/源码编译打包手册.md
Normal file
70
docs/install_guide/源码编译打包手册.md
Normal file
@@ -0,0 +1,70 @@
|
||||
|
||||
|
||||
|
||||
|
||||
# `Know Streaming` 源码编译打包手册
|
||||
|
||||
## 1、环境信息
|
||||
|
||||
**系统支持**
|
||||
|
||||
`windows7+`、`Linux`、`Mac`
|
||||
|
||||
**环境依赖**
|
||||
|
||||
- Maven 3.6.3 （后端）
|
||||
- Node v12.20.0/v14.17.3 （前端）
|
||||
- Java 8+ （后端）
|
||||
|
||||
## 2、编译打包
|
||||
|
||||
整个工程中，除了`km-console`为前端模块之外，其他模块都是后端工程相关模块。
|
||||
|
||||
因此，如果前后端合并打包，则打对整个工程进行打包；如果前端单独打包，则仅打包 `km-console` 中的代码；如果是仅需要后端打包，则在顶层 `pom.xml` 中去掉 `km-console`模块，然后进行打包。
|
||||
|
||||
具体见下面描述。
|
||||
|
||||
|
||||
|
||||
### 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、前端单独打包
|
||||
|
||||
1. 下载源码；
|
||||
2. 进入 `KS-KM/km-console` 工程目录；
|
||||
3. 执行 `npm run build`命令，会在 `KS-KM/km-console` 目录下生成一个名为 `pub` 的前端静态资源包；
|
||||
|
||||
|
||||
|
||||
### 2.3、后端单独打包
|
||||
|
||||
1. 下载源码；
|
||||
2. 修改顶层 `pom.xml` ，去掉其中的 `km-console` 模块，如下所示；
|
||||
```xml
|
||||
<modules>
|
||||
<!-- <module>km-console</module>-->
|
||||
<module>km-common</module>
|
||||
<module>km-persistence</module>
|
||||
<module>km-core</module>
|
||||
<module>km-biz</module>
|
||||
<module>km-extends/km-account</module>
|
||||
<module>km-extends/km-monitor</module>
|
||||
<module>km-extends/km-license</module>
|
||||
<module>km-extends/km-rebalance</module>
|
||||
<module>km-task</module>
|
||||
<module>km-collector</module>
|
||||
<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包也仅有后端服务的功能；
|
||||
|
||||
|
||||
|
||||
|
||||
37
docs/install_guide/版本升级手册.md
Normal file
37
docs/install_guide/版本升级手册.md
Normal file
@@ -0,0 +1,37 @@
|
||||
## 版本升级说明
|
||||
|
||||
### `2.x`版本 升级至 `3.0.0`版本
|
||||
|
||||
**升级步骤：**
|
||||
|
||||
1. 依旧使用**`2.x 版本的 DB`**，在上面初始化 3.0.0 版本所需数据库表结构及数据；
|
||||
2. 将 2.x 版本中的集群，在 3.0.0 版本，手动逐一接入；
|
||||
3. 将 Topic 业务数据，迁移至 3.0.0 表中，详见下方 SQL；
|
||||
|
||||
**注意事项**
|
||||
|
||||
- 建议升级 3.0.0 版本过程中，保留 2.x 版本的使用，待 3.0.0 版本稳定使用后，再下线 2.x 版本；
|
||||
- 3.0.0 版本仅需要`集群信息`及`Topic的描述信息`。2.x 版本的 DB 的其他数据 3.0.0 版本都不需要；
|
||||
- 部署 3.0.0 版本之后，集群、Topic 等指标数据都为空，3.0.0 版本会周期进行采集，运行一段时间之后就会有该数据了，因此不会将 2.x 中的指标数据进行迁移；
|
||||
|
||||
**迁移数据**
|
||||
|
||||
```sql
|
||||
-- 迁移Topic的备注信息。
|
||||
-- 需在 3.0.0 部署完成后，再执行该SQL。
|
||||
-- 考虑到 2.x 版本中还存在增量数据，因此建议改SQL周期执行，是的增量数据也能被迁移至 3.0.0 版本中。
|
||||
|
||||
UPDATE ks_km_topic
|
||||
INNER JOIN
|
||||
(SELECT
|
||||
topic.cluster_id AS cluster_id,
|
||||
topic.topic_name AS topic_name,
|
||||
topic.description AS description
|
||||
FROM topic WHERE description != ''
|
||||
) AS t
|
||||
|
||||
ON ks_km_topic.cluster_phy_id = t.cluster_id
|
||||
AND ks_km_topic.topic_name = t.topic_name
|
||||
AND ks_km_topic.id > 0
|
||||
SET ks_km_topic.description = t.description;
|
||||
```
|
||||
@@ -1,49 +0,0 @@
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
**一站式`Apache Kafka`集群指标监控与运维管控平台**
|
||||
|
||||
|
||||
---
|
||||
|
||||
# 集群接入
|
||||
|
||||
## 主要概念讲解
|
||||
面对大规模集群、业务场景复杂的情况，引入Region、逻辑集群的概念
|
||||
- Region：划分部分Broker作为一个 Region，用Region定义资源划分的单位，提高扩展性和隔离性。如果部分Topic异常也不会影响大面积的Broker
|
||||
- 逻辑集群：逻辑集群由部分Region组成，便于对大规模集群按照业务划分、保障能力进行管理
|
||||
|
||||
|
||||
集群的接入总共需要三个步骤，分别是：
|
||||
1. 接入物理集群：填写机器地址、安全协议等配置信息，接入真实的物理集群
|
||||
2. 创建Region：将部分Broker划分为一个Region
|
||||
3. 创建逻辑集群：逻辑集群由部分Region组成，可根据业务划分、保障等级来创建相应的逻辑集群
|
||||
|
||||
|
||||
|
||||
|
||||
**备注：接入集群需要2、3两步是因为普通用户的视角下，看到的都是逻辑集群，如果没有2、3两步，那么普通用户看不到任何信息。**
|
||||
|
||||
|
||||
## 1、接入物理集群
|
||||
|
||||
|
||||
|
||||
如上图所示，填写集群信息，然后点击确定，即可完成集群的接入。因为考虑到分布式部署，添加集群之后，需要稍等**`1分钟`**才可以在界面上看到集群的详细信息。
|
||||
|
||||
## 2、创建Region
|
||||
|
||||
|
||||
|
||||
如上图所示，填写Region信息，然后点击确定，即可完成Region的创建。
|
||||
|
||||
备注：Region即为Broker的集合，可以按照业务需要，将Broker归类，从而创建相应的Region。
|
||||
|
||||
## 3、创建逻辑集群
|
||||
|
||||
|
||||
|
||||
|
||||
如上图所示，填写逻辑集群信息，然后点击确定，即可完成逻辑集群的创建。
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 261 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 240 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 195 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 124 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 105 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 94 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 181 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 65 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 166 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 30 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 78 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 48 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 55 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 16 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 297 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 189 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 173 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 197 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 244 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 118 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 150 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 177 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 276 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 257 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 153 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 189 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 187 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 92 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 116 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 166 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 158 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 124 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 209 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 127 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 162 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 102 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 189 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 281 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 185 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 170 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 252 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 238 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 252 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 278 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 238 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 233 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 208 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 395 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 235 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 157 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 141 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 150 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 168 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 91 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 120 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 120 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 119 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 168 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 41 KiB |
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user