1e7c5134fe
- 異常頻率追蹤架構 (Redis 計數器 + 滑動窗口) - 修復策略分級 (Tier 1-4: 重啟→緩解→根因→架構) - AI 學習服務 (LearningService + Playbook 自動更新) - Telegram 頻率告警格式 (重複次數 + 成功率統計) - 實作清單 (P0: 22h, P1: 12h, P2: 8h) 🔴 關鍵觀點: 重啟只是治標，不是治本 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
942 lines
55 KiB
Markdown
942 lines
55 KiB
Markdown
# AWOOOI 監控戰略規劃 - 全面性討論
|
||
|
||
> **版本**: v1.0 DRAFT
|
||
> **建立日期**: 2026-03-29
|
||
> **狀態**: 待統帥審核
|
||
> **目標**: 從問題發生到解決的全閉環、角色分層、零遺漏
|
||
|
||
---
|
||
|
||
## 一、核心原則定錨
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────────────────────┐
|
||
│ 監控金三角 (必須同時達成) │
|
||
├─────────────────────────────────────────────────────────────────────┤
|
||
│ │
|
||
│ 即時性 ←──────────────────→ 完整性 │
|
||
│ ↑ ↑ │
|
||
│ │ │ │
|
||
│ │ 監控 │ │
|
||
│ │ │ │
|
||
│ └───────────┬───────────────┘ │
|
||
│ ↓ │
|
||
│ 可行動性 │
|
||
│ │
|
||
│ 即時性: 發生 → 告警 < 30 秒 │
|
||
│ 完整性: 從觸發到解決的完整時間軸 │
|
||
│ 可行動性: 每個告警都有明確的 Next Action │
|
||
│ │
|
||
└─────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
### 1.1 監控閉環時序目標
|
||
|
||
| 階段 | 目標時效 | 說明 |
|
||
|------|----------|------|
|
||
| **T0: 異常發生** | 0s | 系統出現異常狀態 |
|
||
| **T1: 偵測** | < 15s | Prometheus/Sentry/SignOz 捕獲 |
|
||
| **T2: 告警觸發** | < 30s | Alertmanager 發送到 AWOOOI |
|
||
| **T3: AI 分析** | < 60s | OpenClaw 完成根因分析 |
|
||
| **T4: 通知到人** | < 90s | Telegram 推送 (含建議方案) |
|
||
| **T5: 決策** | < 5min | 人工審核或自動執行 |
|
||
| **T6: 執行** | < 1min | K8s Executor 執行修復 |
|
||
| **T7: 驗證** | < 2min | 健康檢查確認修復成功 |
|
||
| **T8: 報告** | 即時 | 完整時間軸報告生成 |
|
||
|
||
**總目標: 從異常到修復 < 10 分鐘 (P0 Critical)**
|
||
|
||
---
|
||
|
||
## 二、現有產品/架構/規範全面清查
|
||
|
||
### 2.1 已實作清單 (截至 2026-03-29)
|
||
|
||
| 類別 | 項目 | 實作狀態 | 即時性 | 完整性 | 可行動性 |
|
||
|------|------|----------|--------|--------|----------|
|
||
| **基礎設施** | K8s Pod 健康 | ✅ Prometheus | ✅ | ✅ | ⚠️ 需 OpenClaw |
|
||
| | Node 資源 | ✅ node-exporter | ✅ | ✅ | ⚠️ |
|
||
| | etcd 狀態 | ✅ K3s 內建 | ✅ | ⚠️ | ❌ |
|
||
| **應用層** | API 錯誤率 | ✅ Sentry | ✅ | ✅ | ✅ |
|
||
| | API 延遲 | ✅ SignOz | ✅ | ✅ | ⚠️ |
|
||
| | 前端錯誤 | ✅ Sentry | ✅ | ⚠️ | ⚠️ |
|
||
| **資料層** | PostgreSQL | ⚠️ 部分 | ⚠️ | ❌ | ❌ |
|
||
| | Redis | ⚠️ 部分 | ⚠️ | ❌ | ❌ |
|
||
| **AI/LLM** | Ollama | ⚠️ 健康檢查 | ⚠️ | ❌ | ❌ |
|
||
| | Token 成本 | ✅ Langfuse | ✅ | ✅ | ⚠️ |
|
||
| **CI/CD** | GitHub Runner | ⚠️ healthcheck | ⚠️ | ❌ | ❌ |
|
||
| | Harbor | ⚠️ | ⚠️ | ❌ | ❌ |
|
||
| **告警通道** | Telegram 推送 | ✅ | ✅ | ✅ | ✅ |
|
||
| | Telegram 按鈕 | ✅ 剛修復 | ✅ | ✅ | ✅ |
|
||
| **AI 分析** | OpenClaw | ✅ | ✅ | ✅ | ✅ |
|
||
| **自動修復** | K8s Executor | ✅ 部分動作 | ✅ | ⚠️ | ⚠️ |
|
||
| **報告** | 時間軸 | ❌ 缺失 | ❌ | ❌ | ❌ |
|
||
|
||
### 2.2 關鍵缺口分析
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────────────────────┐
|
||
│ 缺口優先級矩陣 │
|
||
├─────────────────────────────────────────────────────────────────────┤
|
||
│ │
|
||
│ 影響 │
|
||
│ ↑ │
|
||
│ │ ┌─────────────┐ │
|
||
│ 高 │ │ P0 區域 │ • 靜默失敗 (try/except 吞錯誤) │
|
||
│ │ │ 立即修復 │ • 時間軸報告缺失 │
|
||
│ │ └─────────────┘ • 資料庫監控不足 │
|
||
│ │ │
|
||
│ 中 │ ┌─────────────┐ │
|
||
│ │ │ P1 區域 │ • SignOz 告警規則 │
|
||
│ │ │ 本週內 │ • 自動修復動作擴展 │
|
||
│ │ └─────────────┘ • CI/CD 監控 │
|
||
│ │ │
|
||
│ 低 │ ┌─────────────┐ │
|
||
│ │ │ P2 區域 │ • Grafana 儀表板 │
|
||
│ │ │ 後續迭代 │ • SLO/SLI 定義 │
|
||
│ │ └─────────────┘ • 容量預測 │
|
||
│ │ │
|
||
│ └──────────────────────────────────────────────────────────────→ │
|
||
│ 低 中 高 頻率 │
|
||
│ │
|
||
└─────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 三、角色分層架構 (Role-Based Views)
|
||
|
||
### 3.1 為什麼需要分層？
|
||
|
||
現有的「全局戰情室」設計目標是 **運維人員 (SRE/DevOps)**：
|
||
- 顯示所有技術細節
|
||
- kubectl 指令、Pod 狀態、Trace ID
|
||
- 需要技術背景才能理解
|
||
|
||
但實際使用者包含多種角色：
|
||
|
||
| 角色 | 關注點 | 需要的資訊 | 不需要的資訊 |
|
||
|------|--------|-----------|-------------|
|
||
| **CEO** | 業務影響 | 收入損失、用戶影響、SLA 達標率 | kubectl 指令、Pod 名稱 |
|
||
| **CTO** | 技術決策 | 架構風險、技術債、系統健康度 | 單一 Pod 細節 |
|
||
| **CIO** | 整體營運 | 成本、效率、資源使用率 | 代碼層級錯誤 |
|
||
| **CISO** | 安全事件 | 安全告警、異常存取、合規狀態 | 效能指標 |
|
||
| **Team Lead** | 團隊負責範圍 | 自己團隊的服務狀態 | 其他團隊細節 |
|
||
| **On-Call** | 即時處理 | 所有告警、處理建議、執行按鈕 | 歷史趨勢 |
|
||
| **開發者** | 自己的代碼 | 錯誤堆疊、相關 Commit | 基礎設施狀態 |
|
||
|
||
### 3.2 分層架構設計
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────────────────────┐
|
||
│ AWOOOI 監控分層架構 │
|
||
├─────────────────────────────────────────────────────────────────────┤
|
||
│ │
|
||
│ ┌─────────────────────────────────────────────────────────────┐ │
|
||
│ │ Layer 0: Executive Dashboard │ │
|
||
│ │ (CEO/CTO/CIO/CISO) │ │
|
||
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
|
||
│ │ │ 系統 │ │ 本月 │ │ SLA │ │ 安全 │ │ │
|
||
│ │ │ 健康度 │ │ 成本 │ │ 達標率 │ │ 事件數 │ │ │
|
||
│ │ │ 98.5% │ │ $1,234 │ │ 99.9% │ │ 0 │ │ │
|
||
│ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ │
|
||
│ │ │ │
|
||
│ │ 🟢 正常運作中 | 最近事件: 2 小時前 (已自動修復) │ │
|
||
│ └─────────────────────────────────────────────────────────────┘ │
|
||
│ ↓ │
|
||
│ ┌─────────────────────────────────────────────────────────────┐ │
|
||
│ │ Layer 1: Ops Center │ │
|
||
│ │ (Team Lead / Manager) │ │
|
||
│ │ │ │
|
||
│ │ ┌──────────────────────────────────────────────────────┐ │ │
|
||
│ │ │ 團隊: Backend │ │ │
|
||
│ │ │ ├─ awoooi-api: 🟢 Healthy (2/2 pods) │ │ │
|
||
│ │ │ ├─ awoooi-worker: 🟢 Healthy (1/1 pods) │ │ │
|
||
│ │ │ └─ 本週事件: 3 (已解決: 3) │ │ │
|
||
│ │ └──────────────────────────────────────────────────────┘ │ │
|
||
│ │ │ │
|
||
│ │ ┌──────────────────────────────────────────────────────┐ │ │
|
||
│ │ │ 團隊: Frontend │ │ │
|
||
│ │ │ ├─ awoooi-web: 🟢 Healthy (2/2 pods) │ │ │
|
||
│ │ │ └─ 本週事件: 1 (已解決: 1) │ │ │
|
||
│ │ └──────────────────────────────────────────────────────┘ │ │
|
||
│ └─────────────────────────────────────────────────────────────┘ │
|
||
│ ↓ │
|
||
│ ┌─────────────────────────────────────────────────────────────┐ │
|
||
│ │ Layer 2: War Room (現有全局戰情室) │ │
|
||
│ │ (On-Call / SRE / DevOps) │ │
|
||
│ │ │ │
|
||
│ │ 完整技術細節: │ │
|
||
│ │ - 即時告警清單 │ │
|
||
│ │ - AI 分析結果 │ │
|
||
│ │ - kubectl 指令 │ │
|
||
│ │ - 簽核按鈕 (Y/n) │ │
|
||
│ │ - Timeline 時間軸 │ │
|
||
│ │ - SignOz Trace 連結 │ │
|
||
│ │ - Sentry Issue 連結 │ │
|
||
│ └─────────────────────────────────────────────────────────────┘ │
|
||
│ ↓ │
|
||
│ ┌─────────────────────────────────────────────────────────────┐ │
|
||
│ │ Layer 3: Developer Console │ │
|
||
│ │ (開發者) │ │
|
||
│ │ │ │
|
||
│ │ - 自己負責服務的錯誤 │ │
|
||
│ │ - Stack Trace │ │
|
||
│ │ - 相關 Commit / PR │ │
|
||
│ │ - 修復建議 │ │
|
||
│ └─────────────────────────────────────────────────────────────┘ │
|
||
│ │
|
||
└─────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
### 3.3 路徑規劃
|
||
|
||
| 階段 | 內容 | 優先級 |
|
||
|------|------|--------|
|
||
| **現在** | Layer 2 (War Room) - 已存在的全局戰情室 | ✅ 已有 |
|
||
| **Phase 1** | Layer 0 (Executive) - C-Level 儀表板 | P2 |
|
||
| **Phase 2** | Layer 1 (Ops Center) - 團隊視圖 | P2 |
|
||
| **Phase 3** | Layer 3 (Developer) - 開發者控制台 | P3 |
|
||
|
||
**首席架構師建議**: Layer 2 (War Room) 是核心，優先強化監控能力。Layer 0/1/3 可後續迭代。
|
||
|
||
---
|
||
|
||
## 四、監控深度定義
|
||
|
||
### 4.1 監控層級標準
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────────────────────┐
|
||
│ 監控深度金字塔 │
|
||
├─────────────────────────────────────────────────────────────────────┤
|
||
│ │
|
||
│ ┌───────┐ │
|
||
│ / L4 \ │
|
||
│ / 預測 \ │
|
||
│ / (未來) \ │
|
||
│ ├─────────────┤ │
|
||
│ / L3 \ │
|
||
│ / 根因分析 \ │
|
||
│ / (為什麼發生) \ │
|
||
│ ├───────────────────┤ │
|
||
│ / L2 \ │
|
||
│ / 上下文追蹤 \ │
|
||
│ / (影響範圍/關聯) \ │
|
||
│ ├─────────────────────────┤ │
|
||
│ / L1 \ │
|
||
│ / 即時告警 \ │
|
||
│ / (發生了什麼) \ │
|
||
│ ├───────────────────────────────┤ │
|
||
│ / L0 \ │
|
||
│ / 健康檢查 \ │
|
||
│ / (還活著嗎) \ │
|
||
│ └───────────────────────────────────────┘ │
|
||
│ │
|
||
└─────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
### 4.2 各層級實作標準
|
||
|
||
| 層級 | 定義 | 實作要求 | 當前狀態 |
|
||
|------|------|----------|----------|
|
||
| **L0: 健康檢查** | 服務是否存活 | 每個服務必須有 health endpoint | ✅ 90% |
|
||
| **L1: 即時告警** | 發生了什麼異常 | 每個異常必須觸發告警 | ⚠️ 70% |
|
||
| **L2: 上下文追蹤** | 影響範圍、關聯服務 | 每個告警必須有 Trace Context | ⚠️ 60% |
|
||
| **L3: 根因分析** | 為什麼發生 | AI 分析每個 P0/P1 告警 | ✅ 80% |
|
||
| **L4: 預測** | 可能會發生什麼 | ML 模型預測資源瓶頸 | ❌ 0% |
|
||
|
||
### 4.3 各服務監控深度目標
|
||
|
||
| 服務類型 | L0 | L1 | L2 | L3 | L4 | 備註 |
|
||
|----------|----|----|----|----|----|----|
|
||
| **P0 Critical** (API, DB, Redis) | ✅ 必須 | ✅ 必須 | ✅ 必須 | ✅ 必須 | 🟡 建議 | 核心服務全覆蓋 |
|
||
| **P1 High** (Worker, Ollama, OpenClaw) | ✅ 必須 | ✅ 必須 | ✅ 必須 | 🟡 建議 | ❌ 可選 | 關鍵 AI 服務 |
|
||
| **P2 Medium** (SignOz, Langfuse, Harbor) | ✅ 必須 | ✅ 必須 | 🟡 建議 | ❌ 可選 | ❌ 可選 | 可觀測性工具 |
|
||
| **P3 Low** (Grafana, ArgoCD UI) | ✅ 必須 | 🟡 建議 | ❌ 可選 | ❌ 可選 | ❌ 可選 | 輔助工具 |
|
||
|
||
---
|
||
|
||
## 五、完整事件生命週期 (Incident Lifecycle)
|
||
|
||
### 5.1 事件狀態機
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────────────────────┐
|
||
│ 事件生命週期狀態機 │
|
||
├─────────────────────────────────────────────────────────────────────┤
|
||
│ │
|
||
│ ┌──────────┐ │
|
||
│ │ CREATED │ ← 異常偵測 │
|
||
│ └────┬─────┘ │
|
||
│ │ AI 分析完成 │
|
||
│ ▼ │
|
||
│ ┌──────────┐ │
|
||
│ │ ANALYZED │ ← OpenClaw 完成分析 │
|
||
│ └────┬─────┘ │
|
||
│ │ │
|
||
│ ┌────┴────┐ │
|
||
│ │ │ │
|
||
│ ▼ ▼ │
|
||
│ ┌─────────────┐ ┌──────────────┐ │
|
||
│ │ AUTO_REPAIR │ │ AWAITING_ │ ← 需人工審核 │
|
||
│ │ (自動修復) │ │ APPROVAL │ │
|
||
│ └──────┬──────┘ └───────┬──────┘ │
|
||
│ │ │ │
|
||
│ │ ┌───────┴───────┐ │
|
||
│ │ │ │ │
|
||
│ │ ▼ ▼ │
|
||
│ │ ┌─────────┐ ┌──────────┐ │
|
||
│ │ │ APPROVED│ │ REJECTED │ │
|
||
│ │ └────┬────┘ └────┬─────┘ │
|
||
│ │ │ │ │
|
||
│ └────┬────┘ │ │
|
||
│ │ │ │
|
||
│ ▼ │ │
|
||
│ ┌─────────┐ │ │
|
||
│ │EXECUTING│ ← K8s Executor 執行中 │
|
||
│ └────┬────┘ │ │
|
||
│ │ │ │
|
||
│ ┌────┴────┐ │ │
|
||
│ │ │ │ │
|
||
│ ▼ ▼ │ │
|
||
│ ┌─────────┐ ┌─────────┐ │ │
|
||
│ │ SUCCESS │ │ FAILED │ │ │
|
||
│ └────┬────┘ └────┬────┘ │ │
|
||
│ │ │ │ │
|
||
│ └─────┬──────┴──────────┘ │
|
||
│ │ │
|
||
│ ▼ │
|
||
│ ┌──────────┐ │
|
||
│ │ RESOLVED │ ← 最終狀態 (保留歷史記錄) │
|
||
│ └──────────┘ │
|
||
│ │
|
||
└─────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
### 5.2 事件時間軸報告 (缺失的關鍵功能)
|
||
|
||
```markdown
|
||
═══════════════════════════════════════════════════════════════
|
||
📋 事件報告: INC-20260329-0001
|
||
═══════════════════════════════════════════════════════════════
|
||
|
||
🔴 嚴重度: CRITICAL
|
||
🎯 影響服務: awoooi-api
|
||
👥 責任團隊: Backend
|
||
📊 處理時效: 3 分 42 秒 (SLA 目標: 10 分鐘 ✅)
|
||
|
||
───────────────────────────────────────────────────────────────
|
||
📅 時間軸
|
||
───────────────────────────────────────────────────────────────
|
||
|
||
09:15:00 🔴 [偵測] Prometheus 告警觸發
|
||
│ • alertname: PodCrashLoopBackOff
|
||
│ • pod: awoooi-api-7d4b8c9f5-abc12
|
||
│ • namespace: awoooi-prod
|
||
│
|
||
09:15:12 📡 [接收] AWOOOI Webhook 收到告警
|
||
│ • fingerprint: a1b2c3d4
|
||
│ • 去重檢查: 通過 (新告警)
|
||
│
|
||
09:15:18 🧠 [分析] OpenClaw AI 開始分析
|
||
│ • 收集 K8s Events
|
||
│ • 查詢 Pod Logs (最後 100 行)
|
||
│ • 比對歷史 Playbook
|
||
│
|
||
09:15:42 ✅ [完成] OpenClaw 分析完成
|
||
│ • 根因: OOM Killed (Memory exceeded)
|
||
│ • 建議: DELETE_POD + SCALE_UP
|
||
│ • 信心度: 92%
|
||
│ • 風險等級: LOW
|
||
│ • Tokens: 1,234 / $0.0012
|
||
│
|
||
09:15:45 📱 [通知] Telegram 推送完成
|
||
│ • Chat ID: -1001234567890
|
||
│ • Message ID: 12345
|
||
│
|
||
09:16:02 ✅ [核准] 統帥點擊 [✅ 簽核]
|
||
│ • 審核者: @owenhytsai
|
||
│ • 決策時間: 17 秒
|
||
│
|
||
09:16:05 🔧 [執行] K8s Executor 開始
|
||
│ • Command: kubectl delete pod awoooi-api-7d4b8c9f5-abc12
|
||
│
|
||
09:16:08 ✅ [成功] Pod 刪除成功
|
||
│ • 新 Pod 啟動中...
|
||
│
|
||
09:16:35 🔧 [執行] 擴展副本數
|
||
│ • Command: kubectl scale deployment/awoooi-api --replicas=3
|
||
│
|
||
09:16:38 ✅ [成功] 擴展完成
|
||
│
|
||
09:17:20 ✅ [驗證] 健康檢查通過
|
||
│ • /api/v1/health: 200 OK
|
||
│ • 所有 Pod: Running
|
||
│
|
||
09:18:42 📊 [結案] 事件標記為 RESOLVED
|
||
│ • 總處理時間: 3 分 42 秒
|
||
│ • 自動化程度: 85%
|
||
│ • 人工介入: 核准 (17 秒)
|
||
|
||
───────────────────────────────────────────────────────────────
|
||
📈 指標
|
||
───────────────────────────────────────────────────────────────
|
||
• MTTR (修復時間): 3 分 42 秒
|
||
• MTTA (確認時間): 45 秒
|
||
• 影響時間: 約 4 分鐘
|
||
• 影響用戶: 估計 50-100 人
|
||
|
||
───────────────────────────────────────────────────────────────
|
||
🔗 相關連結
|
||
───────────────────────────────────────────────────────────────
|
||
• SignOz Trace: http://192.168.0.188:3301/trace/abc123
|
||
• Sentry Issue: (無相關)
|
||
• Langfuse: http://192.168.0.110:3100/traces/xyz789
|
||
• Approval: http://awoooi.wooo.tw/authorizations/INC-20260329-0001
|
||
|
||
───────────────────────────────────────────────────────────────
|
||
💡 改進建議 (AI 生成)
|
||
───────────────────────────────────────────────────────────────
|
||
1. 建議增加 memory limit 從 512Mi 到 768Mi
|
||
2. 建議設置 HPA (Horizontal Pod Autoscaler)
|
||
3. 考慮 Playbook 自動化 (信心度 > 95% 時)
|
||
|
||
═══════════════════════════════════════════════════════════════
|
||
```
|
||
|
||
---
|
||
|
||
## 六、監控項目完整清單
|
||
|
||
### 6.1 服務健康 (L0)
|
||
|
||
| 項目 | 監控方式 | 當前狀態 | 目標狀態 |
|
||
|------|----------|----------|----------|
|
||
| awoooi-api | HTTP /api/v1/health | ✅ | ✅ |
|
||
| awoooi-web | HTTP / | ✅ | ✅ |
|
||
| awoooi-worker | Exec mtime | ✅ | ✅ |
|
||
| ollama | HTTP /api/tags | ✅ | ✅ |
|
||
| openclaw | HTTP /health | ✅ | ✅ |
|
||
| postgres | pg_isready | ⚠️ Docker 內部 | ✅ Prometheus Exporter |
|
||
| redis | redis-cli ping | ⚠️ Docker 內部 | ✅ Redis Exporter |
|
||
| harbor | HTTP /api/v2.0/health | ⚠️ | ✅ |
|
||
| sentry | HTTP /_health/ | ⚠️ | ✅ |
|
||
| langfuse | HTTP /api/public/health | ⚠️ | ✅ |
|
||
| github-runner | systemctl status | ⚠️ | ✅ |
|
||
| signoz | HTTP / (UI) | ✅ | ✅ |
|
||
| clickhouse | HTTP /ping | ⚠️ | ✅ |
|
||
|
||
### 6.2 即時告警 (L1)
|
||
|
||
| 告警類型 | 當前狀態 | 目標狀態 | 優先級 |
|
||
|----------|----------|----------|--------|
|
||
| **應用錯誤** |
|
||
| Sentry Exception → Telegram | ⚠️ 有 Webhook，但無 Telegram | ✅ 直接推送 | P0 |
|
||
| HTTP 5xx 激增 | ✅ Prometheus | ✅ | - |
|
||
| API 延遲 P95 > 2s | ⚠️ SignOz 有數據 | ✅ 告警規則 | P1 |
|
||
| **基礎設施** |
|
||
| Pod CrashLoop | ✅ Prometheus | ✅ | - |
|
||
| Node NotReady | ✅ Prometheus | ✅ | - |
|
||
| Disk > 85% | ✅ Prometheus | ✅ | - |
|
||
| **資料庫** |
|
||
| PostgreSQL Down | ⚠️ 無 | ✅ pg_exporter | P0 |
|
||
| PostgreSQL 連線池 > 80% | ⚠️ 無 | ✅ pg_exporter | P1 |
|
||
| Redis Memory > 80% | ⚠️ 無 | ✅ redis_exporter | P1 |
|
||
| **AI/LLM** |
|
||
| Ollama Timeout > 60s | ⚠️ 無 | ✅ 自訂 Metrics | P1 |
|
||
| Gemini Rate Limit | ✅ Rate Limiter | ✅ | - |
|
||
| Token 成本超標 | ⚠️ Langfuse 有數據 | ✅ 告警規則 | P2 |
|
||
| **CI/CD** |
|
||
| Runner Offline | ⚠️ healthcheck | ✅ Prometheus | P0 |
|
||
| Workflow Failed | ⚠️ 無 | ✅ GitHub Webhook | P1 |
|
||
|
||
### 6.3 上下文追蹤 (L2)
|
||
|
||
| 追蹤項目 | 當前狀態 | 目標狀態 | 說明 |
|
||
|----------|----------|----------|------|
|
||
| Request Trace | ✅ SignOz | ✅ | 完整 Span 追蹤 |
|
||
| Error → Trace 連結 | ✅ Sentry | ✅ | Deep Linking |
|
||
| 告警 → 相關服務 | ⚠️ 部分 | ✅ blast_radius | 需強化 |
|
||
| 告警 → 歷史比對 | ❌ | ✅ | Playbook 匹配 |
|
||
| DB Query Trace | ⚠️ 部分 | ✅ | SQLAlchemy 埋點 |
|
||
| Redis Command Trace | ❌ | ✅ | redis-py 埋點 |
|
||
|
||
### 6.4 根因分析 (L3)
|
||
|
||
| 分析項目 | 當前狀態 | 目標狀態 | 說明 |
|
||
|----------|----------|----------|------|
|
||
| Alertmanager → OpenClaw | ✅ | ✅ | 已實作 |
|
||
| Sentry → OpenClaw | ✅ | ✅ | 已實作 |
|
||
| SignOz 異常 → OpenClaw | ❌ | ✅ | 需實作 ClickHouse 查詢 |
|
||
| 責任團隊判定 | ✅ | ✅ | AI 仲裁 |
|
||
| 修復建議生成 | ✅ | ✅ | kubectl 指令 |
|
||
|
||
### 6.5 預測 (L4) - 未來
|
||
|
||
| 預測項目 | 當前狀態 | 目標狀態 | 說明 |
|
||
|----------|----------|----------|------|
|
||
| 資源瓶頸預測 | ❌ | 🟡 Phase 3 | ML 模型 |
|
||
| 告警趨勢預測 | ❌ | 🟡 Phase 3 | 時序分析 |
|
||
| 成本預測 | ❌ | 🟡 Phase 3 | Token 使用趨勢 |
|
||
|
||
---
|
||
|
||
## 七、與全局戰情室的關係
|
||
|
||
### 7.1 決策：整合 vs 分離
|
||
|
||
| 方案 | 優點 | 缺點 | 建議 |
|
||
|------|------|------|------|
|
||
| **整合** (在現有戰情室擴展) | 單一入口、用戶熟悉 | 可能變得臃腫 | ✅ **推薦** |
|
||
| **分離** (獨立監控中心) | 清晰分工 | 維護成本高、用戶需切換 | ❌ |
|
||
|
||
**首席架構師建議**: **整合方案**
|
||
|
||
理由：
|
||
1. 現有戰情室已有完整基礎 (Approval、Incident、Timeline)
|
||
2. 監控與處理應該在同一畫面 (減少上下文切換)
|
||
3. 透過 Tab/Section 區分不同資訊層級
|
||
|
||
### 7.2 整合方案設計
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────────────────────┐
|
||
│ 全局戰情室 v2.0 (整合監控) │
|
||
├─────────────────────────────────────────────────────────────────────┤
|
||
│ │
|
||
│ ┌─────────────────────────────────────────────────────────────┐ │
|
||
│ │ Header │ │
|
||
│ │ ┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐ │ │
|
||
│ │ │ 概覽 │ │ 告警 │ │ 服務 │ │ 追蹤 │ │ 報告 │ │ │
|
||
│ │ └───────┘ └───────┘ └───────┘ └───────┘ └───────┘ │ │
|
||
│ └─────────────────────────────────────────────────────────────┘ │
|
||
│ │
|
||
│ ┌────────────────────────┐ ┌──────────────────────────────────┐ │
|
||
│ │ 左側: 服務健康地圖 │ │ 右側: 事件/告警/追蹤 │ │
|
||
│ │ │ │ │ │
|
||
│ │ 🟢 awoooi-api (2/2) │ │ Tab: [即時告警] [待處理] [歷史] │ │
|
||
│ │ 🟢 awoooi-web (2/2) │ │ │ │
|
||
│ │ 🟢 awoooi-worker (1/1)│ │ ┌────────────────────────────┐ │ │
|
||
│ │ 🟢 ollama (健康) │ │ │ 🔴 CRITICAL | awoooi-api │ │ │
|
||
│ │ 🟢 postgres (健康) │ │ │ 09:15:00 | PodCrashLoop │ │ │
|
||
│ │ 🟢 redis (健康) │ │ │ [查看詳情] [AI 分析中...] │ │ │
|
||
│ │ │ │ └────────────────────────────┘ │ │
|
||
│ │ ───────────────── │ │ │ │
|
||
│ │ 系統指標 │ │ ┌────────────────────────────┐ │ │
|
||
│ │ CPU: 45% ███████░░░ │ │ │ 🟡 WARNING | postgres │ │ │
|
||
│ │ MEM: 62% █████████░ │ │ │ 09:10:00 | ConnectionPool │ │ │
|
||
│ │ Disk: 55% ████████░░ │ │ │ [查看詳情] [已自動處理] │ │ │
|
||
│ │ │ │ └────────────────────────────┘ │ │
|
||
│ └────────────────────────┘ └──────────────────────────────────┘ │
|
||
│ │
|
||
│ ┌─────────────────────────────────────────────────────────────┐ │
|
||
│ │ 底部: 事件時間軸 (Timeline) │ │
|
||
│ │ ────────●─────────●──────────●────────●─────────●─────────→ │ │
|
||
│ │ 09:15 09:16 09:17 09:18 09:19 │ │
|
||
│ │ 偵測 分析 核准 執行 修復 │ │
|
||
│ └─────────────────────────────────────────────────────────────┘ │
|
||
│ │
|
||
└─────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 八、實作路線圖
|
||
|
||
### Phase 0: 立即修復 (今天)
|
||
|
||
| 項目 | 狀態 | 說明 |
|
||
|------|------|------|
|
||
| Telegram 按鈕修復 | ✅ 已完成 | b0b91a5 |
|
||
| Sentry OpenClaw URL | ✅ 已完成 | d6dc80b |
|
||
| 驗證按鈕功能 | ⬜ 待測試 | 觸發測試告警 |
|
||
|
||
### Phase 1: 消滅靜默失敗 (本週)
|
||
|
||
| 項目 | 工時 | 說明 |
|
||
|------|------|------|
|
||
| 所有 try/except 加 Sentry | 2h | 代碼審查 + 修改 |
|
||
| Sentry Issue → Telegram 即時推送 | 1h | 已有 Webhook，補 Telegram |
|
||
| 事件時間軸報告 | 4h | 新功能開發 |
|
||
| 資料庫監控 (pg_exporter, redis_exporter) | 2h | Docker 部署 |
|
||
|
||
### Phase 2: 完善告警 (下週)
|
||
|
||
| 項目 | 工時 | 說明 |
|
||
|------|------|------|
|
||
| SignOz 告警規則 | 2h | Error Rate, Latency |
|
||
| 自動修復動作擴展 | 4h | SCALE_UP, ROLLBACK |
|
||
| Playbook 萃取 | 4h | 成功修復 → 自動記錄 |
|
||
| CI/CD 監控 | 2h | GitHub Webhook |
|
||
|
||
### Phase 3: 角色分層 (兩週後)
|
||
|
||
| 項目 | 工時 | 說明 |
|
||
|------|------|------|
|
||
| Executive Dashboard (L0) | 8h | C-Level 視圖 |
|
||
| Ops Center (L1) | 6h | 團隊視圖 |
|
||
| Grafana 儀表板 | 4h | 視覺化 |
|
||
|
||
---
|
||
|
||
## 九、異常頻率統計與根本修復 (2026-03-29 統帥新增)
|
||
|
||
> **關鍵觀點**: 重啟只是治標，不是治本！太常發生的異常必須徹底解決
|
||
|
||
### 9.1 異常頻率追蹤架構
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────────────────────┐
|
||
│ 異常頻率追蹤閉環 │
|
||
├─────────────────────────────────────────────────────────────────────┤
|
||
│ │
|
||
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
|
||
│ │ 異常發生 │────▶│ 計數統計 │────▶│ 模式識別 │────▶│ 根因修復 │ │
|
||
│ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │
|
||
│ │ │ │ │ │
|
||
│ │ ▼ ▼ ▼ │
|
||
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
|
||
│ │ │ Redis │ │ OpenClaw│ │ Playbook│ │
|
||
│ │ │ 計數器 │ │ 模式分析 │ │ 自動生成│ │
|
||
│ │ └─────────┘ └─────────┘ └─────────┘ │
|
||
│ │ │ │ │ │
|
||
│ │ └────────────────┴──────────────┘ │
|
||
│ │ │ │
|
||
│ │ ▼ │
|
||
│ │ ┌──────────────────┐ │
|
||
│ │ │ 閾值觸發告警 │ │
|
||
│ │ │ (同一問題 > 3次) │ │
|
||
│ │ └──────────────────┘ │
|
||
│ │ │ │
|
||
│ │ ▼ │
|
||
│ │ ┌──────────────────┐ │
|
||
│ └───────────────────▶│ Telegram 特別通知 │ │
|
||
│ 第 1 次 = 普通告警 │ 「此問題本月第 N 次」│ │
|
||
│ 第 3 次 = 重複告警 └──────────────────┘ │
|
||
│ 第 5 次 = 升級告警 │
|
||
│ │
|
||
└─────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
### 9.2 計數器設計
|
||
|
||
```python
|
||
# apps/api/src/services/anomaly_counter.py
|
||
"""
|
||
異常頻率統計服務
|
||
"""
|
||
|
||
from datetime import datetime, timedelta
|
||
from typing import NamedTuple
|
||
import redis
|
||
import structlog
|
||
|
||
logger = structlog.get_logger(__name__)
|
||
|
||
class AnomalyFrequency(NamedTuple):
|
||
"""異常頻率資料"""
|
||
anomaly_key: str # 異常唯一識別 (hash of error signature)
|
||
count_1h: int # 1 小時內發生次數
|
||
count_24h: int # 24 小時內發生次數
|
||
count_7d: int # 7 天內發生次數
|
||
count_30d: int # 30 天內發生次數
|
||
first_seen: datetime # 首次發生時間
|
||
last_seen: datetime # 最近發生時間
|
||
auto_repair_count: int # 自動修復嘗試次數
|
||
permanent_fix_applied: bool # 是否已套用永久修復
|
||
|
||
|
||
class AnomalyCounter:
|
||
"""
|
||
異常計數器 - 追蹤每種異常的發生頻率
|
||
|
||
使用 Redis Sorted Set 實作滑動窗口計數
|
||
"""
|
||
|
||
THRESHOLDS = {
|
||
'REPEAT_ALERT': 3, # 3 次重複 → 升級告警
|
||
'ESCALATE': 5, # 5 次重複 → 人工介入
|
||
'PERMANENT_FIX': 10, # 10 次重複 → 必須永久修復
|
||
}
|
||
|
||
def __init__(self, redis_client: redis.Redis):
|
||
self.redis = redis_client
|
||
|
||
def record_anomaly(self, anomaly_signature: dict) -> AnomalyFrequency:
|
||
"""
|
||
記錄一次異常發生
|
||
|
||
Args:
|
||
anomaly_signature: 異常簽名 (包含 error_type, service, culprit 等)
|
||
|
||
Returns:
|
||
AnomalyFrequency: 當前頻率統計
|
||
"""
|
||
# 生成唯一 key (基於異常簽名的 hash)
|
||
anomaly_key = self._hash_signature(anomaly_signature)
|
||
now = datetime.now()
|
||
timestamp = now.timestamp()
|
||
|
||
# 添加到 Sorted Set (score = timestamp)
|
||
self.redis.zadd(f"anomaly:timeline:{anomaly_key}", {str(timestamp): timestamp})
|
||
|
||
# 清理過期數據 (30 天前)
|
||
cutoff_30d = (now - timedelta(days=30)).timestamp()
|
||
self.redis.zremrangebyscore(f"anomaly:timeline:{anomaly_key}", '-inf', cutoff_30d)
|
||
|
||
# 計算各時間窗口的計數
|
||
count_1h = self.redis.zcount(
|
||
f"anomaly:timeline:{anomaly_key}",
|
||
(now - timedelta(hours=1)).timestamp(),
|
||
'+inf'
|
||
)
|
||
count_24h = self.redis.zcount(
|
||
f"anomaly:timeline:{anomaly_key}",
|
||
(now - timedelta(hours=24)).timestamp(),
|
||
'+inf'
|
||
)
|
||
count_7d = self.redis.zcount(
|
||
f"anomaly:timeline:{anomaly_key}",
|
||
(now - timedelta(days=7)).timestamp(),
|
||
'+inf'
|
||
)
|
||
count_30d = self.redis.zcount(
|
||
f"anomaly:timeline:{anomaly_key}",
|
||
cutoff_30d,
|
||
'+inf'
|
||
)
|
||
|
||
# 取得首次/最近時間
|
||
first_seen_ts = self.redis.zrange(f"anomaly:timeline:{anomaly_key}", 0, 0, withscores=True)
|
||
last_seen_ts = self.redis.zrange(f"anomaly:timeline:{anomaly_key}", -1, -1, withscores=True)
|
||
|
||
# 自動修復次數
|
||
auto_repair_count = int(self.redis.get(f"anomaly:repair_count:{anomaly_key}") or 0)
|
||
permanent_fix = self.redis.get(f"anomaly:permanent_fix:{anomaly_key}") == b'1'
|
||
|
||
freq = AnomalyFrequency(
|
||
anomaly_key=anomaly_key,
|
||
count_1h=count_1h,
|
||
count_24h=count_24h,
|
||
count_7d=count_7d,
|
||
count_30d=count_30d,
|
||
first_seen=datetime.fromtimestamp(first_seen_ts[0][1]) if first_seen_ts else now,
|
||
last_seen=datetime.fromtimestamp(last_seen_ts[0][1]) if last_seen_ts else now,
|
||
auto_repair_count=auto_repair_count,
|
||
permanent_fix_applied=permanent_fix,
|
||
)
|
||
|
||
# 記錄日誌
|
||
logger.info(
|
||
"anomaly_recorded",
|
||
anomaly_key=anomaly_key,
|
||
count_24h=count_24h,
|
||
count_30d=count_30d,
|
||
)
|
||
|
||
return freq
|
||
|
||
def should_escalate(self, freq: AnomalyFrequency) -> str | None:
|
||
"""
|
||
判斷是否需要升級處理
|
||
|
||
Returns:
|
||
None: 不需要升級
|
||
'REPEAT': 重複告警 (3-4 次)
|
||
'ESCALATE': 人工介入 (5-9 次)
|
||
'PERMANENT_FIX': 必須永久修復 (10+ 次)
|
||
"""
|
||
if freq.count_24h >= self.THRESHOLDS['PERMANENT_FIX']:
|
||
return 'PERMANENT_FIX'
|
||
elif freq.count_24h >= self.THRESHOLDS['ESCALATE']:
|
||
return 'ESCALATE'
|
||
elif freq.count_24h >= self.THRESHOLDS['REPEAT_ALERT']:
|
||
return 'REPEAT'
|
||
return None
|
||
```
|
||
|
||
### 9.3 根本修復 vs 重啟
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────────────────────┐
|
||
│ 修復策略分級 │
|
||
├─────────────────────────────────────────────────────────────────────┤
|
||
│ │
|
||
│ ┌─────────────────────────────────────────────────────────────┐ │
|
||
│ │ 🔴 Tier 1: 臨時修復 (重啟類) │ │
|
||
│ │ 適用: 首次發生、原因不明 │ │
|
||
│ │ 動作: restart_pod, restart_container │ │
|
||
│ │ 限制: 同一問題最多用 2 次 │ │
|
||
│ └─────────────────────────────────────────────────────────────┘ │
|
||
│ ↓ 重複發生 │
|
||
│ ┌─────────────────────────────────────────────────────────────┐ │
|
||
│ │ 🟡 Tier 2: 緩解修復 (資源調整類) │ │
|
||
│ │ 適用: 資源不足、負載問題 │ │
|
||
│ │ 動作: scale_up, increase_memory, adjust_limits │ │
|
||
│ │ 條件: 已重啟 2 次仍未解決 │ │
|
||
│ └─────────────────────────────────────────────────────────────┘ │
|
||
│ ↓ 繼續發生 │
|
||
│ ┌─────────────────────────────────────────────────────────────┐ │
|
||
│ │ 🟢 Tier 3: 根本修復 (代碼/配置修復) │ │
|
||
│ │ 適用: 已識別根因 │ │
|
||
│ │ 動作: apply_hotfix, update_config, patch_deployment │ │
|
||
│ │ 要求: OpenClaw AI 分析 + 人工確認 │ │
|
||
│ └─────────────────────────────────────────────────────────────┘ │
|
||
│ ↓ 仍未解決 │
|
||
│ ┌─────────────────────────────────────────────────────────────┐ │
|
||
│ │ 🔵 Tier 4: 架構修復 (需要開發) │ │
|
||
│ │ 適用: 設計缺陷、技術債 │ │
|
||
│ │ 動作: create_issue, notify_team, schedule_fix │ │
|
||
│ │ 結果: 建立追蹤 Issue，排入 Sprint │ │
|
||
│ └─────────────────────────────────────────────────────────────┘ │
|
||
│ │
|
||
└─────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
### 9.4 AI 學習與 Playbook 自動更新
|
||
|
||
```python
|
||
# apps/api/src/services/learning_service.py
|
||
"""
|
||
異常學習服務 - 從解決方案中學習
|
||
"""
|
||
|
||
class LearningService:
|
||
"""
|
||
學習每次修復的效果，自動更新 Playbook
|
||
"""
|
||
|
||
async def record_repair_result(
|
||
self,
|
||
anomaly_key: str,
|
||
repair_action: str,
|
||
success: bool,
|
||
root_cause: str | None,
|
||
fix_description: str | None,
|
||
):
|
||
"""
|
||
記錄修復結果，用於學習
|
||
"""
|
||
# 更新成功/失敗統計
|
||
if success:
|
||
await self._increment_success(anomaly_key, repair_action)
|
||
else:
|
||
await self._increment_failure(anomaly_key, repair_action)
|
||
|
||
# 如果找到根因且修復成功，更新 Playbook
|
||
if success and root_cause:
|
||
await self._update_playbook(
|
||
anomaly_signature=anomaly_key,
|
||
root_cause=root_cause,
|
||
fix_action=repair_action,
|
||
fix_description=fix_description,
|
||
)
|
||
|
||
async def get_recommended_fix(self, anomaly_key: str) -> dict:
|
||
"""
|
||
根據歷史學習，推薦最佳修復方案
|
||
"""
|
||
# 取得該異常的歷史修復統計
|
||
history = await self._get_repair_history(anomaly_key)
|
||
|
||
if not history:
|
||
return {'action': 'restart_pod', 'confidence': 0.3, 'tier': 1}
|
||
|
||
# 計算各動作的成功率
|
||
success_rates = {}
|
||
for action, stats in history.items():
|
||
if stats['total'] > 0:
|
||
success_rates[action] = stats['success'] / stats['total']
|
||
|
||
# 返回成功率最高的動作
|
||
if success_rates:
|
||
best_action = max(success_rates, key=success_rates.get)
|
||
return {
|
||
'action': best_action,
|
||
'confidence': success_rates[best_action],
|
||
'tier': self._get_action_tier(best_action),
|
||
'based_on': f"{history[best_action]['total']} 次歷史數據",
|
||
}
|
||
|
||
return {'action': 'restart_pod', 'confidence': 0.3, 'tier': 1}
|
||
```
|
||
|
||
### 9.5 Telegram 頻率告警格式
|
||
|
||
```
|
||
═══════════════════════════════════════
|
||
⚠️ 重複異常告警 (第 5 次)
|
||
═══════════════════════════════════════
|
||
📍 服務: awoooi-api
|
||
❌ 異常: OOM Killed
|
||
🔄 本月發生: 5 次
|
||
⏱️ 最近發生: 剛剛
|
||
|
||
📊 頻率統計:
|
||
• 1小時: 2 次
|
||
• 24小時: 5 次 ← 觸發升級
|
||
• 7天: 8 次
|
||
• 30天: 15 次
|
||
|
||
🔧 已嘗試修復:
|
||
• restart_pod: 3 次 (成功率 30%)
|
||
• scale_up: 1 次 (成功率 0%)
|
||
|
||
🧠 AI 分析:
|
||
「Memory Limit 設定過低，建議調整為 512Mi」
|
||
|
||
───────────────────────────────────────
|
||
🔴 建議: 永久修復 (Tier 3)
|
||
→ 調整 memory limit
|
||
|
||
[ ✅ 套用永久修復 ] [ 🔄 先重啟 ] [ ⏸️ 稍後 ]
|
||
═══════════════════════════════════════
|
||
```
|
||
|
||
### 9.6 實作清單
|
||
|
||
| 項目 | 優先級 | 工時 | 狀態 |
|
||
|------|--------|------|------|
|
||
| AnomalyCounter 服務 | P0 | 4h | ⬜ |
|
||
| Redis 計數器整合 | P0 | 2h | ⬜ |
|
||
| 頻率閾值告警 | P0 | 2h | ⬜ |
|
||
| Telegram 頻率告警格式 | P0 | 2h | ⬜ |
|
||
| LearningService | P1 | 6h | ⬜ |
|
||
| Playbook 自動更新 | P1 | 4h | ⬜ |
|
||
| 修復成功率統計 | P1 | 2h | ⬜ |
|
||
| 根因修復動作庫 | P2 | 8h | ⬜ |
|
||
|
||
---
|
||
|
||
## 十、待統帥裁示
|
||
|
||
### 9.1 架構決策
|
||
|
||
| 問題 | 選項 | 首席架構師建議 |
|
||
|------|------|----------------|
|
||
| 監控中心是否獨立? | A. 整合到戰情室 / B. 獨立頁面 | **A. 整合** |
|
||
| 角色分層優先級? | A. 先做 C-Level / B. 先強化 L2 | **B. 先強化 L2** |
|
||
| 資料庫監控方式? | A. Exporter / B. 應用層探針 | **A. Exporter** |
|
||
|
||
### 9.2 優先級確認
|
||
|
||
| 階段 | 內容 | 預估工時 | 確認? |
|
||
|------|------|----------|-------|
|
||
| Phase 0 | 驗證修復 | 10min | ⬜ |
|
||
| Phase 1 | 消滅靜默失敗 | 9h | ⬜ |
|
||
| Phase 2 | 完善告警 | 12h | ⬜ |
|
||
| Phase 3 | 角色分層 | 18h | ⬜ |
|
||
|
||
### 9.3 資源分配
|
||
|
||
| 問題 | 選項 |
|
||
|------|------|
|
||
| 是否需要額外主機部署 Exporter? | 188 主機已有 Docker Compose，可直接加入 |
|
||
| Grafana 是否部署到 K3s? | 建議部署到 monitoring namespace |
|
||
|
||
---
|
||
|
||
**文件狀態**: DRAFT - 待統帥審核
|
||
**下一步**: 統帥確認後開始 Phase 1 實作
|