自動交易最麻煩的不是策略，是判斷它現在有沒有真的在跑。服務可能活著但資料停更兩小時，資料可能是新的但下單器根本沒建置 —— 這兩種在 systemctl status 裡都是綠的。
所以把所有判斷條件拉到同一頁。以下只講功能，引擎以 A/B/C/D/E 代稱。
介面快照（可點分頁，識別字與數值均已置換）：https://x213212.github.io/monitor/
串接的 API
| 類型 | 用途 |
|---|---|
| 加密貨幣期貨（測試網／主網） | K 棒串流、下單、部位查詢 |
| 台股券商 API | 模擬單、行情、帳務 |
| systemd D-Bus | 服務狀態、cgroup 資源與網路計量 |
主機 /proc、/sys |
CPU、記憶體、swap、磁碟、網卡 |
金鑰不行程式碼也不進設定檔，由執行環境注入，監控端完全不碰。
三層狀態
執行環境 — 頁首固定顯示目前 release 綁定的環境與引擎數。切換分頁不會改變下單環境，因為環境由 release 決定。「以為在測試網、其實在主網」是這類系統最貴的誤會。
服務與交易器分開顯示 — systemd 說 active/running，不代表交易器在動。交易器另外報 LIVE / NOT_STARTED / NOT_BUILT / STOPPED 加上心跳距今秒數。空轉的服務只有心跳看得出來。
資料新鮮度 — 每個引擎標 FRESH 或 STALE，後面接 K 棒總數與策略缺口。缺口是獨立指標：總數再多，中間缺三根就足以讓訊號算錯。
事件分類
事件有時間範圍和未解除狀態，不是一行 log：
引擎 B 資料異常 STALE (進行中)
引擎 A 流量斷流 ingress 0 bytes x12 (~6min) 01:54 → 01:55
引擎 A 流量暴衝 ingress 1274555 bytes (>3x) 00:56 → 00:56
分類是踩坑長出來的。最陰險的是流量斷流 —— TCP 沒斷、連線還在，但沒有位元組進來，所以不會有任何錯誤被拋出來。
每服務網路計量
主機層的總流量看不出是誰在灌，所以走 systemd cgroup 逐服務計量：
| 服務 | CPU | RAM | 下載 | 上傳 |
|---|---|---|---|---|
| engine-a | –% | 0 B | 0 B/s | 0 B/s |
| monitor | 2.1% | 44.51 MB | 927 B/s | 3.87 KB/s |
| engine-c | 0.6% | 249.01 MB | 42 B/s | 62 B/s |
部署
每個引擎是一個 systemd unit，綁定到一個不可變的 release。切版本就是換 release 再重啟，不是就地改檔案 —— 這樣「現在跑的是哪一版」永遠有答案。
監控本身也是一個 unit，對外只綁 loopback，要看就開 SSH 通道。沒有對外的 HTTP 入口。
唯讀
面板沒有任何按鈕會下單、重啟服務或改設定，真單操作限主機上的 CLI。
監控頁一旦能操作，就會變成「在手機上手滑砍掉正在跑的部位」的入口。拿掉操作面，這個風險就不存在，代價只是多開一個 SSH。
還沒做
警報推送（現在還要人去看）、歷史回放（只有當下狀態）、跨主機（目前綁單一主機）。
Comments