tags: cofacts, —

20260407 會議記錄

:::info

所有會議記錄
NPO Hub 出席：bil, lahna, mrorz, alfred
線上出席：ggm
https://meet.google.com/mrz-dgrd-pri :::

💻 Github 上發生了什麼？

cofacts/takedowns
- Add privacy removal report for message in database #291
  - MrOrz 開了 PR，希望能移除包含家庭隱私資訊的訊息。
- Takedown spam user 日本外送茶TG：yy9882 YMwgWJ0BZgZZYBoadwoP #290
  - nonumpa 關閉了這個 PR。
cofacts/ai
- design: Cofacts design system component library #22
  - MrOrz 開了 PR，新增了 Cofacts design system component library。

:mag: 本週確認事項

GCE Migration

Cost review

3/27 GCE migration

3/28 ~ 4/6 十天 USD121 –> 30天約 370USD
Cloudrun distribution: 50% TW, 50% en+ja

:::info TODO

可以開始把 en, ja 搬到 GCE 上 –> estimated cost save = 70USD/mo
跑幾週看穩定度，決定是否要再把 tw site 也搬進 GCE
跑幾個月看實際用到的運算量，決定 GCP committed use discount 怎麼買比較划算 :::

LINE bot 穩定度

3/27 migration 之後，LINE bot 很常在整點 15 分的時候有 502 error

Linode 上我們本來就會每個整點 15 分時重啟 Line bot（處理 group chat 機制不穩定問題），但當時用的是 pm2 reload 指令
GCE migration 時，這個 cronjob 被寫成直接用 docker-compose restart，導致有 downtime。
4/7 傍晚發現並已經修正，19:15 開始應該會正常無 downtime。

:::info

還沒做的東西

Cloudflare HTML cache and AI crawler defense
Linode rsync 備份 + 刪 instance :::

Elasticsearch 升級

Design doc: https://docs.google.com/document/d/1sZ4jOsrZPvbJv4QjlMxgbqFsh_pTZNBRs-NbG-HU0rM/edit?tab=t.auumvk9ockbl

4/1 凌晨 1:40 ~ 4:10 進行了 Elasticsearch v9 migration

:::spoiler Production cutover status 我已經連入 cofacts-prod 檢查過整體的運作狀態與系統資源了。

整體來說，你的 v9 migration 看起來非常成功，核心的 DB 與 API 都已經穩定運作了整整 6 天。但有幾個小細節（以及兩個不斷在重啟的周邊服務）值得你留意一下：

1. Elasticsearch v9 升規與資源佔用（狀況良好 ✅）

目前的 rumors-deploy-db-1 正在穩穩地跑著 elasticsearch:9.3.2，系統中這台容器的實體記憶體佔用約為 15.14 GiB。這個數字完美貼合了你設定的 -Xms16g -Xmx16g Heap Size。而且目前整台 GCE 的記憶體總共有 31 GiB，可用（Available）的包含 cache 還有將近 15 GiB，留給 OS 與 Lucene 檔案快取的空間非常充足。

2. Swap 使用量達 99%（無須緊張 ℹ️）

GCE 登入後的提示與 free -h 顯示 Swap 空間 (4.0GiB) 已經用滿了 (99%)。這大概率是升級期間 (Phase 1 & 2) 同時跑 v6（16GB Heap）加上 v9（8GB Heap）再疊加第一次 Reindex 時，把記憶體撐爆，造成了大量的分頁被交換到 Swap 所遺留的歷史痕跡。現在由於可用實體記憶體空間很大，這些 Swap 裡的東西就只是一些長期未存取的不活躍分頁（Inactive pages），不用理它也不會影響效能。若看著不順眼，你可以另外找時間手動重置它：sudo swapoff -a && sudo swapon -a。

3. URL Resolver 正在觸發 OOM 被砍（值得注意 ⚠️）

rumors-deploy-url-resolver-1 在我檢查時，顯示運作時間只有 15 分鐘（近期有重新啟動的跡象）。
我查了一下本機的 dmesg 跟 syslog，發現該容器內的 chrome 程序觸發了 Memory cgroup out of memory 而被砍掉。這是因為 docker-compose.yml 裡面可能給予了該服務大約 512MiB 的記憶體限額，但 Puppeteer/Chrome 開網頁非常吃記憶體，因此超過了 CGroup 的限制被砍。

評估：這不影響 GCE 主機，只是純粹容器內限額達到上限。這對於 URL Resolver 來說通常是被預期的操作（藉由 Docker 重啟來釋放洩漏或暴增的記憶體）。如果不希望它一直重啟，且主機目前記憶體還很充裕，或許可以考慮稍微調高一點記憶體上限，例如到 1GB。

4. LINE Bot 持續報 Apollo 錯誤（值得注意 ⚠️）

rumors-deploy-line-bot-zh-1 在我檢查時也顯示才剛起來幾分鐘而已。從這個服務的 Log 裡，發現了一整排很頻繁的錯誤訊息：

Error reporting server info to Apollo during schema reporting: Error: An unexpected HTTP status code (401) was encountered during schema reporting.

評估：看起來是傳遞給 Apollo 的 Token 失效或是過期了（401 Unauthorized）。這本身可能不影響使用者查核的功能，但如果該服務因為 error 或是 healthcheck 一直 crash 重啟的話，可能會遺漏 webhook。可以檢查一下對應的環境變數。

5. 作業系統更新提示

登入時會看到 *** System restart required ***，表示 Ubuntu 的底層 Kernel 順著 package update 已經安裝好了新版本，但需要你手動重啟機器才會套用。你可以在未來確認沒有重大活動的離峰時間，下一道 sudo reboot，重啟後所有 restart: always 的服務都會自己長回來，非常方便。 :::

:::info TODO

找一個離峰時間重開 GCE –> reset Swap ＆ apply Ubuntu kernel
確認 weekly backup 有正常運作、修正 weekly opendata publish https://github.com/cofacts/opendata/pull/32 :::

Cofacts.ai 開發

Progress update: https://github.com/orgs/cofacts/projects/12
Hybrid search: https://docs.google.com/document/d/1sZ4jOsrZPvbJv4QjlMxgbqFsh_pTZNBRs-NbG-HU0rM/edit?tab=t.lhafy6bbdc9p
- 例子：AI 假海嘯影片 https://cofacts.tw/article/6w6rYJgBngzKCCgMrohC
- 例子：鳥喝水暴斃 https://cofacts.tw/article/Ar4e2pgB6nor6FKt1vXc

小聚 rundown

API access

verify1st.tw / https://github.com/topben/cryptotruth/pull/50

Product

主要是用 LLM 生成防詐文案
Cofacts 用來作為 Crowd-source evidence，會交給 LLM 生成最後訊息

Concerns

源頭活水：希望流量數字可以收得到、feedback 收得到
不要有 extra effort for us

https://github.com/cofacts/opendata/blob/master/LEGAL.md

不在 LINE 所以給 LIFF URL 沒有太大幫助