提交 05ae4064 authored 作者: 陈泽健's avatar 陈泽健

Merge remote-tracking branch 'origin/develop' into develop

# _PRD_预定系统EMQX服务监控需求文档.md
> 版本:V1.0
> 更新日期:2026-01-29
> 适用范围:预定系统EMQX消息队列服务监测与自愈
> 实现脚本:`自动化部署脚本\x86架构\预定系统\定时脚本\monitor_emqx_service.sh`
---
## 1. 背景与目标
### 1.1 背景
EMQX作为预定系统的核心消息队列服务,负责处理设备通信、消息路由等关键功能。服务中断会直接影响系统整体可用性,需要建立自动监控和恢复机制。
### 1.2 目标
实现EMQX服务的自动化定时监控功能,具备:
- 容器运行状态监测
- EMQX进程存在性验证
- 服务可用性状态检查
- 异常时的自动重启恢复
- 多层次的状态验证机制
- 完整的操作日志记录
---
## 2. 总体范围
### 2.1 纳入监控对象
- **容器名称**`uemqx`
- **监控维度**
- 容器运行状态(docker ps)
- EMQX进程存在性(pgrep -f "emqx")
- 服务可用性(emqx_ctl status命令)
- 服务状态详细信息
### 2.2 不在本期范围
- EMQX集群状态监控
- 消息队列性能指标监控
- 客户端连接数统计
- 消息流量监控
---
## 3. 术语说明
- **服务状态验证**:通过EMQX自带的emqx_ctl命令检查服务运行状态
- **渐进式恢复**:先检查再重启,重启后再次验证的恢复策略
- **多层次检测**:容器层→进程层→服务层的逐级验证机制
---
## 4. 功能需求
### 4.1 监控流程
#### 4.1.1 状态检查机制
按以下顺序进行状态验证:
1. **容器运行检查**
- 使用`docker ps`检查uemqx容器是否运行
- 容器未运行时直接进入重启流程
2. **进程存在检查**
- 在容器内执行`pgrep -f "emqx"`查找EMQX进程
- 进程不存在时标记为异常状态
3. **服务可用性检查**
- 执行`emqx_ctl status`命令检查服务状态
- 验证返回结果中包含"is started"标识
- 确认服务真正可用而非仅进程存在
#### 4.1.2 异常处理流程
当检测到异常时执行:
1. **容器重启**
- 停止可能挂起的容器实例
- 启动uemqx容器
- 等待30秒让服务完全启动
2. **状态验证循环**
- 检查容器是否成功运行
- 验证EMQX进程是否启动
- 等待10秒后再次检查服务状态
- 确认emqx_ctl status返回正常
3. **最终状态确认**
- 所有检查项都通过才算恢复成功
- 任一环节失败都记录为恢复失败
### 4.2 日志与审计
#### 4.2.1 日志文件
- 主日志:`/var/log/scripts/monitor_emqx_service.log`
#### 4.2.2 日志级别和格式
每行必须包含:
- 时间戳:`YYYY-MM-DD HH:MM:SS`
- 级别标识:信息/警告/错误/成功
- 具体操作和结果状态
示例:
```
2026-01-29 10:00:00 - 开始检查 EMQX 服务状态...
2026-01-29 10:00:01 - EMQX 服务状态正常
2026-01-29 10:05:00 - 警告: 容器正在运行,EMQX 进程存在,但 emqx_ctl 命令执行失败
2026-01-29 10:05:05 - EMQX 未运行。正在尝试重启容器 'uemqx'...
2026-01-29 10:05:35 - 信息: 等待 30 秒让 EMQX 服务完全启动..............................
2026-01-29 10:06:05 - 成功: EMQX 容器已成功启动。
```
### 4.3 错误处理
#### 4.3.1 容器状态异常
- 容器不存在:记录严重错误并建议手动创建
- 容器启动失败:记录错误详情和可能原因
- 容器启动后立即停止:记录错误并建议检查日志
#### 4.3.2 服务状态异常
- emqx_ctl命令不存在:记录警告并降级检查
- 命令执行失败:记录错误并尝试重启
- 状态返回异常:记录详细状态信息
#### 4.3.3 恢复过程异常
- 重启后容器仍不运行:记录失败并建议手动干预
- 进程启动但服务不可用:记录详细诊断信息
- 超时等待后仍未恢复:记录超时并建议深入排查
---
## 5. 配置参数
| 配置项 | 默认值 | 说明 |
|--------|--------|------|
| CONTAINER_NAME | uemqx | EMQX容器名称 |
| LOG_FILE | /var/log/scripts/monitor_emqx_service.log | 日志文件路径 |
| STARTUP_WAIT | 30秒 | 容器启动等待时间 |
| STATUS_CHECK_WAIT | 10秒 | 状态验证等待时间 |
---
## 6. 执行要求
### 6.1 执行时机
- 建议:每5分钟执行一次
- cron配置:`*/5 * * * * /opt/scripts/monitor_emqx_service.sh`
### 6.2 执行环境
- 需要docker命令权限
- uemqx容器必须存在
- 容器内需要有emqx_ctl命令
### 6.3 资源要求
- 内存:监控过程占用少量内存
- CPU:状态检查操作轻量级
- 网络:仅本地容器通信
---
## 7. 验收标准
1. **监控准确性**
- 能正确识别容器运行状态
- 准确检测EMQX进程存在性
- 正确验证服务可用性状态
2. **恢复有效性**
- 异常检测后能正确触发重启
- 重启操作能成功执行
- 恢复后服务状态确实正常
3. **日志完整性**
- 每次检查都有完整的开始和结束记录
- 异常情况有详细的诊断信息
- 恢复过程有清晰的步骤记录
4. **系统稳定性**
- 监控过程不影响EMQX正常运行
- 重启操作安全可靠
- 不会产生连锁故障
---
## 8. 故障排查
### 8.1 常见问题
1. **容器不存在**
```
错误: 容器 'uemqx' 不存在!
```
解决:重新创建uemqx容器
2. **命令执行失败**:
```
警告: 容器正在运行,EMQX 进程存在,但 emqx_ctl 命令执行失败
```
解决:检查容器内EMQX安装状态
3. **重启失败**:
```
错误: 无法启动 EMQX 容器。
```
解决:查看容器日志`docker logs uemqx`
### 8.2 诊断命令
```bash
# 检查容器状态
docker ps | grep uemqx
# 检查容器内进程
docker exec uemqx pgrep -f "emqx"
# 手动检查服务状态
docker exec uemqx emqx_ctl status
# 查看容器日志
docker logs uemqx --tail 50
# 手动重启测试
docker restart uemqx
```
### 8.3 日志分析
```bash
# 实时监控脚本执行
tail -f /var/log/scripts/monitor_emqx_service.log
# 统计异常发生频率
grep "警告\|错误" /var/log/scripts/monitor_emqx_service.log | wc -l
# 查看最近的恢复记录
grep "成功: EMQX 容器已成功启动" /var/log/scripts/monitor_emqx_service.log
```
---
## 需求规范
代码规范:Docs/PRD/01规范文档/_PRD_规范文档_代码规范.md
问题总结:Docs/PRD/01规范文档/_PRD_问题总结_记录文档.md
方法总结:Docs/PRD/01规范文档/_PRD_方法总结_记录文档.md
文档规范:Docs/PRD/01规范文档/_PRD_规范文档_文档规范.md
测试规范:Docs/PRD/01规范文档/_PRD_规范文档_测试规范.md
\ No newline at end of file
# _PRD_预定系统MySQL数据库备份需求文档.md
> 版本:V1.0
> 更新日期:2026-01-29
> 适用范围:预定系统MySQL数据库定时备份
> 实现脚本:`自动化部署脚本\x86架构\预定系统\定时脚本\backup_mysql_databases.sh`
---
## 1. 背景与目标
### 1.1 背景
预定系统使用MySQL数据库存储核心业务数据,为防止数据丢失和满足合规要求,需要建立定期备份机制。
### 1.2 目标
实现MySQL数据库的自动化定时备份功能,具备:
- 指定数据库的批量备份能力
- 容器内操作的安全性保障
- 备份文件的压缩存储
- 过期备份的自动清理
- 完整的操作日志记录
---
## 2. 总体范围
### 2.1 纳入备份对象
- **容器**`umysql`
- **备份数据库列表**
- devops
- devops_voice
- huazhao2
- nacos_mysql
- offline
- ubains
- wifi
- voice
- ubains_nacos_config
- ubains_sso
### 2.2 不在本期范围
- 数据库增量备份
- 备份文件加密
- 远程存储同步
- 备份恢复验证
---
## 3. 术语说明
- **容器内临时目录**:在MySQL容器内创建的临时备份目录,带PID防冲突
- **宿主机备份目录**`/opt/mysql`,存储所有备份文件
- **日期格式**`YYYYMMDD`,用于备份目录命名
- **保留天数**:30天,默认保留期限
---
## 4. 功能需求
### 4.1 备份流程
#### 4.1.1 初始化检查
- 检查umysql容器是否运行
- 获取MySQL root密码(从容器环境变量)
- 验证数据库连接可用性
- 创建宿主机备份目录
#### 4.1.2 数据库发现
- 获取容器内实际存在的数据库列表
- 对比目标备份列表,跳过不存在的数据库
- 建立数据库存在性映射表
#### 4.1.3 批量备份执行
对每个目标数据库执行:
1. 在容器内创建临时目录
2. 执行mysqldump + gzip压缩
3. 从容器复制到宿主机
4. 验证备份文件完整性
5. 清理容器内临时文件
#### 4.1.4 清理机制
- 自动清理超过30天的旧备份目录
- 按日期格式化的目录结构
- 保留完整的备份历史记录
### 4.2 日志与审计
#### 4.2.1 日志文件
- 主日志:`/var/log/scripts/backup_mysql_databases.log`
#### 4.2.2 日志内容
每行必须包含:
- 时间戳:`YYYY-MM-DD HH:MM:SS`
- 操作类型:开始/成功/失败/跳过
- 数据库名称和操作结果
示例:
```
[2026-01-29 01:00:00] 开始备份数据库: ubains
[2026-01-29 01:00:15] ✅ 备份成功: ubains -> /opt/mysql/20260129/ubains.sql.gz
[2026-01-29 01:00:20] ⚠️ 跳过: 数据库 nonexist_db 不存在
```
### 4.3 错误处理
#### 4.3.1 容器状态异常
- 容器未运行:记录错误并退出
- 容器内无法创建目录:记录错误并清理
#### 4.3.2 数据库连接失败
- 密码获取失败:记录错误并退出
- 连接测试失败:记录错误并退出
#### 4.3.3 备份过程异常
- mysqldump执行失败:记录具体数据库名称
- 文件复制失败:删除不完整文件
- 压缩文件为空:标记为备份失败
---
## 5. 配置参数
| 配置项 | 默认值 | 说明 |
|--------|--------|------|
| CONTAINER_NAME | umysql | MySQL容器名称 |
| DB_USER | root | 数据库用户名 |
| HOST_BACKUP_DIR | /opt/mysql | 宿主机备份目录 |
| LOG_FILE | /var/log/scripts/backup_mysql_databases.log | 日志文件路径 |
| RETENTION_DAYS | 30 | 备份保留天数 |
| TARGET_DBS | 10个数据库 | 目标备份数据库列表 |
---
## 6. 执行要求
### 6.1 执行时机
- 建议:每日凌晨1点执行
- cron配置:`0 1 * * * /opt/scripts/backup_mysql_databases.sh`
### 6.2 执行环境
- 需要docker命令权限
- 需要对备份目录的读写权限
- umysql容器必须处于运行状态
### 6.3 资源要求
- 磁盘空间:预留足够空间存储30天备份
- 内存:备份过程中临时使用容器内存
- CPU:mysqldump操作会占用一定CPU资源
---
## 7. 验收标准
1. **备份完整性**
- 每个目标数据库都能生成对应的.sql.gz文件
- 备份文件大小合理(非0字节)
- 可以正常解压和导入
2. **日志完整性**
- 每次执行都有完整的开始和结束记录
- 成功和失败操作都有明确标识
- 包含具体的错误信息和建议
3. **清理机制**
- 超过30天的备份目录被正确删除
- 保留期内的备份文件完整存在
- 不会影响正在进行的备份操作
4. **安全性**
- 密码不直接出现在日志中
- 临时文件及时清理
- 备份目录权限设置合理
---
## 8. 故障排查
### 8.1 常见问题
1. **容器未运行**
```
❌ 无法在容器内创建临时目录,请检查容器是否运行。
```
解决:启动umysql容器
2. **数据库连接失败**:
```
❌ 使用密码连接数据库失败
```
解决:检查容器内MYSQL_ROOT_PASSWORD环境变量
3. **权限不足**:
```
Permission denied
```
解决:检查备份目录权限设置
### 8.2 日志检查
```bash
# 查看最近备份日志
tail -f /var/log/scripts/backup_mysql_databases.log
# 检查备份文件
ls -la /opt/mysql/$(date +%Y%m%d)/
# 验证备份完整性
gunzip -c /opt/mysql/20260129/ubains.sql.gz | head -20
```
---
## 需求规范
代码规范:Docs/PRD/01规范文档/_PRD_规范文档_代码规范.md
问题总结:Docs/PRD/01规范文档/_PRD_问题总结_记录文档.md
方法总结:Docs/PRD/01规范文档/_PRD_方法总结_记录文档.md
文档规范:Docs/PRD/01规范文档/_PRD_规范文档_文档规范.md
测试规范:Docs/PRD/01规范文档/_PRD_规范文档_测试规范.md
\ No newline at end of file
# _PRD_预定系统MySQL日志备份需求文档.md
> 版本:V1.0
> 更新日期:2026-01-29
> 适用范围:预定系统MySQL日志文件定时备份与压缩
> 实现脚本:`自动化部署脚本\x86架构\预定系统\定时脚本\backup_mysql_logs.sh`
---
## 1. 背景与目标
### 1.1 背景
MySQL数据库产生的日志文件(错误日志、慢查询日志等)会持续增长,占用大量磁盘空间,需要定期备份和清理。
### 1.2 目标
实现MySQL日志文件的自动化定时备份功能,具备:
- 日志文件的自动发现和备份
- 备份文件的压缩存储以节省空间
- 原始文件权限的完整保留
- 过期备份的自动清理机制
- 完整的操作日志记录
---
## 2. 总体范围
### 2.1 纳入备份对象
- **日志目录**`/opt/mysql/logs`
- **备份目标**
- *.log 文件(通用日志文件)
- *.slow 文件(慢查询日志)
- error.log(错误日志)
- slow.log(慢查询日志)
- mysqld.log(MySQL服务日志)
### 2.2 不在本期范围
- 日志内容分析和告警
- 日志文件的实时监控
- 备份文件的远程传输
- 日志级别的动态调整
---
## 3. 术语说明
- **权限保存恢复**:备份前后保持文件的权限、属主、属组信息不变
- **临时权限文件**:用于存储文件权限信息的临时文件,格式为`filename.permissions.tmp`
- **备份目录结构**:按日期创建子目录,格式为`/opt/mysql/logs/backup/YYYYMMDD/`
---
## 4. 功能需求
### 4.1 备份流程
#### 4.1.1 初始化检查
- 检查MySQL日志目录是否存在
- 创建今日备份目录
- 初始化日志文件
#### 4.1.2 日志文件发现
使用find命令查找所有符合条件的日志文件:
```bash
find "$MYSQL_LOG_DIR" -maxdepth 1 \( -name "*.log" -o -name "*.slow" -o -name "error.log" -o -name "slow.log" -o -name "mysqld.log" \) -type f
```
#### 4.1.3 权限保存机制
对每个日志文件执行:
1. 获取当前文件权限信息(chmod、chown)
2. 保存到临时权限文件
3. 执行备份操作
4. 恢复原始权限
5. 清理临时权限文件
#### 4.1.4 备份执行
对每个发现的日志文件:
1. 保存权限信息到临时文件
2. 使用gzip压缩并复制到备份目录
3. 文件命名格式:`原文件名_YYYYMMDD.gz`
4. 验证备份文件完整性
5. 恢复原始文件权限
### 4.2 清理机制
#### 4.2.1 过期备份清理
- 自动删除超过30天的备份目录
- 按日期格式化目录进行清理
- 保留完整的备份历史记录
#### 4.2.2 临时文件清理
- 备份完成后清理所有权限临时文件
- 防止临时文件堆积占用空间
### 4.3 日志与审计
#### 4.3.1 日志文件
- 主日志:`/var/log/scripts/backup_mysql_logs.log`
#### 4.3.2 日志内容格式
每行必须包含:
- 时间戳:`YYYY-MM-DD HH:MM:SS`
- 操作类型:开始/成功/失败/跳过/警告
- 文件名称和操作结果
示例:
```
[2026-01-29 02:00:00] 开始备份日志文件: error.log
[2026-01-29 02:00:05] ✅ 日志备份并压缩成功: error.log -> error.log_20260129.gz
[2026-01-29 02:00:10] ⚠️ 备份文件已存在,跳过: slow.log
```
### 4.4 错误处理
#### 4.4.1 目录访问异常
- 日志目录不存在:记录错误并退出
- 无法进入目录:记录错误并退出
#### 4.4.2 文件操作异常
- 权限获取失败:记录警告但继续处理
- 压缩备份失败:记录错误并尝试恢复权限
- 文件复制失败:记录错误并清理不完整文件
#### 4.4.3 权限恢复异常
- 权限恢复失败:记录警告信息
- 临时文件删除失败:记录但不影响主流程
---
## 5. 配置参数
| 配置项 | 默认值 | 说明 |
|--------|--------|------|
| MYSQL_LOG_DIR | /opt/mysql/logs | MySQL日志目录 |
| BACKUP_DIR | /opt/mysql/logs/backup | 备份根目录 |
| LOG_FILE | /var/log/scripts/backup_mysql_logs.log | 日志文件路径 |
| RETENTION_DAYS | 30 | 备份保留天数 |
| DATE_FORMAT | %Y%m%d | 日期格式 |
---
## 6. 执行要求
### 6.1 执行时机
- 建议:每日凌晨2点执行
- cron配置:`0 2 * * * /opt/scripts/backup_mysql_logs.sh`
### 6.2 执行环境
- 需要对MySQL日志目录的读取权限
- 需要对备份目录的写入权限
- 需要gzip命令支持
### 6.3 资源要求
- 磁盘空间:预留足够空间存储压缩后的日志文件
- 内存:压缩操作会占用临时内存
- CPU:gzip压缩会占用一定CPU资源
---
## 7. 验收标准
1. **备份完整性**
- 所有符合条件的日志文件都被正确备份
- 备份文件可以正常解压
- 原始日志文件权限保持不变
2. **权限保持**
- 备份前后文件权限一致
- 属主和属组信息正确保留
- 临时权限文件被正确清理
3. **日志完整性**
- 每次执行都有完整的操作记录
- 成功和失败操作都有明确标识
- 包含具体的文件名称和操作结果
4. **清理机制**
- 超过30天的备份目录被正确删除
- 临时权限文件被彻底清理
- 不影响正常的日志文件使用
---
## 8. 故障排查
### 8.1 常见问题
1. **目录不存在**
```
❌ MySQL日志目录不存在: /opt/mysql/logs
```
解决:检查MySQL配置或创建日志目录
2. **权限不足**:
```
❌ 无法进入目录: /opt/mysql/logs
```
解决:检查目录访问权限
3. **压缩失败**:
```
❌ 日志备份失败: error.log
```
解决:检查磁盘空间和文件权限
### 8.2 日志检查
```bash
# 查看最近备份日志
tail -f /var/log/scripts/backup_mysql_logs.log
# 检查备份文件
ls -la /opt/mysql/logs/backup/$(date +%Y%m%d)/
# 验证权限保持
ls -l /opt/mysql/logs/error.log
ls -l /opt/mysql/logs/backup/20260129/error.log_20260129.gz
```
---
## 需求规范
代码规范:Docs/PRD/01规范文档/_PRD_规范文档_代码规范.md
问题总结:Docs/PRD/01规范文档/_PRD_问题总结_记录文档.md
方法总结:Docs/PRD/01规范文档/_PRD_方法总结_记录文档.md
文档规范:Docs/PRD/01规范文档/_PRD_规范文档_文档规范.md
测试规范:Docs/PRD/01规范文档/_PRD_规范文档_测试规范.md
\ No newline at end of file
# _PRD_预定系统MySQL服务监控需求文档.md
> 版本:V1.0
> 更新日期:2026-01-29
> 适用范围:预定系统MySQL数据库服务监测与自愈
> 实现脚本:`自动化部署脚本\x86架构\预定系统\定时脚本\monitor_mysql_service.sh`
---
## 1. 背景与目标
### 1.1 背景
MySQL作为预定系统的核心数据库服务,存储着所有业务数据。数据库服务的稳定性和可用性直接影响整个系统的正常运行,需要建立可靠的监控和自动恢复机制。
### 1.2 目标
实现MySQL服务的自动化定时监控功能,具备:
- 容器运行状态监测
- 数据库连接可用性验证
- SQL执行功能测试
- 异常时的自动重启恢复
- 密码自动获取机制
- 多层次的健康检查
- 完整的操作日志记录
---
## 2. 总体范围
### 2.1 纳入监控对象
- **容器名称**`umysql`
- **监控维度**
- 容器运行状态(docker ps)
- 数据库连接测试(mysqladmin ping)
- SQL查询执行能力(SELECT 1)
- root密码自动获取
### 2.2 不在本期范围
- 数据库性能指标监控
- 慢查询日志分析
- 数据库备份状态监控
- 主从复制状态监控
---
## 3. 术语说明
- **连接测试**:使用mysqladmin工具测试数据库连接可达性
- **功能验证**:执行简单SQL查询验证数据库功能完整性
- **密码自动获取**:从容器环境变量中读取数据库密码
- **渐进式验证**:从容器→连接→功能的逐层验证机制
---
## 4. 功能需求
### 4.1 监控流程
#### 4.1.1 状态检查机制
按以下顺序进行健康验证:
1. **容器运行检查**
- 使用`docker ps`检查umysql容器是否运行
- 容器未运行时直接进入重启流程
2. **密码获取验证**
- 从容器环境变量获取MYSQL_ROOT_PASSWORD
- 密码获取失败时标记为异常状态
3. **连接可用性测试**
- 使用`mysqladmin ping`测试基本连接
- 验证TCP连接和认证通过
4. **功能完整性验证**
- 执行`SELECT 1`简单查询
- 确认数据库具备完整SQL执行能力
#### 4.1.2 异常处理流程
当检测到异常时执行:
1. **容器重启**
- 停止可能挂起的容器实例
- 启动umysql容器
- 等待60秒让数据库完全启动
2. **状态验证循环**
- 检查容器是否成功运行
- 等待20秒后再次检查服务状态
- 重新获取数据库密码
- 执行连接和功能测试
3. **最终确认**
- 所有检查项都通过才算恢复成功
- 任一环节失败都记录为恢复失败
### 4.2 密码管理机制
#### 4.2.1 自动获取
```bash
docker exec umysql printenv MYSQL_ROOT_PASSWORD
```
#### 4.2.2 安全处理
- 密码从环境变量获取,不在脚本中硬编码
- 命令执行中使用引号保护特殊字符
- 日志中不直接输出密码明文
### 4.3 日志与审计
#### 4.3.1 日志文件
- 主日志:`/var/log/scripts/monitor_mysql_service.log`
#### 4.3.2 日志级别和格式
每行必须包含:
- 时间戳:`YYYY-MM-DD HH:MM:SS`
- 级别标识:信息/警告/错误/成功
- 具体操作和结果状态
示例:
```
2026-01-29 10:00:00 - 开始检查 MySQL 服务状态...
2026-01-29 10:00:02 - MySQL 服务连接正常,可以执行SQL查询
2026-01-29 10:05:00 - 警告: 无法连接到 MySQL 服务
2026-01-29 10:05:05 - MySQL 未运行。正在尝试重启容器 'umysql'...
2026-01-29 10:06:05 - 成功: MySQL 容器已成功启动。
2026-01-29 10:07:05 - 信息: 等待 60 秒让 MySQL 服务完全启动............................................................
2026-01-29 10:08:05 - 信息: 等待 20 秒后检查服务状态....................
2026-01-29 10:08:25 - 信息: MySQL 服务状态正常。
```
### 4.4 错误处理
#### 4.4.1 容器状态异常
- 容器不存在:记录严重错误并建议手动创建
- 容器启动失败:记录错误详情和可能原因
- 容器启动后立即停止:记录错误并建议检查日志
#### 4.4.2 连接状态异常
- 密码获取失败:记录错误并退出检查
- 连接测试失败:记录具体的连接错误信息
- SQL执行失败:区分连接问题和权限问题
#### 4.4.3 恢复过程异常
- 重启后容器仍不运行:记录失败并建议手动干预
- 密码重新获取失败:记录错误并终止恢复
- 功能验证持续失败:记录详细诊断信息
---
## 5. 配置参数
| 配置项 | 默认值 | 说明 |
|--------|--------|------|
| CONTAINER_NAME | umysql | MySQL容器名称 |
| LOG_FILE | /var/log/scripts/monitor_mysql_service.log | 日志文件路径 |
| STARTUP_WAIT | 60秒 | 容器启动等待时间 |
| STATUS_CHECK_WAIT | 20秒 | 状态验证等待时间 |
---
## 6. 执行要求
### 6.1 执行时机
- 建议:每5分钟执行一次
- cron配置:`*/5 * * * * /opt/scripts/monitor_mysql_service.sh`
### 6.2 执行环境
- 需要docker命令权限
- umysql容器必须存在
- 需要mysql-client工具支持
### 6.3 资源要求
- 内存:监控过程占用少量内存
- CPU:状态检查操作轻量级
- 网络:仅本地容器通信
- 磁盘:需要足够的数据库日志空间
---
## 7. 验收标准
1. **监控准确性**
- 能正确识别容器运行状态
- 准确获取和使用数据库密码
- 正确执行连接和功能测试
2. **恢复有效性**
- 异常检测后能正确触发重启
- 重启操作能成功执行
- 恢复后数据库功能确实正常
3. **日志完整性**
- 每次检查都有完整的开始和结束记录
- 异常情况有详细的诊断信息
- 恢复过程有清晰的步骤记录
4. **安全性**
- 密码处理安全,不在日志中明文显示
- 命令执行安全,防止注入攻击
- 权限控制适当,最小化操作权限
---
## 8. 故障排查
### 8.1 常见问题
1. **容器不存在**
```
错误: 容器 'umysql' 不存在!
```
解决:重新创建umysql容器
2. **密码获取失败**:
```
信息: umysql 容器未运行
```
解决:检查容器运行状态和环境变量配置
3. **连接测试失败**:
```
警告: 无法连接到 MySQL 服务
```
解决:查看容器日志`docker logs umysql`
4. **SQL执行失败**:
```
警告: MySQL 服务可以ping通,但无法执行SQL查询
```
解决:检查数据库权限和状态
### 8.2 诊断命令
```bash
# 检查容器状态
docker ps | grep umysql
# 手动获取密码
docker exec umysql printenv MYSQL_ROOT_PASSWORD
# 手动连接测试
mysqladmin -h localhost -u root -p"password" ping
# 手动SQL测试
mysql -u root -p"password" -e "SELECT 1;"
# 查看容器日志
docker logs umysql --tail 50
# 手动重启测试
docker restart umysql
```
### 8.3 日志分析
```bash
# 实时监控脚本执行
tail -f /var/log/scripts/monitor_mysql_service.log
# 统计异常发生频率
grep "警告\|错误" /var/log/scripts/monitor_mysql_service.log | wc -l
# 查看最近的恢复记录
grep "成功: MySQL 容器已成功启动" /var/log/scripts/monitor_mysql_service.log
# 分析连接问题
grep "无法连接到 MySQL" /var/log/scripts/monitor_mysql_service.log
```
---
## 需求规范
代码规范:Docs/PRD/01规范文档/_PRD_规范文档_代码规范.md
问题总结:Docs/PRD/01规范文档/_PRD_问题总结_记录文档.md
方法总结:Docs/PRD/01规范文档/_PRD_方法总结_记录文档.md
文档规范:Docs/PRD/01规范文档/_PRD_规范文档_文档规范.md
测试规范:Docs/PRD/01规范文档/_PRD_规范文档_测试规范.md
\ No newline at end of file
# _PRD_预定系统Nginx日志备份需求文档.md
> 版本:V1.0
> 更新日期:2026-01-29
> 适用范围:预定系统Nginx日志文件定时备份与轮转
> 实现脚本:`自动化部署脚本\x86架构\预定系统\定时脚本\backup_nginx_logs.sh`
---
## 1. 背景与目标
### 1.1 背景
Nginx作为预定系统的反向代理和Web服务器,产生的访问日志和错误日志会持续增长,需要定期备份并进行日志轮转以控制系统磁盘使用。
### 1.2 目标
实现Nginx日志文件的自动化定时备份功能,具备:
- 访问日志和错误日志的定期备份
- 备份文件的压缩存储以节省空间
- 原始日志文件的清空实现日志轮转
- Nginx服务的日志文件重新打开通知
- 过期备份的自动清理机制
- 完整的操作日志记录
---
## 2. 总体范围
### 2.1 纳入备份对象
- **日志目录**`/var/www/java/nginx-conf.d/nginx_log`
- **备份目标**
- access.log(访问日志)
- error.log(错误日志)
### 2.2 不在本期范围
- 日志内容分析和访问统计
- 日志级别的动态调整
- 备份文件的远程传输
- 日志格式的自定义处理
---
## 3. 术语说明
- **日志轮转**:备份后清空原始日志文件内容,但保持文件存在
- **Nginx信号通知**:向Nginx进程发送reopen信号,使其重新打开日志文件
- **容器内执行**:优先在ujava2容器内执行Nginx命令
---
## 4. 功能需求
### 4.1 备份流程
#### 4.1.1 初始化检查
- 检查Nginx日志目录是否存在
- 创建今日备份目录
- 初始化日志文件
#### 4.1.2 日志文件处理
对每个目标日志文件(access.log, error.log)执行:
1. 检查文件是否存在
2. 保存原始权限信息
3. 使用gzip压缩并复制到备份目录
4. 文件命名格式:`原文件名_YYYYMMDD.gz`
5. 验证备份文件完整性
6. 清空原始日志文件内容(> filename)
7. 恢复原始文件权限
#### 4.1.3 Nginx服务通知
备份完成后向Nginx发送reopen信号:
1. 优先尝试直接执行nginx命令
2. 如果失败,尝试在ujava2容器内执行
3. 记录通知结果到日志
### 4.2 权限管理
#### 4.2.1 权限保存机制
- 备份前获取文件权限信息(chmod、chown)
- 保存到临时权限文件
- 备份后恢复原始权限
- 清理临时权限文件
#### 4.2.2 文件操作安全
- 使用原子操作清空日志文件
- 权限恢复失败时记录警告
- 确保Nginx可以继续正常写入日志
### 4.3 日志与审计
#### 4.3.1 日志文件
- 主日志:`/var/log/scripts/backup_nginx_logs.log`
#### 4.3.2 日志内容格式
每行必须包含:
- 时间戳:`YYYY-MM-DD HH:MM:SS`
- 操作类型:开始/成功/失败/跳过/警告
- 文件名称和操作结果
示例:
```
[2026-01-29 03:00:00] 开始备份日志文件: access.log
[2026-01-29 03:00:05] ✅ 日志备份并压缩成功: access.log -> access.log_20260129.gz
[2026-01-29 03:00:06] ✅ 原始日志文件已清空: access.log
[2026-01-29 03:00:10] ⚠️ 无法向Nginx发送reopen信号
```
### 4.4 错误处理
#### 4.4.1 目录访问异常
- 日志目录不存在:记录错误并退出
- 无法进入目录:记录错误并退出
#### 4.4.2 文件操作异常
- 日志文件不存在:记录警告并跳过
- 压缩备份失败:记录错误并尝试恢复权限
- 文件清空失败:记录错误但不影响主流程
#### 4.4.3 服务通知异常
- Nginx命令不存在:记录警告
- 信号发送失败:记录警告但不影响备份流程
---
## 5. 配置参数
| 配置项 | 默认值 | 说明 |
|--------|--------|------|
| NGINX_LOG_DIR | /var/www/java/nginx-conf.d/nginx_log | Nginx日志目录 |
| BACKUP_DIR | /var/www/java/nginx-conf.d/nginx_log/backup | 备份根目录 |
| LOG_FILE | /var/log/scripts/backup_nginx_logs.log | 日志文件路径 |
| RETENTION_DAYS | 30 | 备份保留天数 |
| DATE_FORMAT | %Y%m%d | 日期格式 |
---
## 6. 执行要求
### 6.1 执行时机
- 建议:每日凌晨3点执行
- cron配置:`0 3 * * * /opt/scripts/backup_nginx_logs.sh`
### 6.2 执行环境
- 需要对Nginx日志目录的读写权限
- 需要nginx命令或docker执行权限
- 需要gzip命令支持
### 6.3 资源要求
- 磁盘空间:预留足够空间存储压缩后的日志文件
- 内存:压缩操作会占用临时内存
- 注意:执行时Nginx会短暂停止写入日志
---
## 7. 验收标准
1. **备份完整性**
- access.log和error.log都被正确备份
- 备份文件可以正常解压
- 原始日志文件被正确清空
2. **日志轮转效果**
- 原始日志文件大小变为0字节
- Nginx继续正常记录新日志
- 备份文件命名格式正确
3. **服务连续性**
- Nginx服务不受备份操作影响
- 服务通知信号正确发送
- 日志记录不出现中断
4. **日志完整性**
- 每次执行都有完整的操作记录
- 成功和失败操作都有明确标识
- 包含具体的文件名称和操作结果
---
## 8. 故障排查
### 8.1 常见问题
1. **目录不存在**
```
❌ Nginx日志目录不存在: /var/www/java/nginx-conf.d/nginx_log
```
解决:检查Nginx配置或创建日志目录
2. **文件不存在**:
```
⚠️ 在 /var/www/java/nginx-conf.d/nginx_log 中未找到Nginx日志文件
```
解决:检查Nginx日志配置
3. **权限不足**:
```
❌ 日志备份失败: access.log
```
解决:检查文件权限和磁盘空间
### 8.2 日志检查
```bash
# 查看最近备份日志
tail -f /var/log/scripts/backup_nginx_logs.log
# 检查备份文件
ls -la /var/www/java/nginx-conf.d/nginx_log/backup/$(date +%Y%m%d)/
# 验证日志轮转效果
ls -lh /var/www/java/nginx-conf.d/nginx_log/access.log
# 应该显示文件大小为0
# 检查Nginx是否正常记录新日志
echo "test" >> /var/www/java/nginx-conf.d/nginx_log/access.log
tail /var/www/java/nginx-conf.d/nginx_log/access.log
```
---
## 需求规范
代码规范:Docs/PRD/01规范文档/_PRD_规范文档_代码规范.md
问题总结:Docs/PRD/01规范文档/_PRD_问题总结_记录文档.md
方法总结:Docs/PRD/01规范文档/_PRD_方法总结_记录文档.md
文档规范:Docs/PRD/01规范文档/_PRD_规范文档_文档规范.md
测试规范:Docs/PRD/01规范文档/_PRD_规范文档_测试规范.md
\ No newline at end of file
# _PRD_预定系统Redis服务监控需求文档.md
> 版本:V1.0
> 更新日期:2026-01-29
> 适用范围:预定系统Redis缓存服务监测与自愈
> 实现脚本:`自动化部署脚本\x86架构\预定系统\定时脚本\monitor_redis_service.sh`
---
## 1. 背景与目标
### 1.1 背景
Redis作为预定系统的重要缓存服务,提供高速数据访问和会话存储功能。由于Redis可能配置密码认证,需要建立智能化的监控和恢复机制来应对不同认证场景。
### 1.2 目标
实现Redis服务的自动化定时监控功能,具备:
- 容器运行状态监测
- 智能认证模式识别(有密码/无密码)
- PING命令响应验证
- 异常时的自动重启恢复
- 数据目录清理重试机制
- 完整的操作日志记录
---
## 2. 总体范围
### 2.1 纳入监控对象
- **容器名称**`uredis`
- **监控维度**
- 容器运行状态(docker ps)
- Redis连接测试(redis-cli ping)
- 认证状态识别(NOAUTH/Authentication required)
- PING响应验证(期望返回PONG)
### 2.2 不在本期范围
- Redis内存使用率监控
- Key过期策略监控
- 持久化状态监控
- 集群模式监控
---
## 3. 术语说明
- **认证模式识别**:自动检测Redis是否需要密码认证
- **数据清理重试**:重启失败时清理持久化数据目录后重试
- **渐进式恢复**:从简单重启到数据清理的逐步升级恢复策略
- **密码硬编码**:脚本中直接配置Redis访问密码
---
## 4. 功能需求
### 4.1 监控流程
#### 4.1.1 状态检查机制
按以下逻辑进行健康验证:
1. **容器运行检查**
- 使用`docker ps`检查uredis容器是否运行
- 容器未运行时直接进入重启流程
2. **无密码连接测试**
- 首先尝试无密码PING命令:`redis-cli ping`
- 成功返回PONG表示服务正常
- 失败时分析错误信息
3. **认证状态识别**
- 检查错误信息是否包含"NOAUTH"或"Authentication required"
- 确认为需要密码认证的情况
4. **密码认证测试**
- 使用预设密码执行PING命令
- 验证认证成功后的PING响应
- 确认服务真正可用
#### 4.1.2 异常处理流程
当检测到异常时执行:
1. **初次重启尝试**
- 停止可能挂起的容器实例
- 启动uredis容器
- 等待20秒让服务启动
- 再次检查容器运行状态
- 等待10秒后验证服务状态
2. **认证模式验证**
- 重新测试无密码连接
- 如需认证则使用预设密码测试
- 验证PING响应正确性
3. **数据清理重试**
- 初次重启失败时触发
- 清理可能的数据目录:
- `/var/www/java/redis/data`
- `/var/www/redis/data`
- 再次尝试启动容器
- 重复状态验证流程
### 4.2 认证处理机制
#### 4.2.1 密码配置
```bash
REDIS_PASSWORD="dNrprU&2S"
```
#### 4.2.2 认证命令
```bash
# 无密码模式
docker exec uredis redis-cli ping
# 有密码模式
docker exec uredis redis-cli -a "$REDIS_PASSWORD" --no-auth-warning ping
```
#### 4.2.3 响应验证
- 期望响应:`PONG`
- 异常响应:记录具体错误信息
- 认证失败:区分密码错误和其他连接问题
### 4.3 数据清理策略
#### 4.3.1 清理触发条件
- 容器重启后仍无法正常启动
- 怀疑数据文件损坏导致启动失败
- 常规恢复手段无效时
#### 4.3.2 清理目标目录
```bash
# 检查并删除可能存在的数据目录
if [ -d "/var/www/java/redis/data" ]; then
rm -rf /var/www/java/redis/data/*
fi
if [ -d "/var/www/redis/data" ]; then
rm -rf /var/www/redis/data/*
fi
```
#### 4.3.3 安全考虑
- 仅清理data子目录内容,不删除目录本身
- 清理前记录操作日志
- 清理后重新验证服务启动
### 4.4 日志与审计
#### 4.4.1 日志文件
- 主日志:`/var/log/scripts/monitor_redis_service.log`
#### 4.4.2 日志级别和格式
每行必须包含:
- 时间戳:`YYYY-MM-DD HH:MM:SS`
- 级别标识:信息/警告/错误/成功
- 具体操作和结果状态
示例:
```
2026-01-29 10:00:00 - 开始检查 Redis 服务状态...
2026-01-29 10:00:01 - 检测到需要认证的 Redis 服务,正在尝试使用密码...
2026-01-29 10:00:02 - Redis 服务状态正常(已通过密码认证)
2026-01-29 10:05:00 - 信息: uredis 容器未运行
2026-01-29 10:05:05 - Redis 未运行。正在尝试重启容器 'uredis'...
2026-01-29 10:05:25 - 成功: Redis 容器已成功启动。
2026-01-29 10:05:45 - 信息: 等待 10 秒后检查服务状态..........
2026-01-29 10:05:55 - 信息: Redis 服务状态正常(已通过密码认证)。
```
### 4.5 错误处理
#### 4.5.1 容器状态异常
- 容器不存在:记录严重错误并建议手动创建
- 容器启动失败:记录错误详情和可能原因
- 容器启动后立即停止:记录错误并建议检查日志
#### 4.5.2 认证状态异常
- 无密码连接失败但不是认证问题:记录具体错误
- 密码认证失败:记录认证错误信息
- PING响应异常:记录实际响应内容
#### 4.5.3 恢复过程异常
- 重启后容器仍不运行:记录失败并建议手动干预
- 数据清理后仍无法启动:记录严重错误
- 多次重试均失败:建议深入排查根本原因
---
## 5. 配置参数
| 配置项 | 默认值 | 说明 |
|--------|--------|------|
| CONTAINER_NAME | uredis | Redis容器名称 |
| REDIS_PASSWORD | dNrprU&2S | Redis访问密码 |
| LOG_FILE | /var/log/scripts/monitor_redis_service.log | 日志文件路径 |
| STARTUP_WAIT | 20秒 | 容器启动等待时间 |
| STATUS_CHECK_WAIT | 10秒 | 状态验证等待时间 |
---
## 6. 执行要求
### 6.1 执行时机
- 建议:每5分钟执行一次
- cron配置:`*/5 * * * * /opt/scripts/monitor_redis_service.sh`
### 6.2 执行环境
- 需要docker命令权限
- uredis容器必须存在
- 需要redis-cli命令支持
### 6.3 资源要求
- 内存:监控过程占用少量内存
- CPU:状态检查操作轻量级
- 网络:仅本地容器通信
- 磁盘:数据清理时会删除旧数据文件
---
## 7. 验收标准
1. **监控智能性**
- 能正确识别有密码/无密码认证模式
- 准确执行对应的连接测试
- 智能选择合适的恢复策略
2. **恢复有效性**
- 异常检测后能正确触发重启
- 重启操作能成功执行
- 数据清理机制能解决启动问题
- 恢复后服务状态确实正常
3. **日志完整性**
- 每次检查都有完整的开始和结束记录
- 认证模式识别过程详细记录
- 异常情况有详细的诊断信息
- 数据清理操作明确记录
4. **安全性**
- 密码在脚本中合理配置
- 数据清理操作安全可控
- 不会对正常运行的服务产生副作用
---
## 8. 故障排查
### 8.1 常见问题
1. **容器不存在**
```
错误: 容器 'uredis' 不存在!
```
解决:重新创建uredis容器
2. **认证模式识别错误**:
```
警告: 需要认证,但无法使用预设密码连接到 Redis
```
解决:检查Redis密码配置是否正确
3. **数据清理触发**:
```
信息: 尝试清理数据目录并重新启动 Redis 容器...
```
解决:这表示常规重启失败,脚本自动尝试清理数据
4. **持续启动失败**:
```
错误: 即使清理了数据目录,仍然无法启动 Redis 容器。
```
解决:需要手动检查容器配置和系统资源
### 8.2 诊断命令
```bash
# 检查容器状态
docker ps | grep uredis
# 手动无密码测试
docker exec uredis redis-cli ping
# 手动密码测试
docker exec uredis redis-cli -a "dNrprU&2S" --no-auth-warning ping
# 查看容器日志
docker logs uredis --tail 50
# 检查数据目录
ls -la /var/www/java/redis/data/
ls -la /var/www/redis/data/
# 手动重启测试
docker restart uredis
```
### 8.3 日志分析
```bash
# 实时监控脚本执行
tail -f /var/log/scripts/monitor_redis_service.log
# 统计认证模式使用情况
grep "检测到需要认证" /var/log/scripts/monitor_redis_service.log | wc -l
grep "无密码情况下能 ping 通" /var/log/scripts/monitor_redis_service.log | wc -l
# 查看数据清理记录
grep "清理.*data 目录" /var/log/scripts/monitor_redis_service.log
# 分析重启成功率
grep "Redis 容器已成功启动" /var/log/scripts/monitor_redis_service.log | wc -l
grep "仍然无法启动 Redis 容器" /var/log/scripts/monitor_redis_service.log | wc -l
```
---
## 需求规范
代码规范:Docs/PRD/01规范文档/_PRD_规范文档_代码规范.md
问题总结:Docs/PRD/01规范文档/_PRD_问题总结_记录文档.md
方法总结:Docs/PRD/01规范文档/_PRD_方法总结_记录文档.md
文档规范:Docs/PRD/01规范文档/_PRD_规范文档_文档规范.md
测试规范:Docs/PRD/01规范文档/_PRD_规范文档_测试规范.md
\ No newline at end of file
# _PRD_预定系统外部API服务监控需求文档.md
> 版本:V1.0
> 更新日期:2026-01-29
> 适用范围:预定系统外部API服务进程监测与自愈
> 实现脚本:`自动化部署脚本\x86架构\预定系统\定时脚本\monitor_external_api_services.sh`
---
## 1. 背景与目标
### 1.1 背景
预定系统的外部API服务以独立进程方式运行在宿主机上,包括会议API服务和malan服务。这些服务的稳定运行对系统功能至关重要,需要建立自动监控和恢复机制。
### 1.2 目标
实现外部API服务的自动化定时监控功能,具备:
- 多个服务进程的同时监控
- 进程存在性检测
- 服务目录和启动脚本验证
- 异常时的自动启动恢复
- 完整的操作日志记录
---
## 2. 总体范围
### 2.1 纳入监控对象
#### 2.1.1 ubains-meeting-api服务
- **进程标识**`ubains-meeting-api-1.0-SNAPSHOT.jar`
- **服务目录**`/var/www/malan`
- **启动脚本**`/var/www/malan/run.sh`
#### 2.1.2 malan服务
- **进程标识**`malan`
- **服务目录**`/var/www/malan`
- **启动脚本**`/var/www/malan/run.sh`
### 2.2 不在本期范围
- 服务性能指标监控
- API接口可用性检查
- 服务间依赖关系监控
- 负载均衡状态监控
---
## 3. 术语说明
- **进程标识**:用于在进程列表中识别特定服务的关键字
- **服务目录**:服务程序文件所在的目录路径
- **启动脚本**:用于启动服务的shell脚本文件
- **子shell执行**:在独立的shell环境中执行命令避免影响当前环境
---
## 4. 功能需求
### 4.1 监控流程
#### 4.1.1 服务配置管理
使用数组存储服务配置信息:
```bash
SERVICES=(
"ubains-meeting-api-1.0-SNAPSHOT.jar:/var/www/malan:/var/www/malan/run.sh"
"malan:/var/www/malan:/var/www/malan/run.sh"
)
```
#### 4.1.2 批量服务检查
对每个配置的服务执行:
1. **目录存在性验证**
- 检查服务目录是否存在
- 目录不存在时跳过该服务监控
2. **进程运行状态检查**
- 使用`pgrep -f`搜索进程标识
- 对于.jar文件搜索`java.*jar_name`模式
- 对于普通进程直接搜索进程名
3. **服务状态判定**
- 进程存在:标记为RUNNING状态
- 进程不存在:标记为STOPPED状态并尝试启动
#### 4.1.3 服务启动恢复
当服务处于STOPPED状态时执行:
1. **环境准备**
- 切换到服务目录(使用子shell)
- 验证启动脚本存在且可执行
2. **服务启动**
- 执行启动脚本:`nohup "./$(basename "$script_path")" > startup.log 2>&1 &`
- 等待3秒让进程启动
3. **启动验证**
- 再次检查进程是否运行
- 启动成功:记录SUCCESS状态
- 启动失败:记录ERROR状态
### 4.2 日志与审计
#### 4.2.1 日志文件
- 主日志:`/var/log/scripts/monitor_external_api_services.log`
#### 4.2.2 日志内容格式
每行必须包含:
- 时间戳:`YYYY-MM-DD HH:MM:SS`
- 操作类型:开始/检查/启动/成功/错误
- 服务名称和操作结果
示例:
```
2026-01-29 10:00:00 - === 服务监控脚本开始执行 ===
2026-01-29 10:00:01 - 检查服务: ubains-meeting-api-1.0-SNAPSHOT.jar (目录: /var/www/malan, 启动脚本: /var/www/malan/run.sh)
2026-01-29 10:00:02 - 服务 'ubains-meeting-api-1.0-SNAPSHOT.jar' 正在运行。
2026-01-29 10:00:03 - 检查服务: malan (目录: /var/www/malan, 启动脚本: /var/www/malan/run.sh)
2026-01-29 10:00:04 - 服务 'malan' 未运行。
2026-01-29 10:00:05 - 尝试启动服务 'malan'...
2026-01-29 10:00:08 - 服务 'malan' 启动成功。
2026-01-29 10:00:10 - === 服务监控脚本执行完毕 ===
```
### 4.3 错误处理
#### 4.3.1 目录异常
- 服务目录不存在:记录警告并跳过该服务
- 无法切换目录:记录错误并跳过启动
#### 4.3.2 脚本异常
- 启动脚本不存在:记录错误并跳过启动
- 脚本无执行权限:记录错误并跳过启动
#### 4.3.3 启动异常
- 进程启动失败:记录错误详情
- 启动后进程消失:记录启动超时错误
- 启动脚本执行异常:记录脚本错误输出
---
## 5. 配置参数
| 配置项 | 默认值 | 说明 |
|--------|--------|------|
| LOG_FILE | /var/log/scripts/monitor_external_api_services.log | 日志文件路径 |
| SERVICES | 数组配置 | 监控服务列表配置 |
| STARTUP_WAIT | 3秒 | 进程启动等待时间 |
---
## 6. 执行要求
### 6.1 执行时机
- 建议:每5分钟执行一次
- cron配置:`*/5 * * * * /opt/scripts/monitor_external_api_services.sh`
### 6.2 执行环境
- 需要对服务目录的访问权限
- 需要执行启动脚本的权限
- 需要pgrep命令支持
### 6.3 资源要求
- 内存:监控过程占用少量内存
- CPU:进程检查操作轻量级
- 注意:启动新进程时会有短暂资源占用
---
## 7. 验收标准
1. **监控覆盖性**
- 所配置的服务都被正确监控
- 能准确识别进程运行状态
- 目录和脚本验证机制有效
2. **恢复有效性**
- 停止的服务能被正确识别
- 启动操作能成功执行
- 启动后服务确实正常运行
3. **日志完整性**
- 每次执行都有完整的开始和结束记录
- 每个服务的检查结果都详细记录
- 启动操作有清晰的过程记录
4. **执行安全性**
- 不影响正在运行的正常服务
- 启动失败时不产生副作用
- 权限检查机制完善
---
## 8. 故障排查
### 8.1 常见问题
1. **目录不存在**
```
跳过服务 'xxx': 目录 '/path/to/service' 不存在。
```
解决:检查服务部署路径或更新配置
2. **脚本权限问题**:
```
错误: 启动脚本 '/path/to/run.sh' 不存在或不可执行。
```
解决:检查文件权限`chmod +x run.sh`
3. **进程启动失败**:
```
错误: 服务 'xxx' 启动失败。
```
解决:查看startup.log文件内容
### 8.2 诊断命令
```bash
# 检查进程状态
pgrep -f "ubains-meeting-api"
pgrep -x "malan"
# 检查服务目录
ls -la /var/www/malan/
# 查看启动脚本
cat /var/www/malan/run.sh
chmod +x /var/www/malan/run.sh
# 查看启动日志
tail -f /var/www/malan/startup.log
# 手动启动测试
cd /var/www/malan && ./run.sh
```
### 8.3 日志分析
```bash
# 实时监控脚本执行
tail -f /var/log/scripts/monitor_external_api_services.log
# 统计服务重启次数
grep "启动成功" /var/log/scripts/monitor_external_api_services.log | wc -l
# 查看最近的错误记录
grep "错误\|跳过" /var/log/scripts/monitor_external_api_services.log
```
---
## 需求规范
代码规范:Docs/PRD/01规范文档/_PRD_规范文档_代码规范.md
问题总结:Docs/PRD/01规范文档/_PRD_问题总结_记录文档.md
方法总结:Docs/PRD/01规范文档/_PRD_方法总结_记录文档.md
文档规范:Docs/PRD/01规范文档/_PRD_规范文档_文档规范.md
测试规范:Docs/PRD/01规范文档/_PRD_规范文档_测试规范.md
\ No newline at end of file
# _PRD_预定系统已删除文件清理需求文档.md
> 版本:V1.0
> 更新日期:2026-01-29
> 适用范围:预定系统被进程占用的已删除文件清理
> 实现脚本:`自动化部署脚本\x86架构\预定系统\定时脚本\cleanup_deleted_files.sh`
---
## 1. 背景与目标
### 1.1 背景
Linux系统中,当文件被删除但仍有进程持有文件句柄时,文件虽然在文件系统中不可见,但仍占用磁盘空间。这类"已删除但被占用"的文件会导致磁盘空间统计不准确和潜在的空间浪费。
### 1.2 目标
实现系统中已删除但被进程占用文件的自动检测和清理功能,具备:
- 自动发现link count为0但仍被打开的文件
- 识别持有这些文件的进程信息
- 向相关进程发送适当信号以释放文件句柄
- 避免强制终止进程保证服务连续性
- 完整的操作日志记录
---
## 2. 总体范围
### 2.1 纳入处理对象
- **检测工具**:lsof +L1(link count为0的文件)
- **目标进程**:持有已删除文件句柄的所有进程
- **处理方式**:发送SIGHUP信号尝试释放文件句柄
### 2.2 不在本期范围
- 强制kill进程释放文件句柄
- 文件内容的恢复或备份
- 磁盘空间的实时监控告警
- 进程行为的深度分析
---
## 3. 术语说明
- **Link Count**:文件的硬链接计数,为0时表示文件已被删除但仍在被使用
- **文件句柄**:进程打开文件时获得的引用标识符
- **SIGHUP信号**:Hang Up信号,通常用于通知进程重新加载配置或释放资源
- **进程优雅重启**:通过信号通知而非强制终止的方式重启进程
---
## 4. 功能需求
### 4.1 检测流程
#### 4.1.1 文件发现
使用lsof命令查找已删除但被占用的文件:
```bash
lsof +L1 2>/dev/null | grep -v "COMMAND"
```
#### 4.1.2 进程信息提取
从lsof输出中提取:
- 进程PID
- 进程命令名称
- 文件描述符信息
- 文件大小等详细信息
#### 4.1.3 进程存活验证
对每个发现的PID执行:
- 检查进程是否仍然存在(kill -0)
- 获取进程的实际命令名称
- 记录进程基本信息
### 4.2 清理策略
#### 4.2.1 信号发送机制
对每个有效的PID执行:
1. 验证进程是否仍然存活
2. 获取进程命令名称用于日志记录
3. 发送SIGHUP信号(kill -HUP)
4. 记录信号发送结果
#### 4.2.2 安全处理原则
- **不强制终止进程**:避免服务中断
- **选择性信号发送**:仅对存活进程发送信号
- **优雅处理失败**:信号发送失败时记录警告而非错误
### 4.3 日志与审计
#### 4.3.1 日志文件
- 主日志:`/var/log/scripts/cleanup_deleted_files.log`
#### 4.3.2 日志内容格式
每行必须包含:
- 时间戳:`YYYY-MM-DD HH:MM:SS`
- 操作类型:开始/发现/处理/警告/完成
- 进程信息和处理结果
示例:
```
[2026-01-29 04:00:00] 开始检查被占用的已删除文件...
[2026-01-29 04:00:01] 发现以下被占用的已删除文件:
[2026-01-29 04:00:01] nginx 1234 cwd DIR 8,1 4096 123456 /var/log/nginx (deleted)
[2026-01-29 04:00:02] 处理进程: PID=1234, CMD=nginx
[2026-01-29 04:00:02] 向 PID 1234 发送 SIGHUP 信号...
[2026-01-29 04:00:05] 检查完成。
```
### 4.4 错误处理
#### 4.4.1 进程状态异常
- PID不存在:记录信息并跳过处理
- 进程命令获取失败:使用默认标识记录
#### 4.4.2 信号处理异常
- SIGHUP信号发送失败:记录警告信息
- 进程不支持信号处理:记录警告但不强制处理
#### 4.4.3 检测工具异常
- lsof命令不存在:记录错误并退出
- 检测结果解析失败:记录警告并继续
---
## 5. 配置参数
| 配置项 | 默认值 | 说明 |
|--------|--------|------|
| LOG_FILE | /var/log/scripts/cleanup_deleted_files.log | 日志文件路径 |
| SIGNAL_TYPE | SIGHUP (-HUP) | 发送的信号类型 |
| CHECK_INTERVAL | 每次执行 | 检测频率 |
---
## 6. 执行要求
### 6.1 执行时机
- 建议:每日凌晨4点执行
- cron配置:`0 4 * * * /opt/scripts/cleanup_deleted_files.sh`
### 6.2 执行环境
- 需要lsof命令支持
- 需要适当的进程操作权限
- 建议在系统负载较低时执行
### 6.3 适用场景
- 适用于支持reload/reopen操作的服务(如Nginx、rsyslog等)
- 不适用于不处理SIGHUP信号的应用程序
- 主要针对日志轮转后残留的文件句柄
---
## 7. 验收标准
1. **检测准确性**
- 能正确识别link count为0的文件
- 准确提取持有文件的进程信息
- 不误报正常文件为已删除文件
2. **处理安全性**
- 不强制终止任何进程
- 信号发送针对正确的PID
- 处理失败时不影响系统稳定性
3. **日志完整性**
- 每次执行都有完整的开始和结束记录
- 发现的文件和处理的进程都有详细记录
- 包含具体的PID、命令名称和处理结果
4. **效果验证**
- 处理后相关文件句柄得到释放
- 磁盘空间统计更加准确
- 不影响相关服务的正常运行
---
## 8. 故障排查
### 8.1 常见问题
1. **lsof命令不存在**
```
command not found: lsof
```
解决:安装lsof工具包
2. **权限不足**:
```
lsof: no permission to read PID list
```
解决:使用root权限执行或调整sudo配置
3. **无文件发现**:
```
未发现被占用的已删除文件。
```
解决:这是正常情况,表示系统clean
### 8.2 效果验证
```bash
# 手动执行检测
sudo /opt/scripts/cleanup_deleted_files.sh
# 查看检测结果
tail -f /var/log/scripts/cleanup_deleted_files.log
# 验证文件句柄状态
lsof +L1
# 检查磁盘空间变化
df -h
# 验证相关服务状态
systemctl status nginx # 或其他相关服务
```
### 8.3 手动清理方法
当自动清理无法解决问题时:
```bash
# 1. 查找已删除文件
lsof +L1
# 2. 识别相关进程
ps -p <PID> -o pid,ppid,cmd
# 3. 重启相关服务(谨慎操作)
systemctl reload nginx
# 或
systemctl restart nginx
```
---
## 需求规范
代码规范:Docs/PRD/01规范文档/_PRD_规范文档_代码规范.md
问题总结:Docs/PRD/01规范文档/_PRD_问题总结_记录文档.md
方法总结:Docs/PRD/01规范文档/_PRD_方法总结_记录文档.md
文档规范:Docs/PRD/01规范文档/_PRD_规范文档_文档规范.md
测试规范:Docs/PRD/01规范文档/_PRD_规范文档_测试规范.md
\ No newline at end of file
# _PRD_预定系统定时脚本需求文档概览.md
> 版本:V1.0
> 更新日期:2026-01-29
> 适用范围:预定系统全套定时监控与维护脚本需求说明
---
## 1. 文档概述
本文档提供了预定系统全套定时脚本的详细需求说明,涵盖服务监控、数据备份、日志管理和系统维护等核心功能模块。
---
## 2. 脚本分类与功能矩阵
### 2.1 服务监控类脚本
| 脚本名称 | 监控对象 | 核心功能 | 执行频率 | 文档链接 |
|---------|---------|---------|---------|---------|
| monitor_emqx_service.sh | EMQX消息队列 | 容器状态+进程检查+服务验证 | 每5分钟 | [_PRD_预定系统_EMQX服务监控需求文档.md](./_PRD_预定系统_EMQX服务监控需求文档.md) |
| monitor_mysql_service.sh | MySQL数据库 | 容器状态+连接测试+SQL验证 | 每5分钟 | [_PRD_预定系统_MySQL服务监控需求文档.md](./_PRD_预定系统_MySQL服务监控需求文档.md) |
| monitor_redis_service.sh | Redis缓存 | 容器状态+认证识别+PING验证 | 每5分钟 | [_PRD_预定系统_Redis服务监控需求文档.md](./_PRD_预定系统_Redis服务监控需求文档.md) |
| monitor_external_api_services.sh | 外部API服务 | 进程监控+目录验证+自动启动 | 每5分钟 | [_PRD_预定系统_外部API服务监控需求文档.md](./_PRD_预定系统_外部API服务监控需求文档.md) |
| monitor_inner_api_services.sh | 内部API服务 | API检查+容器服务+端口监控 | 每5分钟 | [_PRD_预定系统_内部API服务监控需求文档.md](./_PRD_预定系统_内部API服务监控需求文档.md) |
### 2.2 数据备份类脚本
| 脚本名称 | 备份对象 | 核心功能 | 执行频率 | 文档链接 |
|---------|---------|---------|---------|---------|
| backup_mysql_databases.sh | MySQL数据库 | 指定库备份+压缩存储+自动清理 | 每日凌晨1点 | [_PRD_预定系统_MySQL数据库备份需求文档.md](./_PRD_预定系统_MySQL数据库备份需求文档.md) |
| backup_mysql_logs.sh | MySQL日志 | 日志文件备份+权限保持+压缩清理 | 每日凌晨2点 | [_PRD_预定系统_MySQL日志备份需求文档.md](./_PRD_预定系统_MySQL日志备份需求文档.md) |
| backup_nginx_logs.sh | Nginx日志 | 日志轮转+压缩备份+Nginx通知 | 每日凌晨3点 | [_PRD_预定系统_Nginx日志备份需求文档.md](./_PRD_预定系统_Nginx日志备份需求文档.md) |
### 2.3 系统维护类脚本
| 脚本名称 | 维护对象 | 核心功能 | 执行频率 | 文档链接 |
|---------|---------|---------|---------|---------|
| cleanup_deleted_files.sh | 系统文件 | 已删除文件清理+SIGHUP信号 | 每日凌晨4点 | [_PRD_预定系统_已删除文件清理需求文档.md](./_PRD_预定系统_已删除文件清理需求文档.md) |
---
## 3. 统一配置规范
### 3.1 日志配置
- **日志目录**`/var/log/scripts/`
- **日志格式**`[YYYY-MM-DD HH:MM:SS] 日志内容`
- **权限要求**:脚本执行前自动创建目录
### 3.2 执行环境
- **基础权限**:docker命令执行权限
- **网络要求**:本地网络访问(API检查)
- **工具依赖**:curl、netstat/ss/lsof、gzip等标准工具
### 3.3 定时任务配置
```bash
# 预定系统定时任务配置
0 1 * * * /opt/scripts/backup_mysql_databases.sh
0 2 * * * /opt/scripts/backup_mysql_logs.sh
0 3 * * * /opt/scripts/backup_nginx_logs.sh
0 4 * * * /opt/scripts/cleanup_deleted_files.sh
*/5 * * * * /opt/scripts/monitor_emqx_service.sh
*/5 * * * * /opt/scripts/monitor_external_api_services.sh
*/5 * * * * /opt/scripts/monitor_inner_api_services.sh
*/5 * * * * /opt/scripts/monitor_mysql_service.sh
*/5 * * * * /opt/scripts/monitor_redis_service.sh
```
---
## 4. 关键技术特性
### 4.1 智能化监控
- **容器模糊匹配**:自动发现ujava*系列容器
- **认证模式识别**:Redis服务智能识别有无密码认证
- **分级恢复策略**:从简单重启到数据清理的渐进式恢复
- **IP自动获取**:动态识别服务器实际IP地址
### 4.2 安全性保障
- **密码安全管理**:从环境变量获取敏感信息
- **权限最小化**:仅授予必要的操作权限
- **数据保护**:备份过程中的数据完整性保障
- **操作审计**:完整的日志记录和追踪机制
### 4.3 可靠性设计
- **多重验证机制**:容器→进程→服务的逐层验证
- **超时控制**:各项操作设置合理的等待时间
- **错误处理**:完善的异常捕获和处理机制
- **幂等性保证**:重复执行不会产生副作用
---
## 5. 部署与维护
### 5.1 部署步骤
1. **文件准备**:将所有脚本上传至`/opt/scripts/`目录
2. **权限设置**`chmod +x /opt/scripts/*.sh`
3. **日志目录**`mkdir -p /var/log/scripts/`
4. **定时配置**:编辑crontab添加上述定时任务
### 5.2 监控要点
- **日志监控**:定期检查各脚本日志文件
- **执行状态**:确认定时任务正常执行
- **资源使用**:监控磁盘空间和系统负载
- **报警机制**:建立异常情况的通知机制
### 5.3 故障排查
- **实时查看**`tail -f /var/log/scripts/脚本名.log`
- **手动测试**:直接执行脚本验证功能
- **依赖检查**:确认所需命令和权限可用
- **配置验证**:检查路径和服务配置正确性
---
## 6. 性能优化建议
### 6.1 执行时间安排
- **错峰执行**:备份任务安排在业务低峰期
- **负载均衡**:避免多个重量级任务同时执行
- **资源预留**:确保系统有足够的资源处理定时任务
### 6.2 监控优化
- **日志轮转**:定期清理过期日志文件
- **告警阈值**:设置合理的异常检测阈值
- **性能基线**:建立正常的执行时间和资源消耗基线
---
## 7. 扩展性考虑
### 7.1 新增监控项
- 遵循现有脚本结构和命名规范
- 使用统一的日志格式和输出方式
- 保持与现有定时任务的时间协调
### 7.2 配置管理
- 关键参数可通过环境变量配置
- 支持配置文件外部化
- 提供合理的默认值和配置示例
---
## 8. 相关文档
### 8.1 详细需求文档
- [EMQX服务监控需求文档](./_PRD_预定系统_EMQX服务监控需求文档.md)
- [MySQL服务监控需求文档](./_PRD_预定系统_MySQL服务监控需求文档.md)
- [Redis服务监控需求文档](./_PRD_预定系统_Redis服务监控需求文档.md)
- [外部API服务监控需求文档](./_PRD_预定系统_外部API服务监控需求文档.md)
- [内部API服务监控需求文档](./_PRD_预定系统_内部API服务监控需求文档.md)
- [MySQL数据库备份需求文档](./_PRD_预定系统_MySQL数据库备份需求文档.md)
- [MySQL日志备份需求文档](./_PRD_预定系统_MySQL日志备份需求文档.md)
- [Nginx日志备份需求文档](./_PRD_预定系统_Nginx日志备份需求文档.md)
- [已删除文件清理需求文档](./_PRD_预定系统_已删除文件清理需求文档.md)
### 8.2 配置说明文档
- [预定系统定时任务配置说明](../../../自动化部署脚本/x86架构/预定系统/定时脚本/配置说明)
---
## 需求规范
代码规范:Docs/PRD/01规范文档/_PRD_规范文档_代码规范.md
问题总结:Docs/PRD/01规范文档/_PRD_问题总结_记录文档.md
方法总结:Docs/PRD/01规范文档/_PRD_方法总结_记录文档.md
文档规范:Docs/PRD/01规范文档/_PRD_规范文档_文档规范.md
测试规范:Docs/PRD/01规范文档/_PRD_规范文档_测试规范.md
\ No newline at end of file
#!/bin/bash
#===============================================================================
# 脚本名称:backup_mysql_databases.sh
# 功能描述:MySQL数据库定时备份脚本
# 版本:V1.0
# 创建日期:2026-01-27
# 基于文档:_PRD_预定系统_MySQL数据库备份需求文档.md
#
# 备份对象:
# 1. 容器umysql内的指定数据库
# 2. 支持多数据库批量备份
# 3. 自动清理过期备份文件
#
# 备份数据库列表:
# devops, devops_voice, huazhao2, nacos_mysql, offline,
# ubains, wifi, voice, ubains_naco_config, ubains_sso
#
# 使用方法:
# chmod +x backup_mysql_databases.sh
# ./backup_mysql_databases.sh
#
# 定时任务示例:
# 0 1 * * * /opt/scripts/backup_mysql_databases.sh
#===============================================================================
# ==================== 配置区 ====================
CONTAINER_NAME="umysql"
DB_USER="root"
......
#!/bin/bash
#===============================================================================
# 脚本名称:backup_mysql_logs.sh
# 功能描述:MySQL日志文件定时备份与压缩脚本
# 版本:V1.0
# 创建日期:2026-01-27
# 基于文档:_PRD_预定系统_MySQL日志备份需求文档.md
#
# 备份对象:
# 1. MySQL容器日志文件(.log, .slow等)
# 2. 自动压缩备份文件
# 3. 保留原始文件权限
# 4. 自动清理过期备份
#
# 日志文件类型:
# *.log, *.slow, error.log, slow.log, mysqld.log
#
# 使用方法:
# chmod +x backup_mysql_logs.sh
# ./backup_mysql_logs.sh
#
# 定时任务示例:
# 0 2 * * * /opt/scripts/backup_mysql_logs.sh
#===============================================================================
# ==================== 配置区 ====================
MYSQL_LOG_DIR="/opt/mysql/logs" # MySQL日志目录
BACKUP_DIR="/opt/mysql/logs/backup" # 备份目录
......
#!/bin/bash
#===============================================================================
# 脚本名称:backup_nginx_logs.sh
# 功能描述:Nginx日志文件定时备份与压缩脚本
# 版本:V1.0
# 创建日期:2026-01-27
# 基于文档:_PRD_预定系统_Nginx日志备份需求文档.md
#
# 备份对象:
# 1. Nginx访问日志(access.log)
# 2. Nginx错误日志(error.log)
# 3. 自动压缩并清空原日志文件
# 4. 向Nginx发送reopen信号重新打开日志
# 5. 自动清理过期备份
#
# 使用方法:
# chmod +x backup_nginx_logs.sh
# ./backup_nginx_logs.sh
#
# 定时任务示例:
# 0 3 * * * /opt/scripts/backup_nginx_logs.sh
#===============================================================================
# ==================== 配置区 ====================
NGINX_LOG_DIR="/var/www/java/nginx-conf.d/nginx_log" # Nginx日志目录
BACKUP_DIR="$NGINX_LOG_DIR/backup" # 备份目录
......
#!/bin/bash
#===============================================================================
# 脚本名称:cleanup_deleted_files.sh
# 功能描述:清理被进程占用的已删除文件脚本
# 版本:V1.0
# 创建日期:2026-01-27
# 基于文档:_PRD_预定系统_已删除文件清理需求文档.md
#
# 清理对象:
# 1. 使用lsof +L1查找link count为0但仍被进程打开的文件
# 2. 向相关进程发送SIGHUP信号尝试释放文件句柄
# 3. 避免强制kill进程,防止服务中断
# 4. 适用于Nginx、rsyslog等支持reload的服务
#
# 使用方法:
# chmod +x cleanup_deleted_files.sh
# ./cleanup_deleted_files.sh
#
# 定时任务示例:
# 0 4 * * * /opt/scripts/cleanup_deleted_files.sh
#===============================================================================
# clear_deleted_files.sh - 定时清理被进程占用的已删除文件
LOG_FILE="/var/log/scripts/cleanup_deleted_files.log"
......
#!/bin/bash
#===============================================================================
# 脚本名称:monitor_emqx_service.sh
# 功能描述:EMQX服务监测与自愈脚本
# 版本:V1.0
# 创建日期:2026-01-27
# 基于文档:_PRD_预定系统_EMQX服务监控需求文档.md
#
# 监测对象:
# 1. uemqx容器运行状态
# 2. 容器内EMQX进程状态
# 3. EMQX服务可用性(使用emqx_ctl status命令)
# 4. 自动重启异常容器
#
# 恢复策略:
# 1. 检查容器是否运行
# 2. 检查EMQX进程是否存在
# 3. 验证服务状态是否正常
# 4. 异常时自动重启容器
# 5. 重启后验证服务恢复情况
#
# 使用方法:
# chmod +x monitor_emqx_service.sh
# ./monitor_emqx_service.sh
#
# 定时任务示例:
# */5 * * * * /opt/scripts/monitor_emqx_service.sh
#===============================================================================
# 宿主机上的脚本:检查 EMQX,如果容器未运行则重启 uemqx 容器
LOG_FILE="/var/log/scripts/monitor_emqx_service.log"
......
#!/bin/bash
#===============================================================================
# 脚本名称:monitor_external_api_services.sh
# 功能描述:外部API服务监测与自愈脚本
# 版本:V1.0
# 创建日期:2026-01-27
# 基于文档:_PRD_预定系统_外部API服务需求文档.md
#
# 监测对象:
# 1. ubains-meeting-api-1.0-SNAPSHOT.jar服务
# 2. malan服务
# 3. 宿主机进程运行状态
# 4. 服务目录和启动脚本存在性
#
# 恢复策略:
# 1. 检查进程是否运行(pgrep -f)
# 2. 验证服务目录是否存在
# 3. 检查启动脚本权限
# 4. 异常时自动启动服务
# 5. 启动后验证进程状态
#
# 使用方法:
# chmod +x monitor_external_api_services.sh
# ./monitor_external_api_services.sh
#
# 定时任务示例:
# */5 * * * * /opt/scripts/monitor_external_api_services.sh
#===============================================================================
# --- 配置区域 ---
# 日志文件路径
LOG_FILE="/var/log/scripts/monitor_external_api_services.log"
......
#!/bin/bash
#===============================================================================
# 脚本名称:monitor_mysql_service.sh
# 功能描述:MySQL服务监测与自愈脚本
# 版本:V1.0
# 创建日期:2026-01-27
# 基于文档:_PRD_预定系统_MySQL服务监控需求文档.md
#
# 监测对象:
# 1. umysql容器运行状态
# 2. MySQL服务连接可用性
# 3. SQL查询执行能力
# 4. 数据库基本功能验证
#
# 恢复策略:
# 1. 检查容器是否运行
# 2. 获取MySQL root密码
# 3. 测试mysqladmin ping连接
# 4. 验证SELECT 1查询执行
# 5. 异常时自动重启容器
# 6. 重启后验证服务恢复
#
# 使用方法:
# chmod +x monitor_mysql_service.sh
# ./monitor_mysql_service.sh
#
# 定时任务示例:
# */5 * * * * /opt/scripts/monitor_mysql_service.sh
#===============================================================================
# 宿主机上的脚本:检查 MySQL,如果容器未运行则重启 umysql 容器
LOG_FILE="/var/log/scripts/monitor_mysql_service.log"
......
#!/bin/bash
#===============================================================================
# 脚本名称:monitor_redis_service.sh
# 功能描述:Redis服务监测与自愈脚本
# 版本:V1.0
# 创建日期:2026-01-27
# 基于文档:_PRD_预定系统_Redis服务监控需求文档.md
#
# 监测对象:
# 1. uredis容器运行状态
# 2. Redis服务连接可用性
# 3. 认证状态检查(支持有密码/无密码)
# 4. PING命令响应验证
#
# 恢复策略:
# 1. 检查容器是否运行
# 2. 测试无密码PING连接
# 3. 如需认证则使用预设密码测试
# 4. 异常时自动重启容器
# 5. 重启失败时清理数据目录重试
# 6. 重启后验证服务恢复
#
# 使用方法:
# chmod +x monitor_redis_service.sh
# ./monitor_redis_service.sh
#
# 定时任务示例:
# */5 * * * * /opt/scripts/monitor_redis_service.sh
#===============================================================================
# 宿主机上的脚本:检查 Redis,如果容器未运行则重启 uredis 容器
LOG_FILE="/var/log/scripts/monitor_redis_service.log"
......
......@@ -33,36 +33,87 @@ crontab -e
# ==================== 预定系统定时任务配置 ====================
# 每日凌晨1点备份MySQL数据库
# 功能:备份umysql容器内指定的10个数据库,自动清理30天前的备份
0 1 * * * /opt/scripts/backup_mysql_databases.sh
# 每日凌晨2点备份MySQL日志
# 功能:备份MySQL日志文件(.log/.slow),保留原始权限,自动清理过期备份
0 2 * * * /opt/scripts/backup_mysql_logs.sh
# 每日凌晨3点备份Nginx日志
# 功能:备份Nginx访问日志和错误日志,压缩后清空原文件并通知Nginx重新打开日志
0 3 * * * /opt/scripts/backup_nginx_logs.sh
# 每日凌晨4点检查并清理被占用的已删除文件
# 功能:查找link count为0但仍被进程占用的文件,发送SIGHUP信号释放句柄
0 4 * * * /opt/scripts/cleanup_deleted_files.sh
# 每5分钟监测EMQX服务状态
# 功能:检查uemqx容器运行状态、EMQX进程存在性和服务可用性,异常时自动重启
*/5 * * * * /opt/scripts/monitor_emqx_service.sh
# 每5分钟监测外部API服务状态
# 功能:监测ubains-meeting-api和malan服务进程,目录存在性,异常时自动启动
*/5 * * * * /opt/scripts/monitor_external_api_services.sh
# 每5分钟监测内部API服务状态
# 功能:检查平台API可用性、容器内meeting2.0服务和宿主机6060端口malan服务
*/5 * * * * /opt/scripts/monitor_inner_api_services.sh
# 每5分钟监测MySQL服务状态
# 功能:检查umysql容器、MySQL连接可用性和SQL执行能力,异常时自动重启
*/5 * * * * /opt/scripts/monitor_mysql_service.sh
# 每5分钟监测Redis服务状态
# 功能:检查uredis容器、Redis连接和认证状态,支持密码认证,异常时自动重启
*/5 * * * * /opt/scripts/monitor_redis_service.sh
# ==================== 定时任务结束 ====================
```
## 四、注意事项
## 四、脚本功能详解
### 数据库相关脚本
- **backup_mysql_databases.sh**: MySQL数据库备份脚本
- 备份容器:umysql
- 备份数据库:10个核心业务数据库
- 特色功能:容器内临时目录处理、PID防冲突、自动清理
- **backup_mysql_logs.sh**: MySQL日志备份脚本
- 备份类型:.log, .slow, error.log等日志文件
- 特色功能:权限保存恢复、自动压缩、保留原始文件
### 服务监测脚本
- **monitor_emqx_service.sh**: EMQX消息队列服务监测
- 监测维度:容器状态、进程存在性、服务可用性
- 恢复机制:容器重启、服务状态验证
- **monitor_mysql_service.sh**: MySQL数据库服务监测
- 监测维度:容器运行、连接测试、SQL执行验证
- 恢复机制:容器重启、密码获取、功能验证
- **monitor_redis_service.sh**: Redis缓存服务监测
- 监测维度:容器状态、认证检查、PING响应
- 恢复机制:密码认证、数据清理、容器重启
- **monitor_external_api_services.sh**: 外部API服务监测
- 监测服务:meeting-api、malan服务
- 监测方式:进程检查、目录验证、脚本执行
- **monitor_inner_api_services.sh**: 内部API服务监测
- 监测对象:平台API、容器内服务、6060端口
- 特色功能:IP自动获取、容器模糊匹配、分级恢复
### 系统维护脚本
- **backup_nginx_logs.sh**: Nginx日志备份脚本
- 处理文件:access.log, error.log
- 特色功能:日志轮转、Nginx信号通知、权限保持
- **cleanup_deleted_files.sh**: 已删除文件清理脚本
- 处理对象:被进程占用的已删除文件
- 处理方式:SIGHUP信号释放、避免强制kill
## 五、注意事项
1. **日志输出**:所有脚本已在内部实现日志输出功能,无需在 crontab 中重定向输出
......@@ -74,7 +125,11 @@ crontab -e
5. **备份保留**:日志和备份文件会保留30天,如需调整保留时间请修改脚本中的 RETENTION_DAYS 参数
## 五、故障排查
6. **密码管理**:Redis脚本中包含硬编码密码,请根据实际情况修改
7. **容器名称**:支持容器名称模糊匹配(ujava*, uemqx, umysql, uredis)
## 六、故障排查
1. **检查脚本权限**:
```bash
......@@ -91,3 +146,20 @@ crontab -e
tail -f /var/log/scripts/脚本名.log
```
4. **手动执行脚本测试**:
```bash
/opt/scripts/脚本名.sh
```
5. **检查日志目录权限**:
```bash
ls -ld /var/log/scripts/
```
## 七、维护建议
1. **定期检查**:建议每日检查关键服务监测脚本的执行情况
2. **备份验证**:定期验证备份文件的完整性和可恢复性
3. **日志清理**:监控日志文件大小,避免磁盘空间不足
4. **性能监控**:关注脚本执行时间和系统资源消耗
5. **版本更新**:及时更新脚本以适应系统变更
Markdown 格式
0%
您添加了 0 到此讨论。请谨慎行事。
请先完成此评论的编辑!
注册 或者 后发表评论