h2. 規格建議（2026-10-25，依新資訊修訂）

新資訊：@instance-20261017-095505@ 為 2 vCPU / 8 GB，且專用於 Redmine → BEAM 必須獨立開機（2 vCPU 跑 20 個 JVM 會直接卡死）。

h3. 三選項
| 選項 | 組態 | 合計 | 風險 |
| A. 單機最小 | @e2-standard-8@（8/32） | 8／32GB | 估算需求 26–28GB，餘裕僅 4–6GB，GC 尖峰易 OOM |
| B. 單機舒適 | @e2-standard-16@（16/64） | 16／64GB | 單點；Oracle I/O 與服務競爭 |
| C. 兩台分層（建議） | @beam-app@ @e2-standard-8@ ＋ @beam-data@ @e2-standard-4@ | 12／48GB | 多一台要管 |

建議 C：①Oracle／Kafka 的記憶體與磁碟 I/O 與應用不同，分開不互相拖累；②12/48 比 16/64 便宜約 25%（e2 線性計價）；③未來換 GKE 時 @beam-app@ 可退成操作機。

h3. 磁碟與區域
@beam-app@ 100GB／@beam-data@ 200GB，皆 @pd-balanced@；@asia-east1-b@。

h3. ★ 兩個容易漏的前提

VPC 要同一個：若新 VM 建在新 @beam-vpc@ 而 Redmine VM 在 @default@，兩者內網不通。POC 建議直接放同一 VPC；若 CI/CD 要呼叫 Redmine API 則必須可通。¶

不給外部 IP（@--no-address@）走 IAP 通道——需要 @roles/iap.tunnelResourceAccessor@。¶

h3. 現成指令
已寫入 OPS-001 §T-1.1（VPC／subnet／防火牆／兩台 VM 完整 @gcloud@ 指令）。

h3. 成本
未給具體金額——e2 按 vCPU／GB 線性計價，實際請以 GCP Pricing Calculator 試算；我不用記憶中的價格充數。

h2. 環境現況登錄 ＋ 連線準備（2026-10-25）

h3. 已確認（由客戶 Console 截圖登錄）
| 項目 | 值 |
| 專案 | @My First Project@ ／ Project ID @project-384c5e55-666e-422a-b12@ |
| 組織 | @iec-ticket-org@（@276760220681@） |
| Zone | @asia-east1-b@ |
| BEAM VM | @instance-20261025-075628@：外部 @34.80.107.222@／內部 @10.140.0.3@ |
| Redmine VM | @instance-20261017-095505@：外部 @35.221.190.90@／內部 @10.140.0.2@ |

★ 兩台同在 @10.140.0.x@ → 同一 VPC，內網互通 → 先前「新 VPC 與 default 不通」的疑慮不成立，不需 peering。

h3. 存取方式（已決議：SSH 金鑰，不用服務帳戶金鑰）
權限最小、可單獨撤銷。我方已產生 ed25519 金鑰，私鑰留本機不傳出：

@ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAtr4941pbx+VR5flDeKNdPtunW75LSM8eMkn7ufEuZi workbuddy-cardcore-poc@

待客戶操作（約 1 分鐘，二選一）：

A（建議） Compute Engine → 中繼資料（Metadata） → SSH 金鑰 → 新增 → 貼整行 → 儲存（一次涵蓋兩台）¶

B 個別 VM → 編輯 → SSH 金鑰 → 貼上 → 儲存¶

防火牆需允許 @tcp:22@（若 @default-allow-ssh@ 仍在即可直連）。

h3. 已備妥（待連線後執行）

• @ops/gcp/OPERATIONS.md@：環境、9 步進度表、注意事項（憑證不入 VM／Oracle 獨立 SSD／20 JVM 分批啟動／結束關機避免計費）
• @ops/gcp/install-beam.sh@：草案（Docker／JDK21／Node22／helm／kubectl／kind），冪等＋先盤點機器規格，@bash -n@ 通過

h3. ⚠️ 如實揭露
@install-beam.sh@ 尚未在目標 VM 實測——@bash -n@ 只驗語法不驗行為；Oracle 映像架構（x86/arm）、20 個 JVM 的啟動風暴，都只有真機能確認。首次執行時我會逐段確認後才標「已驗證」。

h3. 下一步
客戶貼公鑰後：連線 → 盤點規格（nproc／free／df／OS）→ 安裝 → 起基礎設施 → kind → 建置部署 → 驗收（20 服務 health 全 UP、出帳、部署作業台、前端）。

h2. ✅ BEAM 已在 GCP 跑起來（2026-10-25，T-1 主體完成）

h3. 環境實測
| 項目 | 值 |
| vCPU／RAM | 16／62 GB |
| 磁碟 | 290 GB（用 2%） |
| OS | Ubuntu 24.04.5 LTS x86_64 |
| Docker | 29.9.2（免 sudo） |
| JDK | 21.0.13 |
| helm／kubectl／kind | 4.3.0／1.37.1／0.30.0 |

h3. 成果

• 基礎設施 9 容器 healthy（Oracle／Kafka／Redis／PG／Prometheus／Loki／Grafana／Jaeger／otelcol）——Oracle 4 分鐘就緒，19 個 @CC_*@ schema 自帶
• @./gradlew bootJar -x test@ 3m28s → 18 服務 jar（＋gateway／bff）
• @ops/gcp/start-all.sh@ 分批啟動（每 5 個 25 秒）→ 20 / 20 @/actuator/health@ UP
• 真實資料查詢成功：帳戶 @…0002@ 額度 @permanentAmount=10000@
• RAM 使用 24 GB / 62 GB——與估算 26–28 GB 相符

h3. ★ 實作挖到四個坑（皆已修，已寫入 @ops/gcp/OPERATIONS.md@）

非互動 SSH 不讀 @.bashrc@ → @nohup: java: No such file@；腳本須自設 @JAVA_HOME/PATH@¶

種子 @ORA-00942@（@SYS.ACCOUNT_LIMITS@ 不存在）——種子用未限定表名，須 @alter session set current_schema=CC_xxx@，且必須先跑過 Flyway（先啟一次服務）¶

helm 裝成 v3.22.1（專案鎖 4.3.0）——@get-helm-3@ 只裝 v3 → 手動裝 v4.3.0 到 @~/.local/bin@（無 sudo）¶

@ORA-12516@：20 服務 × 預設 pool 20 = 400 連線超 Oracle Free 上限 → @DB_POOL_MAX=5@／@DB_POOL_MIN=1@¶

④ 的教訓最貴：「服務起得來」≠「撐得住」——剛啟動 pool 未長滿、health 全綠；跑幾分鐘後 pool 擴張才爆，症狀是「突然全部失敗」。健康檢查要過幾分鐘再驗一次。

h3. 待完成（T-1 剩餘）

• kind 叢集 ＋ 佔位映像（12-3 部署作業台演示用）
• 出帳／部署作業台／前端之端到端驗收

h3. 下一步
T-2 Redmine 遷移（GCP 權威、每日全量，D-058）。

h2. T-1 端到端驗收完成（2026-10-25）

h3. kind 叢集與部署

• kind 0.30.0 叢集建立於 GCP VM
• 三版佔位映像 @cardcore-standin:v1/v2/v3@ 建置並 @kind load docker-image@
• Helm 部署 → 20 / 20 Deployment @1/1@ READY

h3. 端到端三項（全通）
| # | 項目 | 結果 |
| ① | 部署作業台 @GET /deployments@ | release @cardcore@／rev 1／20 服務全 READY |
| ② | 分期出帳 @POST /api/v1/installment-billings@（2027-01-25） | selected 9／posted 9／failed 0 |
| ③ | 前端後端 @bff-web@ | health 200 |

h3. ⚠️ 未完成

• 前端 UI 未建置：@node_modules@ 未隨 rsync 傳（排除規則），需 @npm ci@ ＋ @npm run build@。目前僅驗到 @bff-web@ 後端 200，不能算「前端可開」。

h3. 教訓
rsync 排除 @node_modules@ 省了傳輸時間，但「前端可開」這條驗收就得另外補建置步驟——排除規則要對照驗收清單檢查一遍，否則驗收會缺一角。

h3. T-1 狀態
主體（環境＋20 服務＋出帳＋部署作業台＋kind）已完成；僅剩前端 UI 建置。之後可轉 T-2 Redmine 遷移。

h2. 前端建置完成（T-1 收尾，2026-10-25）

h3. 結果

• @npm ci@ ＋ @npm run build@ → dist 648 KB、建置 432 ms
• @vite preview --port 4173@ → @/@ HTTP 200、含 @
  @、@assets/index-BbvVxplr.js@ HTTP 200（639 KB）

  h3. ⚠️ 驗證界線（如實揭露）
  | 已驗 | 未驗（原因） |
  | 靜態資源可載入（200 + root div + JS 200） | React 是否真的掛載——VM 未裝 Chrome，無瀏覽器端渲染驗證 |
  | @bff-web@（8101）health 200 | API 呼叫——@vite preview@ 未設 proxy（僅 @server.proxy@），API 會 404 |
  | — | 登入——Keycloak 未部署於 VM（8180 無服務） |

  故僅能宣稱「前端可載入」，不可宣稱「可操作／可登入」。
  要完整驗收需：①@vite.config@ 補 @preview.proxy@；②VM 部署 Keycloak；③裝 headless Chrome 截圖。

  h3. T-1 總結
  | 項目 | 狀態 |
  | 環境安裝（Docker/JDK21/Node/helm4.3/kubectl/kind） | ✅ |
  | 基礎設施 9 容器 | ✅ |
  | 20 服務建置＋啟動（20/20 health UP） | ✅ |
  | kind ＋ Helm 20/20 READY | ✅ |
  | 分期出帳（9/9 成功） | ✅ |
  | 部署作業台 API（20 服務全 READY） | ✅ |
  | 前端可載入 | ✅（界線見上） |

  T-1 主體完成；可轉 T-2 Redmine 遷移。

【對外 URL 方案定案並上線】https://beam.dxcbank.com（2026-10-25 23:2x）

■ 背景
客戶把 beam.dxcbank.com 指向 34.80.107.222，但源站 80/443 無監聽 → 521。
客戶詢問「日後 URL 要怎麼用（例：https://beam.dxcbank.com:port → consul）」。

■ 結論（規格見 docs/06-ops/OPS-008）
對外只有 beam.dxcbank.com 一個入口，領域服務一律經 api-gateway。

https://beam.dxcbank.com/ → SPA（React Router，深連結 fallback）
https://beam.dxcbank.com/bff-api/** → bff-web:8101（前綴 /bff-api 替換為 /api）
https://beam.dxcbank.com/{svc}-api/** → api-gateway:8100
https://beam.dxcbank.com/deploy-api/** → 部署作業台 API（18090，刪前綴）
https://beam.dxcbank.com/auth/** → Keycloak（尚未部署，目前 502）

{svc} 共 17 個：auth card clearing dispute installment limit merchant migration
notification party payment posting pricing product report rewards statement

■ 三個「為什麼不」

1. 不用 https://beam.dxcbank.com:port —— GCP 防火牆只放行 80/443（VM 標籤 http-server/https-server），
   其餘埠實測全部 timeout（exit 28）。
2. 不用「每個服務一個子網域」—— dxcbank.com 沒有泛域名解析（實測 grafana./jaeger. 皆無記錄），
   每個子域都要手動加 DNS。
3. 不把領域服務／資料層對外 —— 對外應只留 gateway 一個出口，否則繞過認證／限流／審計。

■ 關於 consul
目前架構沒有 Consul：服務發現由 Kubernetes 自帶 DNS 負責（cardcore-*-service 就是 DNS 名）。
若客戶指定要 Consul，那是新增元件（部署形態／是否取代 k8s DNS／UI 存取控制都要決定），需另開 CR。

■ 實作
新增 ops/gcp/beam/{Caddyfile,docker-compose.yml}，於 34.80.107.222 的 ~/beam-edge 以 compose 起
cr-beam-edge（network_mode: host，因為要同時代理宿主機 jar 服務與容器發佈埠）。

■ 驗證（外網直打網域）
GET / → 200、<title>BEAM 信用卡核心 — 授權作…</title>
GET /assets/index-*.js → 200、639,627 bytes、text/javascript
GET /ops/deployments（深連結） → 200（SPA fallback 正確）
GET /bff-api/v1/bff/health → 200
GET /bff-api/v1/bff/dashboard → 200
GET /deploy-api/deployments → 200
GET /party-api/v1/parties → 405（POST-only → 路由正確）
GET /card-api/v1/cards → 400（參數缺失 → 路由正確）
TLS → Let's Encrypt，notAfter 2027-01-04
容器 → cr-beam-edge healthy

■ 實作踩到兩個坑
① strip_prefix /bff-api 得到 /v1/bff/health（少 /api）→ 404。
vite 的 rewrite 是「替換」不是刪除 → 改 uri replace /bff-api /api。
② handle /-api/ 是無效語法（Caddy 路徑匹配只支援尾端 *）→ 改 @svcapi path_regexp。

■ 挖出的既有缺口（未修，需評估）
campaign-service（8099）健康 200，但 api-gateway 沒有 /campaign-api/** 路由 → 對外 404。

■ 尚未完成

• Keycloak 未部署 → /auth 回 502，登入流程無法端到端演示
• SPA 建置未帶正式 env（VITE_KEYCLOAK_URL 仍是 .env.development 的 localhost:8180）
• 運維子網域（grafana/jaeger/prometheus）待加 DNS；Caddyfile 已備但註解，且已預留 basic_auth
• 資料層仍綁 0.0.0.0（Oracle/PG/Redis/Kafka），目前靠防火牆擋住，屬隱患

■ 需客戶動作
Cloudflare 加 A 記錄 → 34.80.107.222（橘雲）：grafana、jaeger（選用）

【運維子網域上線】grafana / jaeger（2026-10-25 23:3x）

客戶已在 Cloudflare 加好 A 記錄 → 34.80.107.222（橘雲）。

■ 結果
https://grafana.dxcbank.com/ → grafana:3000 ✅
https://jaeger.dxcbank.com/ → jaeger:16686 ✅
兩者皆套 Caddy basic_auth（帳號 ops）；Grafana 另有自身登入。
※ 密碼不寫在此（本 Redmine 已對公網開放），存放於 ops/gcp/beam/edge.env（gitignored），另行交付。

■ 為什麼要 basic_auth
Jaeger 沒有任何內建認證；Grafana 預設帳密 admin/admin 是公開知識。
兩者現在都在公網上，沒有外層認證等於把 trace（可能含 PII）與內部指標送給全世界。
Grafana 的 admin 密碼已由預設值改為強密碼。

■ 驗證（外網直打子網域）
grafana：無帳密 401／正確帳密 302→/login→200（<title>Grafana</title>）／錯誤帳密 401
/public/build/runtime..js → 200、50,236 bytes
admin 登入 API → 200（新密碼生效）
jaeger： 無帳密 401／正確帳密 200（<title>Jaeger UI</title>）／錯誤帳密 401
/static/index-.js → 200、4,317,985 bytes
/api/services → 200、20 個服務（limit/notification/merchant/statement/bff-web…）
→ 追蹤資料確實在流，不是空殼
TLS：兩張 Let's Encrypt 憑證皆簽發成功（HTTP-01 經 Cloudflare 轉發到源站 80）

■ ★ 第三個坑（實測，會再遇到）
Compose 會對 env_file 做變數插值 → bcrypt 雜湊的 $2a$14$TME5… 被當成變數吃成空字串，
容器內只剩 $2a$14/L/dsc./GFm3pWU4iW → 正確密碼也回 401。
修法：edge.env 內 $ 一律寫成 $$。
驗證：docker exec cr-beam-edge printenv OPS_AUTH_HASH（要看得到完整的 60 字元雜湊）

■ 尚未做

• Prometheus 子網域未啟用（客戶未要求；Caddyfile 已備，取消註解即可）
• Grafana GF_SERVER_ROOT_URL 未設 → 站內分享連結／信件連結會指向 http://localhost:3000
  （瀏覽本身正常；要修需以新 env 重建 cc-grafana 容器）

【Grafana 空的？】查出兩個原因，已修（2026-10-25 23:5x）

使用者問「Grafana 裡面是空的，正常嗎？dashboard 還沒建，是吧？」
答案：「還沒建」只對一半 —— 底下還有一個真的 bug。

■ 原因 ①（確實是「還沒建」）
0 個 dashboard、0 個資料夾，也沒有 provisioning 設定。

■ 原因 ②（真 bug，不修的話 dashboard 建了也全空）
Prometheus 22 個 scrape target 只有 2 個 UP：
dial tcp: lookup host.docker.internal on 127.0.0.1:53: no such host
根因：prometheus.yml 用 host.docker.internal:808x 抓宿主機上的 jar 服務，
但那是 Docker Desktop（Mac/Windows）專有名稱，Linux 上不存在。
這份 compose 當初在 Mac 寫的，搬到 GCP Linux VM 就斷了。
修法：prometheus 服務加 extra_hosts: ["host.docker.internal:host-gateway"]（Docker 20.10+）。
結果：21 UP / 1 down（down 的是 Keycloak:9000，Keycloak 尚未部署）。
實測指標量：http_server_requests_seconds_count 65 series、jvm_memory_used_bytes 464、hikaricp_connections_active 55。

■ 連帶處理

1. prometheus.yml 改寫 19 個 target → 每個一個 static_configs + labels:{tier,svc}
   圖例才顯示得出服務名（原本只有 host.docker.internal:8083）。promtool check 通過。
2. 指標標籤不統一：直抓的在 svc，OTel 轉發的在 exported_job
   → JVM／連線池面板用 label_replace 對齊。
3. 新增 provisioned dashboard「BEAM 平台總覽」（uid beam-overview，9 面板），
   檔案在 ops/local/config/grafana-dashboards/（可版控、重啟自動載入）。
4. 順帶修 GF_SERVER_ROOT_URL（原本未設，分享連結會指 localhost:3000）。

■ 逐個面板實打 PromQL（不是「建了就算」）
服務UP／總QPS／平均延遲 → 1／1／1 series
5xx 比率 → 1 series（值 0）。原寫法在沒有 5xx 時 sum() 回空集合 → 面板顯示 No data，
很容易被誤判成「面板設壞」→ 已加 or vector(0)。
QPS by 服務／平均延遲 by 服務 → 19／19
JVM Heap by 服務／DB 連線池 by 服務 → 21／19
抓取狀態 → 38（19 新 + 19 舊，5 分鐘後舊 series 過期）

■ 外網驗證
經 Caddy basic auth 換 Grafana session → login 200、/api/search?type=dash-db 200，
1 個 dashboard「BEAM 平台總覽」。

■ 如實揭露
沒有 p95：http_server_requests_seconds 只有 _count／_sum／_max，沒有 _bucket
（Micrometer 未開 percentiles-histogram）→ 面板用「平均延遲」而非 p95。
要 p95 需在服務加 management.metrics.distribution.percentiles-histogram.http.server.requests=true 並重建。

【一致性核對 ＋ p95 補齊】2026-10-26 00:1x

■ 問題一：本機與 GCP 的程式碼一樣嗎？
一樣。 但不能用 git 判斷——GCP 的 ~/cardcore 不是 git repo（當初是整包複製過去的）。
改用 sha256 逐檔比對（排除 build／dist／node_modules／logs）：

共同檔案 1,550 個，內容差異 0
只在 GCP：無
只在本機：6 個，皆 ops/gcp/{beam,redmine}/* —— 部署產物，實際落在 VM 的
~/beam-edge 與 ~/redmine，不在 ~/cardcore（設計如此）
環境值差異：ops/local/.env 的 GRAFANA_ROOT_URL=https://grafana.dxcbank.com/

所以「只有 yaml 不同」不精確：yaml 也完全一樣；差的是 .env 環境值。
核對時另外發現 ops/gcp/start-all.sh 只存在 VM 上、沒進版控（啟動 20 服務的關鍵腳本）
→ 已收回版控。

■ 問題二：p95 必須兩邊一致
已在 20 個 application.yml（18 領域服務 ＋ api-gateway ＋ bff-web）的 management 段加入：
metrics.distribution.percentiles-histogram.http.server.requests: true
metrics.distribution.minimum-expected-value.http.server.requests: 1ms
metrics.distribution.maximum-expected-value.http.server.requests: 10s

為什麼要設 min/max expected value：不設時 Micrometer 用預設約 70 個桶，
20 服務 × uri × status × method 的 series 會放大好幾倍；設定後桶數可控。

驗證：

• YAML 逐檔解析（容器內 pyyaml）：20/20 通過，且設定值 == true
• GCP 重建：bootJar -x test 51 秒
• 重啟 20 服務：20/20 UP
• http_server_requests_seconds_bucket 出現，2,440 個 bucket series
• histogram_quantile(0.95, …) = 419.6 ms（真的算出來了）

■ dashboard
兩個「平均延遲」面板改為 P95 延遲：
整體：histogram_quantile(0.95, sum by (le) (rate(http_server_requests_seconds_bucket[5m])))
by 服務：histogram_quantile(0.95, sum by (le, svc) (rate(...{svc!=""}[5m])))
逐面板實打：1／1／1／1／19／19／20／18／19 series，全部有資料。

■ 如實揭露

1. 本機的 api-gateway(8100) 仍跑舊 jar —— 原始碼一致，但執行中的 jar 是舊的。
   要讓本機也產生 _bucket，需在本機重建並重啟（我沒動，怕打斷你正在用的環境）。
2. GCP 的 ~/cardcore 沒有 .git → 程式碼無版本可追溯。
   建議後續改為 git clone，只同步受控檔案（現在靠我手動 tar 上傳，容易漂移）。

■ 過程踩到的兩個假綠

1. tar czf - $FILES 在 zsh 下不會對未加引號的變數做分詞 → 整串被當成一個檔名，
   tar 全部失敗，但 && 鏈仍印出「已上傳」→ 下一行 grep 回 0 才發現。改用 tar -T -。
2. pkill -f "java -jar" 會匹配到自己那行 shell（命令列含同樣字串）→ 連線被殺。
   改用 pkill -f "[j]ava -jar"（括號技巧）。

【本機 api-gateway 重建重啟完成】兩邊都跑新 jar（2026-10-26 00:1x）

■ 為什麼要做
上一輪只重建了 GCP；本機的 api-gateway 仍跑舊 jar（原始碼一致、但執行中的 jar 是舊的），
所以本機不會產生 http_server_requests_seconds_bucket。

■ 做法（照原本進程的形態，不自己發明）
從 lsof 反查舊進程：cwd=backend/platform/api-gateway、jar=build/libs/api-gateway-0.1.0-SNAPSHOT.jar、
Java=~/dev-tools/opt/jdk-21.0.12.1+1；再從失敗的舊背景任務得知啟動參數：
SPRING_PROFILES_ACTIVE=local（來自 ops/local/.env）
CARDCORE_SECURITY_ENABLED=false
清掉 HTTP_PROXY/HTTPS_PROXY/ALL_PROXY（本機 curl 必加 --noproxy 的同源問題）

流程：source ops/local/env.sh（JDK 21）→ set -a; . ops/local/.env → kill 舊 PID
→ 以相同參數啟動新 jar。

■ 驗證

1. 新 jar 時間 2026-10-26 00:11
2. jar 內的 application.yml 確實含 percentiles-histogram（不是「建了就算」）
3. 本機 api-gateway UP（約 20 秒）
4. 打 10 次真實請求後，/actuator/prometheus 出現 244 行 http_server_requests_seconds_bucket
   （其中 500 是因為下游 limit/party 服務本機沒跑，屬預期）
5. 本機 Prometheus 收到 244 個 bucket series；target host.docker.internal:8100 → UP
6. 本機 p95 實算 = 21.81 ms

■ 兩邊一致性（最終）
本機與 GCP 的 api-gateway jar 內 application.yml sha256 完全相同：
9b512f52c7e97319ede8d656bbff82f086fa3009b221c810abb6b7cca4dd41b0
GCP：20/20 UP、2,440 bucket series、p95 = 419.6 ms
本機：api-gateway UP、244 bucket series、p95 = 21.81 ms
（本機 bff-web 8101 未啟動 → 本機 Prometheus 該 target DOWN，屬正常）

■ 過程踩到的一個坑
nohup ... & disown 啟動的 java 進程在 Bash 工具呼叫結束後被回收——
日誌停在「profile is active: local」就沒有下文，8100 一直不監聽。
改用受管後台任務（run_in_background）才穩定存活（上一輪也是這個形態）。
→ 在這個環境裡，長跑服務不要用 nohup 脫離，要用受管後台任務。

【prometheus.dxcbank.com 上線】2026-10-26 00:2x

客戶已加 DNS：prometheus → 34.80.107.222（橘雲，三個解析器交叉確認皆指向 Cloudflare）。
Caddyfile 取消 prometheus 區塊註解 → 部署 → Caddy 自動簽發 Let's Encrypt 憑證。

■ 驗證（外網直打子域）
無帳密 → 401
正確帳密 → 302 → /query → 200，<title>Prometheus Time Series Collection and Processing Server</title>
錯誤帳密 → 401
/assets/index-.js → 200、1,966,265 bytes、application/javascript
/api/v1/query?query=sum(up{job=~"cardcore-."}) → 200、19（經外網查到真實資料）
ACME：certificate obtained successfully: prometheus.dxcbank.com
容器：cr-beam-edge healthy

■ 兩個「看起來像問題、其實不是」的現象（查證後才寫）

1. /favicon.ico 回 404 —— 直打 Prometheus 本體（127.0.0.1:9090）也是 404，
   是 Prometheus 自己沒有這個檔案，不是代理設定錯。
2. / 回 302 —— 是 Prometheus 自身把根路徑導到 /query，屬正常行為。

■ 現況：三個運維子域全部上線
https://grafana.dxcbank.com/ basic_auth(ops) + Grafana 自身登入
https://jaeger.dxcbank.com/ basic_auth(ops)
https://prometheus.dxcbank.com/ basic_auth(ops)

■ 提醒（已在回覆中說明，非阻斷）
Prometheus UI 主要用於臨時寫 PromQL；Grafana 的 Explore 也能直接查，
所以這個子域屬「方便」而非「必需」。若要收掉，取消 Caddyfile 區塊＋刪 DNS 即可。

【收工文件總整理】2026-10-26 00:5x

■ 收掉 prometheus 子域（D-062）
客戶裁定「多一隻香爐多一隻鬼，難維護」。取消 Caddyfile 註解 → 部署。
驗證：prometheus.dxcbank.com → 525（不再服務）；
鄰居全部正常（beam 200／grafana 302／jaeger 200）；
Prometheus 本體 127.0.0.1:9090 → 200（收的只是公開入口，內部抓取與 Grafana 查詢未受影響）。
⚠️ 待客戶：刪 Cloudflare 的 prometheus A 記錄（目前仍解析到 CF，源站不回應 → 525）。

■ 新增 GAP-004 缺口總覽（docs/00-governance/GAP-004_缺口總覽_20261026.md）
一頁看完「還剩什麼、明天先做哪個」：
§1 今晚關掉 7 項
§2 A 類我方工程 8 項（含估時）：Keycloak／前端正式 env／campaign 路由／Alertmanager／
停車 WebUI 4 項／本機一鍵起服務／GCP 改 git clone／資料層收緊
§3 B 類卡外部 6 項：12-7／12-5 待裁定、GAP-001 外部依賴、Cloudflare Full(strict)、
刪 prometheus DNS、代表性效能環境
§4 C 類風險 6 項：公網曝面、憑證曾在對話出現、GCP 無 sudo、edge.env 的 $$ 轉義、
兩邊 .env 靠人工同步、無 p99
§5 建議推進順序（明天／週末前／等客戶）
§7 如實揭露：估時非承諾；與 GAP-002 明細有出入時以 GAP-002 為準

■ HANDOVER 補上 §3.A-ops
原本完全沒有 GCP／Redmine／VS Code 的記錄（真缺口）。補 T-1／T-2／T-3 與 T-1′／T-2′
的狀態列，細節回 OPS-001（符合「只改狀態列，不寫敘事」）。

■ ★ check_memory.py 一次抓到 3 個問題，全部修掉
START-HERE 83 > 80 行、HANDOVER 3615 > 3600 行、START-HERE 未指向 TRP-004。
修法都是無損壓縮：合併同義列、收掉連續空行、說明併進標題——沒有刪掉任何事實。

■ 明天的第一件事
Keycloak 未部署 → 登入流程無法端到端演示（/auth 502、前端 VITE_KEYCLOAK_URL 仍指 localhost）。
這是唯一硬阻塞，其餘都能繞。