docs(logbook): 2026-04-19 Phase 7 scanner 完成 + CI 修復歷程
記錄本輪 6 個 commits 的全景與 CI cd.yaml B5 3 輪除錯歷程, 供未來 session 接手時理解當前進度。 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
OG T
156
docs/LOGBOOK.md
156
docs/LOGBOOK.md
@@ -6,6 +6,162 @@
|
||||
|
||||
---
|
||||
|
||||
## 📍 2026-04-19 下午 16:30 — Phase 7 完整實作：4 個新 scanner service + CI 修復 🎖️
|
||||
|
||||
### 統帥鐵律激活
|
||||
「批准！！全部都要同步做！！」 — 平行推進 CI 修復 + 4 個新 service + E2E 驗證
|
||||
|
||||
### 完成清單（6 個 commits）
|
||||
|
||||
| Commit | 內容 | 狀態 |
|
||||
|---|---|---|
|
||||
| `e7ba8cb` | approval_execution aol writer + verifier await + declarative done_callback | ✅ 手動 build 部署 |
|
||||
| `c0f3509` | drift diff HTTP 400 修復（item-by-item 累計防 HTML 截斷） | ✅ |
|
||||
| `5b9b36f` | cd.yaml shared network + rule_catalog_sync | ✅ **CI 首次通過** |
|
||||
| `4259a10` | capacity_scanner + compliance_scanner | ⏳ CI 跑中 |
|
||||
| `0226344` | asset_scanner kubectl 改 subprocess | ⏳ CI 跑中 |
|
||||
|
||||
### CI cd.yaml B5 3 輪除錯歷程
|
||||
1. **e7ba8cb fail**：act runner 跟 pg-test-b5 用不同 docker network，172.17.0.2 IP 不通
|
||||
2. **b636d3b fail**：grep `GITEA-ACTIONS-TASK` 無 match → `bash -e -o pipefail` 中斷整 step（無任何 echo）
|
||||
3. **c0f3509 fail**：fallback bridge 網路但 default bridge 不支援 container name DNS
|
||||
4. **5b9b36f 成功**：主動建 shared network `b5-test-net`，ci-runner + pg-test-b5 都加入
|
||||
|
||||
### 實際驗證（5b9b36f 部署後 7min）
|
||||
| 表 | 修復前 | 修復後 |
|
||||
|---|---|---|
|
||||
| **alert_rule_catalog** | 0 | **68**（Prometheus active rules 全 sync）✅ |
|
||||
| asset_discovery_run | 1 | **3**（asset_scanner 跑了 3 次）✅ |
|
||||
| asset_inventory | 0 | 0（K8sProvider bug，0226344 修復中） |
|
||||
| automation_operation_log | 22 | 26（+2 asset_discovered, +1 rule_created, +1 notification_formatted）|
|
||||
|
||||
### 程式邏輯串聯（本輪打通）
|
||||
```
|
||||
Pod 啟動 → main.py lifespan
|
||||
├─ asset_scanner_loop (3600s) → kubectl get pods --all-namespaces
|
||||
│ └─→ asset_inventory UPSERT + 7 維 coverage_snapshot
|
||||
├─ rule_catalog_sync_loop (3600s) → Prometheus /api/v1/rules
|
||||
│ └─→ alert_rule_catalog UPSERT (solves E3 Hermes 的 baseline)
|
||||
├─ capacity_scanner_loop (daily 02:00) → Prometheus node_exporter
|
||||
│ └─→ host_capacity_snapshot + capacity_violation_event
|
||||
└─ compliance_scanner_loop (daily 03:00) → asset_inventory active
|
||||
└─→ asset_compliance_snapshot × 7 維 (secret_rotated 真實檢查)
|
||||
```
|
||||
|
||||
### 修復的 CI 基礎設施
|
||||
- `cd.yaml` line 158-182：主動建 shared network、ci-runner + pg-test-b5 用 container name 連線
|
||||
- 解鎖以後**所有** commit 都能自動 CI/CD 部署，不用手動 build
|
||||
|
||||
### 下一階段（待 CI 完成）
|
||||
- B3/B4 部署後 host_capacity_snapshot + compliance_snapshot 開始累積
|
||||
- 等真實 approval 進來驗證 aol(playbook_executed) + evidence.verification_result
|
||||
- Phase 7 所有 11 張 ADR-090 表全部有 writer，0 writer 盲區治理完成
|
||||
|
||||
---
|
||||
|
||||
## 📍 2026-04-19 中午 12:30 — 北極星全景打通：verifier 改 await + aol 動作回灌 🚀
|
||||
|
||||
### 統帥鐵律激活
|
||||
「全景、全流程、全節點、全程式碼關聯串接邏輯！朝 AI 自動化方向目標前進！」
|
||||
|
||||
### 起因
|
||||
統帥指出原本的「11 張表 migration 未 apply」需求,先全景審計再動手。
|
||||
盤點結果:14 張表全建好,但 11/14 完全沒人寫;真正瓶頸在「程式邏輯沒串通」,不是 schema 缺失。
|
||||
|
||||
### 全景審計鐵證（C 方案 = A 學習鏈 + B 動作回灌 並行）
|
||||
|
||||
| 觀察 | 鐵證 |
|
||||
|---|---|
|
||||
| 14 張 ADR-090 表全部 EXISTS（owner=awoooi） | pg_class 確認 |
|
||||
| automation_operation_log: 22 筆全部 drift_narrator 寫的 | grep + DB 統計 |
|
||||
| 33 件/7d approval APPROVED+EXECUTION_FAILED → aol 0 筆回灌 | 跨表 JOIN 比對 |
|
||||
| incident_evidence: 1212 筆,evidence_summary 100% 有,verification_result 100% NULL | DB 統計 |
|
||||
| AIOPS_P1-P6 flag 全部 true（4 天前 76558a3 全開）| Pod env 實測 |
|
||||
| verifier flag 開了還是 0 寫入 → fire-and-forget task 在 Pod recycle 時被殺 | 程式碼 trace |
|
||||
|
||||
### 真正斷點（程式邏輯角度）
|
||||
1. `_run_post_execution_verify` 用 `asyncio.create_task` fire-and-forget,task 死 → verification_result 永遠 NULL
|
||||
2. `approval_execution.execute_approved_action` 全程沒寫 automation_operation_log
|
||||
3. `declarative_remediation._log_remediation_event` 也是 fire-and-forget,失敗無 log → 0 筆寫入
|
||||
|
||||
### 修復（commit e7ba8cb）
|
||||
|
||||
**apps/api/src/services/approval_execution.py（+182 行）**：
|
||||
- 新增 `_log_aol_started`：主流程開始 INSERT aol(playbook_executed, pending) 拿 op_id
|
||||
- 新增 `_log_aol_completed`：4 個 return 點 UPDATE aol 為 success/failed + duration + stderr_feed_back
|
||||
- `_run_post_execution_verify` 兩處（成功+失敗 path）從 `create_task` 改 `await + 60s timeout`
|
||||
- 失敗時 `stderr_feed_back = result.error` → 解開 E6 stderr 回灌閉環
|
||||
|
||||
**apps/api/src/services/declarative_remediation.py（+24 行）**：
|
||||
- `_log_remediation_event` task 加 `name` + `add_done_callback`,task 失敗時有 log
|
||||
|
||||
### 預期解鎖鏈（驗證待 CD 完成 + 下一次 approval）
|
||||
- automation_operation_log: 33 件/7d 立即可見（playbook_executed）
|
||||
- incident_evidence.verification_result: 開始累積
|
||||
- learning_service.record_verification_result → Playbook EWMA trust_score 動態變化
|
||||
- finetune_exporter 7d cron: 終於有 `verification_result='success'` 可匯出 → finetune_exports 寫入
|
||||
- stderr_feed_back: 接通 → 失敗訊號回灌 retry/Playbook 負向強化
|
||||
|
||||
### 還沒做（下一輪）
|
||||
- 8 張 asset/capacity 表 0 writer：需要新建 scanner / capacity / rule_catalog services
|
||||
- E3 Hermes 自動建規則：依賴 alert_rule_catalog 有資料
|
||||
- Phase 4 NemoTron 容量巡檢：依賴 host_capacity_snapshot 有資料
|
||||
|
||||
### Commits
|
||||
- `e7ba8cb` fix(aiops): 打通 AI 自主學習鏈 — verifier 改 await + aol 動作回灌
|
||||
|
||||
---
|
||||
|
||||
## 📍 2026-04-19 凌晨 02:05 — Phase 7 盲區治理 Round 1：結構性治理全景打擊 🎯
|
||||
|
||||
### 統帥鐵律激活
|
||||
"不要只降低！要長期解決！" → 放棄「重啟 cadvisor」戰術補丁，轉走**結構性治理**
|
||||
|
||||
### 起因
|
||||
- 剛才開頭我給 A-E 戰術選單 → 統帥兩輪校準（看過全景？符合北極星？不要只降低！）
|
||||
- 全景調查揭露：188 cadvisor **Up 13h 還 321%** = 重啟完全無效鐵證
|
||||
- 110 load 17 真兇**不是 cadvisor**（cadvisor 0%）而是 Sentry 155% + Gitea 109% + node-exporter 141%
|
||||
|
||||
### Commits（2 repos）
|
||||
- `eab3f52` awoooi: monitoring compose + alerts-unified `infra_self_monitoring` 群組（9 規則）
|
||||
- `507384a` wooo-aiops: 188 cadvisor compose 結構性治理（flags + L2）
|
||||
|
||||
### 全景打擊戰果
|
||||
|
||||
| 服務 | Before | After | 配額 |
|
||||
|---|---|---|---|
|
||||
| 188 cadvisor | 321% 爆 13 天 | **0.00%** 🎉 | 1g/1.5c |
|
||||
| 110 cadvisor | 0% | 4.38% | 512m/1.0c（防爆網）|
|
||||
| 110 node-exporter | 141% 爆 | **0.00%** 🎉 | 256m/1.0c |
|
||||
| Sentry ClickHouse | 155% | 71% | 8g/4c |
|
||||
| Gitea | 109% 爆 | **5.87%** 🎉 | 3g/3c |
|
||||
|
||||
### Load 變化
|
||||
- 188: 10.33 → **5.09** ✅
|
||||
- 110: 17 → (重啟峰值 51 回落中) 待驗證
|
||||
|
||||
### 告警規則（動態，非寫死）
|
||||
- Memory usage / spec_memory_limit > 0.8 → Pressure
|
||||
- CPU throttle rate > 0.5s/s → Throttled
|
||||
- 配額改，閾值自動跟著變（比寫死 80% 智能）
|
||||
|
||||
### 🔴 關鍵教訓（下次 Session 必讀）
|
||||
1. **重啟 ≠ 解決** — cadvisor Up 13h 又 321% 是鐵證
|
||||
2. **全景調查必要** — status 快照說「188 cadvisor 288%」隱藏了 Sentry/Gitea/node-exporter 的巨大背景噪音
|
||||
3. **Compose 來源 drift 危險** — 188 cadvisor 真正來自 `momo-pro/monitoring/` 非 `wooo-aiops/` 差點治錯
|
||||
4. **配額即智能** — L2 配額比閾值規則更智能，因為它把「限制」寫進基礎設施
|
||||
|
||||
### 技術債（5 項）
|
||||
見 `project_current_status.md` 頂部
|
||||
|
||||
### 下一 Session 接手
|
||||
1. 驗 110 load 是否穩 <10
|
||||
2. 驗 9 條 infra_self_monitoring 規則活躍
|
||||
3. 補 ADR-090 11 表 migration（需先找 prod DB 位置）
|
||||
4. 決議 110/188 手動管 compose 是否納入 Git
|
||||
|
||||
---
|
||||
|
||||
## 📍 2026-04-17 晚 — P1+P2 安全熱修 + 第一次授權執行歷史里程碑 🏁
|
||||
|
||||
### 第一次 [✅批准] 歷史時刻
|
||||
|
||||
Reference in New Issue
Block a user