20260727 會議記錄

:::info

上週重點整理（2026-07-21 ～ 2026-07-26）

GitHub 活動

cofacts/ai

cofacts/url-resolver

benchmark

detail

cofacts/kb

cofacts/opendata

cofacts/takedowns

Discord 重點討論

general

@bil：嗨嗨我想請問，下週的周會改到 07/27（一）會是可以的嗎？ @mrorz：收到，已調整完畢 @mrorz：https://cofacts.tw/article/3r95ela9vhf51 這篇在 LINE 查詢數這麼高，也尚未回應，為啥 reply request 數量才 4 個｜同一人重複查詢這麼多次嗎 @@ @mrorz：結論：是因為他是 FB 連結、再加上我們群組裡面做「visit」的比對較寬鬆，所以任何 FB 連結可能都會被視為很接近

dev

@MrOrz：上週更新了（忘記在開會時講）結果 observation v2 API 其實是要啟動 v4 observation 才適用的。v4 observation 其實是滿大的變動，要把現有 trace 的欄位也寫到 observation 去，藉此省去昂貴的 join operation，我們目前還沒使用。所以即使我們 Langfuse 已經更新到新版了，我們用 langfuse cli 分析的時候，他還是會抱怨 observation v2 API 無效 ._. @MrOrz：更新一下 cofacts/ai 的部分。現在是 cofacts/ai 建構整個系統的時候，過去幾個月其實做了不少設計選擇……這一層一層的實作是為何要這樣做，資訊可能散佈在 PR description、comment 等地方。其實這些決策，如果能在實作的當下就用文件記下來，最能夠記錄設計選擇的脈絡，供未來參考。因此，我開了這個 PR: https://github.com/cofacts/ai/pull/120 ——把之前寫在 kb 的、關於 cofacts/ai 的 design doc（只有 authentication 一則）和之前的大 PR，放到 docs/decisions 裡面，用 Markdown Architecture Decision Record 的格式 @MrOrz：PR120 的文件 review 過了，大家也可以看一看唷～ 這樣回頭看，cofacts/ai 也確實在技術上幾經更迭呢。這個應該會對寫報告滿有幫助的（可以讓 claude 去掃）；然後開發的時候，有了這些文件，會比較知道為何 cofacts/ai 選擇了 vertex ai 等脈絡，應該能讓 coding agent 在做技術選擇時能考慮過往決策歷史 @MrOrz：這個 PR120 沒問題的話我打算 merge 唷。我還要 rebase 現有的兩個 draft PR，那兩個 draft PR 我覺得都大到需要寫 ADR

上週待辦

url-resolver

COSCUP

AI 修正

GGM: 目前沒有更新，可以看的時候會貼 DC cfacts-ai dev channel

cofacts.ai

小聚（08/16）

信件

Cofacts 正式環境狀態檢查（2026-07-14 ~ 2026-07-26）

1. GCE 伺服器 (cofacts-prod)

注:歷史資料實際涵蓋 07-18~07-26(9 天),07-14~07-17 因監控取樣視窗限制未回傳每日聚合值。

日期 CPU (min|avg|p95|max) Mem (min|avg|p95|max) Swap (min|avg|p95|max)
07-18 10.24% | 20.14% | 25.81% | 32.66% 62.44% | 65.74% | 68.67% | 71.12% 39.74% | 40.94% | 42.27% | 42.82%
07-19 11.12% | 28.27% | 64.68% | 75.70% 62.48% | 66.62% | 71.39% | 80.45% 37.65% | 41.00% | 44.29% | 45.49%
07-20 8.65% | 41.11% | 72.12% | 80.44% 62.09% | 68.35% | 74.53% | 78.42% 32.54% | 36.23% | 42.89% | 43.54%
07-21 11.21% | 52.62% | 75.04% | 86.78% 62.19% | 69.21% | 74.99% | 79.54% 39.70% | 40.71% | 42.31% | 42.79%
07-22 9.03% | 29.71% | 42.68% | 73.85% 62.84% | 65.74% | 68.68% | 70.95% 37.88% | 40.46% | 42.60% | 44.79%
07-23 7.48% | 25.46% | 39.42% | 43.05% 62.26% | 65.07% | 67.49% | 69.72% 40.12% | 42.03% | 43.31% | 44.08%
07-24 13.88% | 23.84% | 32.39% | 59.31% 62.09% | 65.30% | 68.07% | 73.80% 40.96% | 43.22% | 45.94% | 47.71%
07-25 10.98% | 16.57% | 21.40% | 41.97% 62.59% | 65.56% | 67.39% | 85.43% 42.35% | 44.32% | 46.52% | 46.58%
07-26 17.41% | 24.33% | 31.13% | 37.26% 63.42% | 66.44% | 68.08% | 84.93% 41.58% | 43.04% | 46.04% | 47.63%

目前即時狀態:已連續運行 80 天未重啟(load avg 1.14/1.50/1.49);Mem 20Gi/31Gi(約 65%,與均值一致);Swap 1.7Gi/4Gi(約 43%,與均值一致);Disk 52G/67G(77%)。

觀察:07-19~07-22 出現明顯的 CPU/Mem 尖峰(07-21 CPU 均值衝到 52.62%、max 86.78%),與 process 層資料交叉比對,是 Elasticsearch (java) 與 node server.js(rumors-api)同時飆高造成(見下方 §3)。這與 [[project_transcript_outage_202607]] 記錄中「07-19/07-20 尖峰成因待查」是同一起事件,目前仍未有定論,不是本次新發現。07-25/26 出現 Mem max 85%、84% 的短暫尖峰但未反映在均值/p95,應是瞬間突波,非持續性問題。

2. Cloud Run 服務狀態

所有 11 個服務皆為 Serving 狀態,無異常。

服務 Normal Range (p50) Stability (p95/p99) 觀察
site-tw CPU 0.03~0.38 vCPU(隨流量波動,週間較高) p99 多日精準落在 1.0118(疑似 CPU 配額上限) CPU 經常打到分配上限,有 throttling 風險
site-tw (mem) p50 0.76~0.81 GiB p95 固定 0.981GiB,p99 多日精準落在 1.0118 GiB 記憶體也經常頂到上限,建議評估調高配置
cofacts-ai CPU p50 極低(~0.015,幾乎閒置) p99 07-19 出現單日尖峰(0.469,為期間最高) 07-19 有一次性負載尖峰,之後回穩
site-staging-tw/ja/en CPU/Mem 均低且平穩 偶有 p99 頂到 ~1.01 上限(與 site-tw 同款配置) Staging 環境同樣有配額頂格現象,但因流量低影響不大
line-bot-en/ja, dev-line-bot CPU/Mem 皆極低且平穩 無異常波動 正常,無需關注

⚠️ 重點發現:site-tw、site-staging-tw/ja/en 這幾個服務的 CPU 與 Memory p99 在多個日期都精準落在同一個數值(~1.0118),這通常代表指標已達到 Cloud Run 容器的資源配額上限(而非真實用量),意味著實際負載可能被截斷/節流。建議之後檢查這幾個服務的 CPU/Memory 配置上限是否需要調高,尤其 site-tw 是主要對外服務。

3. GCE Process 層級排名(按尖峰用量)

記憶體 (RSS) Top 消耗者:

Process 平均/峰值 穩定度 備註
Elasticsearch (java) ~19.2GB / 19.8GB 極穩定(std ~100MB) 常駐最大記憶體用戶,07-21 峰值略升(19.67GB)
node /srv/www/server.js 293~652MB / 2.58GB 07-19~07-21 明顯不穩(std 達 225) 與上述 GCE CPU/Mem 尖峰同一時段,07-20 衝到 2.58GB
node build/index.js ~145MB / 857MB 平穩(std ~5-8) SSR 前端,偶有短暫突波但均值穩定
python main.py(cofacts-ai) 18~140MB / 323MB 波動較大(std 最高 79) [[project_cofacts_ai_python]] 已知此服務用量本就不穩定

CPU Top 消耗者:Elasticsearch (java) 全期最高,其次是 node server.js,兩者皆在 07-19~07-22 出現同步尖峰(呼應 §1 的 GCE CPU 異常),其餘為零星單日出現的 Puppeteer headless chrome render process(截圖/爬取任務所致,一次性,非持續問題)。

小結