docs(logbook): record argocd health recovery [skip ci]

This commit is contained in:
Your Name
2026-06-04 09:18:33 +08:00
parent e355c8eb0f
commit 160209aba4

View File

@@ -39,12 +39,32 @@
- `awoooi-prod.spec.source.kustomize.images` 必須為空。
- 違反即 fail-fast避免正式站再被支線或手動 image override 拉回舊版。
**殘留觀察**
- ArgoCD top-level health 仍顯示 `Degraded`,但 `.status.resources`任何 degraded child resourcecontroller log 顯示 sync 成功且沒有錯誤;目前以 rollout、Pod ready、public API health 與 Playwright 為實際可用性判斷。需另開一小段清理 Argo health stale/custom-health 行為,避免治理頁被橘燈誤導
**ArgoCD health 追補修復2026-06-04 09:14 台北)**
- 初始症狀:`awoooi-prod.status.health=Degraded`,但 `.status.resources` unhealthy child resourceDeployment 實際皆 ready
- 根因 1`argocd-cm` 設有 `resource.customizations.ignoreResourceUpdates.all: /status`,導致 Argo 對所有資源 status 更新過鈍。
- 根因 2`argocd-cmd-params-cm` 未啟用 `controller.resource.health.persist``.status.resources[].health` 不落入 Application CRDtop-level health 缺少子資源證據。
- 根因 3`k3s-status-report` 於 2026-06-04 01:00台北用舊 image 失敗後CronJob `lastScheduleTime` 晚於 `lastSuccessfulTime`Argo 正確判定該 CronJob degraded。
- Live 修復:
- 移除 `argocd-cm.data.resource.customizations.ignoreResourceUpdates.all`
- 設定 `argocd-cmd-params-cm.data.controller.resource.health.persist=true`
- 重啟 `argocd-redis``argocd-server``argocd-application-controller` 以清 appTree cache 並載入新參數。
- 手動補跑 `kubectl -n awoooi-prod create job --from=cronjob/k3s-status-report k3s-status-report-manual-20260604091401`Job 使用 `f1ef7ec3` image`Complete 1/1`log 顯示 `k3s_daily_report_sent`
- 修復後:
- `k3s-status-report.status.lastSuccessfulTime=2026-06-04T01:14:38Z`
- `awoooi-prod``targetRevision=main``images=[]``revision=e355c8eb0fee1b1b5b41955811bc987ba2d88ef1``sync=Synced``health=Healthy``unhealthy=[]`
- Deployment resource health 已持久化為 `Healthy`CronJob health 全部 `Healthy`
- Production workloads 維持 `awoooi-api 2/2``awoooi-web 2/2``awoooi-worker 1/1``awoooi-auto-repair-canary 1/1`image 仍為 `f1ef7ec3...`
- 待後續 GitOps 化:目前 ArgoCD configmap live fix 尚未找到 repo source需補一份 Argo config source-of-truth避免 Argo 重裝後遺失 `controller.resource.health.persist=true` 與 status watch 修正。
**Ollama health 觀察**
- 追補期間 API `/api/v1/health` 曾短暫 `degraded`,原因是 `ollama_gcp_a` 進短 cooldown 且 `ollama_local` (`11437`) 回 `502`
- 直接從 API Pod 測試:`ollama_gcp_a` (`11435`) `200``ollama_gcp_b` (`11436`) `200``ollama_local` (`11437`) `502`
- 這不影響既定順序 `GCP-A -> GCP-B -> 111/local -> Gemini fallback`;但 `ollama_local` 502 與 health aggregation 對 fallback 狀態的權重需另列 P1避免把 fallback 節點問題誤報成核心服務故障。
**進度更新**
- Production 首頁版本恢復:`100%`
- GitOps source guard`0% -> 80%`;已在 CD 補 fail-fast尚待下一次 CD 實跑驗證。
- ArgoCD health truthfulness`40% -> 85%`live 已啟用 resource health persistence 並修復 CronJob degraded尚待 config GitOps 化。
- CI/CD release gates維持 `100%`,新增 source contract gate。
- 完整 AI 自動化飛輪:維持 `67%`;本輪是 production source 修復與可觀測性補強,未新增 auto-repair execution。