feat: monitor cloud server health
This commit is contained in:
Codex Local
@@ -181,6 +181,7 @@
|
||||
| 隐私删除并发 | 100个并发受理全部成功、HTTP失败率0%、提交p95 385.15ms；11.58秒内600个子任务、100个墓碑和100个主体冻结全部对账 |
|
||||
| PostgreSQL隔离恢复 | 实际`pg_dump`/`pg_restore`到随机隔离库，迁移`22|false`、66张表、190个外键和关键计数一致；本地约5.14秒，临时库/备份已清理 |
|
||||
| 阿里云单机加密备份与恢复 | 目标服务器已安装每日systemd备份任务，覆盖PostgreSQL、认证Redis RDB、MinIO全部桶和暂停后的Keycloak数据目录；归档使用AES-256-CBC/PBKDF2加密、逐文件SHA-256并保留14天。首次实际归档成功，数据库从V38备份恢复到随机隔离库后`38|false|2|3|73|215`六项证据一致，归档内Redis RDB格式有效、Keycloak 3个文件一致、临时恢复库为0；同机备份尚不作为跨故障域生产恢复证据 |
|
||||
| 阿里云单机健康监测 | 目标服务器已安装五分钟systemd健康检查，结构化状态覆盖HTTPS、OIDC签发地址、11个常驻容器、备份新鲜度与摘要、备份执行结果、备份/证书timer、短期IP证书剩余时间和磁盘阈值。实际正常路径20项全部healthy；把备份最大年龄临时设为0秒后仅`backup_freshness`进入critical并退出1，测试目录已清理且线上容器未停止。可选Webhook仅在状态变化时发送带时间戳和HMAC-SHA256的脱敏状态；真实接收器尚未配置，因此不作为值班通知送达证据 |
|
||||
| 进程与Redis恢复 | API/Callbacks/Worker重启恢复；停机期间Outbox仅执行一次；Redis 14个热状态键清空后由签名设备请求重建，PostgreSQL权威计数不变 |
|
||||
| 供应商故障恢复 | V23持久化按租户/供应商的可用状态；连续临时失败暂停新启动但停止任务继续尝试；演练确认暂停后新外呼0、停止尝试2次、历史接口200、CRITICAL告警出现，恢复后全部收敛；V23单版本回退/重升通过 |
|
||||
| 安全专项 | Go 1.26.6容器`govulncheck`可达漏洞0、npm高危审计0、最终镜像HIGH/CRITICAL已修复漏洞0、Gitleaks无泄漏；HTTP认证/授权/注入式输入/1MiB正文/回调签名/Nonce重放/安全头/日志过滤烟测通过 |
|
||||
|
||||
@@ -0,0 +1,123 @@
|
||||
# 单机云端健康监测与告警手册
|
||||
|
||||
## 1. 目标与边界
|
||||
|
||||
`deploy/server/health-monitor.sh`为单机阿里云演示环境提供五分钟一次的轻量健康检查。它用于发现“公网入口不可用、身份签发地址漂移、容器退出、备份过期或损坏、证书接近到期、定时任务停止、磁盘空间不足”等直接影响可用性的问题。
|
||||
|
||||
该脚本不替代Prometheus、Grafana、云监控或真实值班系统。默认只写结构化状态文件和systemd日志；配置外部接收器后，状态发生变化时才发送一次HMAC签名Webhook，避免每五分钟重复通知。
|
||||
|
||||
## 2. 检查项
|
||||
|
||||
| 检查 | 正常条件 | 失败状态 |
|
||||
|---|---|---|
|
||||
| 公网地址 | `PUBLIC_ORIGIN`为HTTPS | `invalid_https_origin` |
|
||||
| HTTPS入口 | `/api/v1/version`在10秒内返回成功 | `request_failed` |
|
||||
| OIDC | Discovery中的`issuer`与公网地址完全一致 | `issuer_mismatch`或`request_failed` |
|
||||
| 容器 | PostgreSQL、Redis、MinIO、Keycloak、API、Callbacks、Worker、Web、Gateway和两个模拟服务均为运行态；有健康检查的容器必须为healthy | `missing`、容器状态或健康状态 |
|
||||
| 备份 | 最新加密归档不超过36小时且外层SHA-256有效 | `missing`、`age_seconds=...`或`checksum_failed` |
|
||||
| 备份任务 | 最近一次`platform-backup.service`结果成功且退出码为0 | `result=.../exit=...` |
|
||||
| 定时任务 | 备份和证书续期timer均为enabled/active | 当前启用/活动状态 |
|
||||
| 证书 | 本地活动证书剩余时间不少于36小时 | `missing`或`remaining_seconds=...` |
|
||||
| 磁盘 | 低于80%为健康，80%—89%为warning，90%及以上为critical | `used_percent=...` |
|
||||
|
||||
状态文件写入`/var/lib/data-terminal-cloud-monitor/status.json`，格式为`platform-server-health-v1`。每个检查只有稳定名称、状态和脱敏值，不包含数据库密码、Webhook地址、证书正文、业务数据或令牌。
|
||||
|
||||
## 3. 状态模型
|
||||
|
||||
```text
|
||||
全部检查健康 → healthy，退出0
|
||||
没有critical但存在warning → warning，退出0
|
||||
任一检查critical → critical，退出1
|
||||
```
|
||||
|
||||
systemd oneshot任务成功结束后显示`inactive (dead)`属于正常行为，应使用以下字段判断：
|
||||
|
||||
```bash
|
||||
systemctl show platform-health-monitor.service -p Result -p ExecMainStatus -p ActiveState
|
||||
```
|
||||
|
||||
期望结果为`Result=success`、`ExecMainStatus=0`。状态为critical时服务会显示失败，timer仍会在下一个周期继续执行。
|
||||
|
||||
## 4. 安装与运行
|
||||
|
||||
```bash
|
||||
cd /opt/data-terminal-cloud/current
|
||||
chmod 0755 deploy/server/health-monitor.sh deploy/server/install-monitoring.sh
|
||||
deploy/server/install-monitoring.sh
|
||||
systemctl start platform-health-monitor.service
|
||||
systemctl list-timers platform-health-monitor.timer --no-pager
|
||||
python3 -m json.tool /var/lib/data-terminal-cloud-monitor/status.json
|
||||
```
|
||||
|
||||
定时任务在开机两分钟后首次执行，之后每五分钟执行并附加最多30秒随机延迟。`Persistent=true`确保错过计划时间后补跑。
|
||||
|
||||
## 5. 可选Webhook通知
|
||||
|
||||
安装脚本创建：
|
||||
|
||||
- `/etc/data-terminal-cloud/monitor.env`：`0600 root:root`；
|
||||
- `/etc/data-terminal-cloud/monitor-webhook-secret`：独立随机HMAC密钥，`0600 root:root`。
|
||||
|
||||
编辑配置：
|
||||
|
||||
```bash
|
||||
ALERT_WEBHOOK_URL=https://receiver.example.com/platform-health
|
||||
ALERT_WEBHOOK_SECRET_FILE=/etc/data-terminal-cloud/monitor-webhook-secret
|
||||
```
|
||||
|
||||
只有总体状态发生变化时才发送JSON状态文件。请求包含：
|
||||
|
||||
- `Content-Type: application/json`；
|
||||
- `X-Platform-Timestamp`：Unix秒；
|
||||
- `X-Platform-Signature: sha256=<hex>`；
|
||||
- 签名正文：`HMAC-SHA256(secret, timestamp + "." + raw_body)`。
|
||||
|
||||
接收端应限制时间偏差、按时间戳和签名去重并使用恒定时间比较。Webhook地址和密钥不会进入状态文件或日志。正式配置前应先在接收端完成验签联通测试。
|
||||
|
||||
## 6. 参数
|
||||
|
||||
| 环境变量 | 默认值 | 说明 |
|
||||
|---|---|---|
|
||||
| `BACKUP_MAX_AGE_SECONDS` | `129600` | 最新备份最大年龄，36小时 |
|
||||
| `CERTIFICATE_MIN_SECONDS` | `129600` | 证书最小剩余时间，36小时 |
|
||||
| `DISK_WARNING_PERCENT` | `80` | 磁盘警告阈值 |
|
||||
| `DISK_CRITICAL_PERCENT` | `90` | 磁盘严重阈值 |
|
||||
| `MONITOR_STATE_DIR` | `/var/lib/data-terminal-cloud-monitor` | 原子状态文件目录 |
|
||||
| `MONITOR_CONFIG_FILE` | `/etc/data-terminal-cloud/monitor.env` | 可选通知配置 |
|
||||
| `TLS_CERTIFICATE_FILE` | 根据`PUBLIC_ORIGIN`主机名推导 | 当前活动证书文件 |
|
||||
|
||||
阈值只能使用非负整数，磁盘警告阈值必须小于严重阈值。普通调整无需重建镜像，但应记录变更理由并重新执行一次手工检查。
|
||||
|
||||
## 7. 验收与排障
|
||||
|
||||
正常路径：
|
||||
|
||||
```bash
|
||||
/opt/data-terminal-cloud/current/deploy/server/health-monitor.sh
|
||||
```
|
||||
|
||||
不改变线上状态的备份过期失败分支：
|
||||
|
||||
```bash
|
||||
test_dir=$(mktemp -d /var/tmp/platform-monitor-test-XXXXXX)
|
||||
MONITOR_STATE_DIR="$test_dir" MONITOR_CONFIG_FILE=/dev/null \
|
||||
BACKUP_MAX_AGE_SECONDS=0 \
|
||||
/opt/data-terminal-cloud/current/deploy/server/health-monitor.sh
|
||||
```
|
||||
|
||||
期望退出1，状态为critical，唯一人工注入的严重检查为`backup_freshness`。测试目录验证后应精确删除。
|
||||
|
||||
常用排障命令：
|
||||
|
||||
```bash
|
||||
journalctl -u platform-health-monitor.service -n 100 --no-pager
|
||||
systemctl list-timers platform-health-monitor.timer platform-backup.timer certbot-ip-renew.timer --no-pager
|
||||
docker compose -f compose.yaml -f deploy/server/compose.override.yaml --env-file deploy/server/.env ps -a
|
||||
```
|
||||
|
||||
## 8. 下一步生产化
|
||||
|
||||
1. 配置真实告警网关、主值班组和升级组，并完成HMAC验签联通测试。
|
||||
2. 将状态接入云监控或Prometheus长期存储，建立可用率和告警送达趋势。
|
||||
3. 将加密备份复制到不同故障域，并对“异地复制最后成功时间”增加检查。
|
||||
4. 使用外部OIDC、托管数据库/Redis/对象存储后，把资源级高可用、PITR和容量指标纳入同一状态模型。
|
||||
Reference in New Issue
Block a user