# ADR-060: 全面基礎設施監控告警與自動修復架構

**狀態**: 已批准 (首席架構師裁示 2026-04-08)
**日期**: 2026-04-08
**提案者**: Claude Code
**審核者**: 統帥 (首席架構師)

---

## 背景

AWOOOI 平台現有監控主要覆蓋 K3s 層 (Prometheus + Alertmanager → AWOOOI API → Telegram)。
四台主機上的 Docker 服務、系統服務、外部網站共 **30+ 個服務/容器** 缺乏監控告警。

## 問題陳述

| 層 | 服務數 | 目前監控 | 告警 | 自動修復 |
|----|--------|---------|------|---------|
| K3s Pods | ~15 | ✅ Prometheus | ✅ Alertmanager | ✅ 部分 |
| Docker 容器 (110) | ~35 | ❌ | ❌ | ❌ |
| Docker 容器 (188) | ~12 | ❌ | ❌ | ❌ |
| 系統服務 (188) | 3 (PG/Redis/Nginx) | ❌ | ❌ | ❌ |
| 外部網站 | 4 個 | ❌ | ❌ | ❌ |

## 決策

### 分三層實施

**Plan A — Docker 容器健康監控 (P0)**
- 部署 `docker-health-monitor.sh` cron 腳本至 110 和 188 主機
- 每 5 分鐘主動偵測容器狀態 (unhealthy / exited / dead)
- Intent → Action → Result 三階段通知流程
- 透過 HMAC 簽名呼叫 AWOOOI API `/api/v1/webhooks/alerts`
- Telegram Bot API 直接推送作為 Fallback

**Plan B — Prometheus Exporter 補齊 (P0)**
- `postgres_exporter` (9187) → PostgreSQL awoooi_prod 深度指標
- `redis_exporter` (9121) → Redis 連線/記憶體/延遲
- `nginx-prometheus-exporter` (9113) → Nginx 流量/連線
- 部署於 188，加入 Prometheus scrape config
- 新增 `alerts-unified.yml` 詳細規則

**Plan C — Blackbox 外部網站補齊 (P1)**
- 4 個外部產品網站加入 Blackbox HTTP probe
- mo.wooo.work / tsenyang.wooo.work / stock.wooo.work / bitan.wooo.work
- SSL 憑證到期預警 (14 天)

### 自動修復策略 (首席架構師裁示)

| 服務類型 | 策略 | 動作 |
|---------|------|------|
| Docker 容器 (非 DB/監控) | **自動修復** | `docker restart` |
| Nginx systemd | **自動修復** | `systemctl restart nginx` |
| Prometheus/Grafana/Alertmanager | **自動啟動** | `docker start`（非 restart，保護 WAL） |
| PostgreSQL | **僅告警** | 禁止自動重啟（資料安全） |
| Redis | **僅告警** | 禁止自動重啟（告警鏈依賴） |
| 外部網站 Down | **自動修復** | 對應容器 `docker restart` |
| 主機間網路中斷 | **僅告警** | 網路問題不自動修復 |

### 通知順序 (首席架構師裁示)

**必須**: Intent → Action → Result

```
Telegram: [AI 決策] 偵測到 <容器> 異常，準備執行 Docker Restart...
系統: 執行重啟
Telegram: [執行結果] <容器> 重啟成功 / 失敗，需人工介入
```

## 備份與還原體系

### PostgreSQL awoooi_prod
- 工具: Restic + GFS (已有 backup-awoooi.sh)
- 頻率: 每 6 小時 (頻繁) + 每日完整備份 02:00
- 保留: daily=14, weekly=8, monthly=12
- 還原 RTO: < 30 分鐘

### Docker Volume 備份
- momo-db, harbor-db, sentry-postgres
- 工具: `docker exec pg_dump` → Restic
- 頻率: 每日 03:00

### 備份驗證
- 每月第一個週日 03:00 執行 DR Drill
- 從最新快照還原到臨時容器，執行 SQL 驗證
- 結果推送 Telegram

## 操作記錄體系

所有操作必須寫入 `alert_operation_log` 表 (ADR-061)：
- Docker 健康監控的修復記錄
- 備份操作 (BACKUP_COMPLETED / BACKUP_FAILED)
- 變更記錄 (CHANGE_APPLIED)
- DR 演練 (DR_DRILL_COMPLETED)

## 備援方案 (Fallback)

| 情境 | 備援 |
|------|------|
| AWOOOI API Down | docker-health-monitor.sh 直接呼叫 Telegram Bot API |
| Prometheus Down | Alertmanager 直接 telegram_configs |
| Redis Down | 告警去重退化為記憶體模式 (60s 窗口)，Webhook 端點不受影響 |

## 結果

- 監控覆蓋率: 15/15 targets → **45+ targets** (新增 Docker/系統/外部網站)
- 告警盲區: **0** (設計目標)
- MTTR: Docker 服務 < 2 分鐘 (自動修復)

## 相關文件

- ADR-025: Alert Chain E2E Validation
- ADR-030: Intelligent Auto-Remediation
- ADR-058: Host Auto-Repair SSH Whitelist
- ADR-061: Alert Operation Log Event Sourcing
- `ops/monitoring/alerts-unified.yml`
- `ops/monitoring/docker-compose.exporters.yaml`
- `scripts/ops/docker-health-monitor.sh` (待建立)
