# RMDC-watchdog详细设计说明书

### 项目归属模块

1. 包含的模块及对应的目录
    1. wdd.io/RMDC/rmdc-project-management
    2. wdd.io/RMDC/rmdc-watchdog
    3. wdd.io/RMDC/rmdc-watchdog-agent
    4. wdd.io/RMDC/rmdc-watchdog-node

## 授权系统说明

```概述```

1. rmdc-project-management是一级授权中心
    1. 授权所有二级授权中心
    2. 维护二级授权中心的授权信息
    3. 该模块之前为 rmdc-watchdog-center
        1. 但是由于功能单一并且与rmdc-project-management功能冲突
        2. 该模块已被移除，并且功能完全移动至rmdc-project-management中实现
2. RMDC-watchdog作为项目授权中心(二级授权中心)
    1. 接受来自RMDC-watchdog-node的主机信息,唯一主机信息加密
    2. 将授权文件上传至rmdc-project-management
    3. 接受来自rmdc-project-management的授权文件,并解析授权信息
    4. 接受来自RMDC-watchdog-agent的心跳查询是否授权信息
    5. 向RMDC-watchdog-agent发送已授权信息,避免agent自毁
3. RMDC-watchdog-agent是嵌入到业务运行的启动器
    1. 监控业务运行的一切
    2. 向RMDC-watchdog发送心跳查询是否授权信息
    3. 若长时间未被授权,则自毁
    4. 解析RMDC-watchdog的心跳回复,确保不会自毁
    5. 设计方案类似于 死手系统
4. RMDC-watchdog-node是以daemonset运行
    1. 只暴露有限的、经过审计的操作接口（重启服务、收集日志、健康检查等），通过严格认证与授权调用,只能接受来自RMDC-watchdog的调用
    2. 可以收集每台主机的运行状态信息
        1. CPU
        2. 内存
        3. 磁盘
        4. 网络
5. 授权系统防篡改核心
    1. TOTP算法防止信息篡改
    2. 每个项目的二级授权中心密钥均不同
    3. 每个项目的一级授权中心密钥均不同
    4. rmdc-project-management和RMDC-watchdog之间交互信息需要加密
    5. RMDC-watchdog和RMDC-watchdog-agent之间交互信息不需要加密，但是首先需要验证TOTP码
6. 取消授权
    1. rmdc-project-management应该可以取消对一个项目的授权
    2. RMDC-watchdog应该有相应的接口,能够接收取消授权
        1. 取消特定主机的授权
7. 授权时间
    1. rmdc-project-management应该能够设置授权时间
    2. RMDC-watchdog应该新增授权时间管理功能,
        1. 在解析授权文件中,应该解析授权时间,并设置授权时间

## Octopus Operator说明

### 运行环境说明

1. 有网络情况,通过RMDC-Exchange-Hub进行信息交互
    1. 正常情况，需要通过MQTT接收指令，上传指令
    2. 正常情况需要通过此种方式交互，无需认证
2. 无网络情况
    1. 不正常情况，无法接收MQTT指令，无法上传指令
    2. 预留HTTP端口暴露，用于特殊情况访问
    3. 通过此种方式调用，复用二级授权中心的TOTP密钥,进行认证

### K8S Operator

``` 功能模块归属 rmdc-watchdog ```

#### 业务信息管理

1. 能够获取命名空间内的所有如下信息
    1. StatefulSet
    2. Deployment
    3. DaemonSet
    4. Pod
    5. ReplicaSet
    6. Service
    7. ConfigMap
    8. Secret
2. 上述的内容均支持筛选查询
3. 上述内容均支持yaml文件编辑
4. 上述内容均支持删除
5. 上述内容均支持创建
6. 上述内容均支持复制

#### K8S信息管理

1. 能够获取k8s的所有如下信息
    1. 主机节点信息
    2. Ingress信息

#### 业务详情

1. 业务的部署模式为Deployment,能够获取到业务的详情
2. 针对下面的内容均有 查看和编辑能力
    1. 副本数量
    2. 镜像版本
    3. 环境变量
    4. JVM参数
3. 该业务的历史版本信息
    1. 通过同名的ReplicaSets获取
    2. 历史版本创建时间
4. 业务镜像的运行环境变量
    1. 在镜像构建的时候, GIT_BRANCH GIT_COMMIT信息保存在docker image中
    2. 业务镜像的运行环境变量包含GIT_BRANCH GIT_COMMIT信息，此部分需要能够一键获取到

#### 中间件详情

1. 中间件的部署模式为StatefulSet
2. 针对特定的中间件，需要有监视、信息查看、编辑、删除、重启等能力
    1. MySQL
    2. Redis
    3. MQTTX
    4. InfluxDB

### 向上-信息交互 wdd.io/RMDC/rmdc-exchange-hub

请参照 [1-rmdc-exchange-hub-DDS.md](0-设计方案\3-信息交换ExchangeHub\1-rmdc-exchange-hub-DDS.md)
中项目启动注册流程-正常的rmdc-watchdog启动流程的详细流程

### 向下-信息交互 rmdc-watchdog-agent rmdc-watchdog-node

#### 集群信息收集

1. 收集主机运行状态信息
    1. from rmdc-watchdog-node
    2. 收集简单信息
        1. 主机名称
        2. 主机IP
        3. 主机CPU使用率
        4. 主机内存使用率
        5. 主机磁盘使用率
        6. 主机网络使用率
    3. 收集详细信息
        1. 主机磁盘的详细使用情况,包含每个目录,排除linux系统的特殊目录
        2. 主机内存的详细使用情况
        3. 主机CPU的详细使用情况
        4. 主机网络的详细使用情况
2. 收集k8s集群运行状态信息
    1. from 自身
    2. 收集简单信息
        1. k8s集群名称
        2. k8s集群版本
        3. k8s集群节点数量
        4. k8s集群CPU使用率
        5. k8s集群内存使用率
        6. k8s节点状态
        7. k8s存活状态
        8. k8s存活时间

2. 收集业务运行状态信息
    1. from rmdc-watchdog-agent
    2. 业务如果重启, agent需要向watchdog发送故障信息
        1. 故障信息包括 业务名称, 运行主机信息,重启次数, 重启时间, 重启日志结存300行
        2. 需要持久化
    3. 收集简单信息
        1. 业务名称
        2. 业务存活状态
        3. 业务存活时间
        4. 业务CPU使用率
        5. 业务内存使用率
    4. 业务详细运行信息
        1. JAVA 内存分析
        2. JAVA 线程分析
        3. JAVA GC分析
        4. JAVA 类加载分析
        5. JAVA 类卸载分析

#### 主机指令下发

1. 下发主机指令
    1. to rmdc-watchdog-node
2. 下发业务指令
    1. to rmdc-watchdog-agent
3. 下发K8S指令
    1. to 自身

### 信息持久化

1. 上文中存在的说明的信息,需要持久化保存
2. 支持时间段所有信息导出
    1. 提供HTTP端口,能够导出指定时间段的所有信息
3. 业务系统存在如下的中间件,可以考虑使用
    1. MySQL数据库
    2. Redis数据库
    3. InfluxDB数据库

## Node Operator说明

```功能模块归属 rmdc-watchdog-node```

### DLTU - Download Load Tag Upload

1. 功能模块归属 rmdc-watchdog-node
2. 接收来自wdd.io/RMDC/rmdc-watchdog的指令
3. Download 下载镜像 从指定的url下载镜像压缩包至特定的目录保存
    1. 需要考虑无公网的异常情况
    2. 人工将压缩包防止在规定的目录中
    3. 应该检测本地的镜像压缩包，判定是否存在
4. Load 加载镜像 从指定的目录加载镜像压缩包
5. Tag 标签镜像 为镜像打标签
6. Upload 上传镜像 将镜像推送到指定的Harbor仓库


## 运行状态与心跳策略

1. **状态机**：`offline -> connecting -> verifying -> online -> disconnecting -> offline`，对应 exchange-hub 的在线状态表；心跳超时默认 30 秒转 offline。
2. **心跳频率**：watchdog→exchange-hub 默认 5 秒；agent/node→watchdog 默认 10 秒；支持配置，超时触发 notice-center 告警。
3. **缓存与补传**：指令结果、监控、日志上报在弱网下先写本地队列（容量 N，按时间/大小回收），重连后批量补传。

## 安全与授权细化

1. **授权校验**：watchdog 启动需验证一级 TOTP；agent/node 请求需验证二级 TOTP；授权文件到期需自动降级并通知项目管理。
2. **接口暴露**：仅开放受审计的操作接口（重启、日志收集、健康检查、DLTU）；默认拒绝除名单外的命令类型。
3. **防篡改**：所有下行指令校验签名 + TOTP；agent 自毁前需等待 N 次连续授权失败确认。

## 监控与告警

1. **采集项**：主机 CPU/内存/磁盘/网络、Pod 状态、业务 JVM 指标、重启次数、上报延迟。
2. **指标维度**：按项目/主机/Pod 维度聚合，暴露给 monitor-center；上报失败/延迟写入本地并告警。
3. **日志截断**：业务故障日志仅回传最近 300 行；超长日志切片上传，避免 MQTT/HTTP 负载过大。

## 数据留存与导出

1. **持久化**：主机/业务指标可选本地 InfluxDB 或 SQLite（弱网时）；周期性清理过期数据（默认 30 天）。
2. **导出**：提供 HTTP 端口导出指定时间段信息，需签名 + TOTP 校验；导出操作写审计。

