使用模式是混合型：平時靠告警被動通知，收到通知後到 dashboard 查看細節。日常監控視圖提供「一眼確認系統正常」的能力，告警觸發視圖提供「出事了去哪裡查」的排障路徑。

日常監控視圖

服務狀態卡

一個狀態卡顯示 collector 的存活狀態和各 SDK 實例的最後心跳時間。狀態卡的設計是「綠色代表正常、紅色代表異常」的二元判斷 — 不需要使用者解讀數字。

Collector 存活的判斷依據是 health endpoint 回應。各 SDK 實例的狀態依據是最後一次 sdk.heartbeat 事件的時間 — 超過設定的逾時閾值（預設 10 分鐘）標為離線。

需要的事件：collector.health.check（collector 自身定期產生）、sdk.heartbeat（各 SDK 定期送出）、sdk.init（SDK 啟動時送出、標記上線）。

吞吐量曲線

折線圖顯示過去 24 小時每分鐘收到的事件數量。多個 SDK 實例用不同顏色區分。吞吐量的正常範圍由歷史資料建立基線 — 突然下降代表某個 SDK 停止送資料，突然上升代表 error storm 或重複送出。

需要的事件：collector.ingestion.count（collector 每分鐘記錄收到的事件數，按 source.app 分群）。

儲存用量

磁碟使用率的趨勢圖 + 保留策略的執行狀態。開發者需要知道「磁碟什麼時候會滿」和「purge 有沒有正常跑」。

需要的事件：collector.storage.disk_usage（定期取樣、metric 類型）、collector.storage.purge.completed（每次 purge 完成時記錄清了多少空間）。

SDK 連線列表

表格列出所有已知的 SDK 實例，每行顯示：app 名稱、版本、平台、最後回報時間、最後一次 init 時間。表格按「最後回報時間」排序 — 最久沒回報的在最上面，方便發現異常。

需要的事件：sdk.init（帶 source 完整資訊）、sdk.heartbeat（定期更新最後回報時間）。

Heartbeat 的觸發機制是 flush timer 的副作用 — SDK 的 flush timer 觸發時，如果 buffer 為空且距上次 heartbeat 超過設定間隔（預設 5 分鐘），自動注入一筆 sdk.heartbeat 事件後送出。不需要獨立的 heartbeat timer。App idle 時 heartbeat 仍會送出，dashboard 的 SDK 連線列表因此能偵測 SDK 是否仍存活。

告警觸發視圖

告警由 rule engine 觸發，觸發後開發者進入 dashboard 查看細節。每種告警條件對應一個排障路徑。

Health check 失敗

Collector 的 health endpoint 連續 N 次回應失敗（由外部 uptime check 偵測、如 cron + curl）。

進入 dashboard 後看：最後一次 collector.health.check 的時間和結果、collector 的 stderr log（systemd journal）、process 是否存活。如果 collector 已經掛了，dashboard 本身也不可達 — 這時的排障路徑是 SSH 到主機查 systemd 狀態。

SDK 停止回報

某個 SDK 實例超過逾時閾值沒有送 sdk.heartbeat。可能原因：被監控 app 當掉、網路斷開、SDK 初始化失敗。

進入 dashboard 後看：該 SDK 的最後事件（什麼類型、什麼時間）、最後 sdk.init 的 source 資訊（版本、平台）、同時段其他 SDK 是否正常（區分「單一 SDK 問題」和「collector 端問題」）。

磁碟用量超過閾值

collector.storage.disk_usage 超過 80%。

進入 dashboard 後看：各 backend 的空間佔比（SQLite DB 大小 + 匯出檔大小）、最近一次 purge 的執行時間和清理量、保留策略的設定值。如果 purge 正常執行但空間仍不足，代表事件產生速度超過清理速度 — 需要調整保留策略或擴容磁碟。

事件吞吐量異常下降

每分鐘事件數從正常基線突然下降超過 50%。

進入 dashboard 後看：吞吐量曲線標注「下降起始時間」、SDK 連線列表確認哪些 SDK 在該時間點後停止回報、collector 的 ingestion error log。

需要的事件總表

這些事件是 collector 自身的營運事件，和被監控 app 的事件走同一個 Storage interface 儲存。Collector 同時是事件的生產者和消費者 — collector.ingestion.count 由 collector 自己產生、自己儲存、自己在 dashboard 顯示。

deployment.started / deployment.completed 這兩個 lifecycle event 在 server-side 部署流程中對應 Backend 5.8 Deployment Rollout 的 evidence package——rollout 的每一批切換需要可判讀的部署事件作為證據。自架 collector 場景的部署追蹤規模遠小於 production server-side rollout，但 event schema 設計（timestamp / version / environment / result）可以跟 server-side 的 evidence 欄位對齊，讓未來規模成長時 event 格式不用重新設計。

自動恢復設計

自用工具場景下「凌晨三點 collector 掛了」的處理策略是自動恢復，不需要人介入。

自動恢復後 collector 送出 collector.started 事件，dashboard 的服務狀態卡從紅轉綠。如果連續重啟（10 分鐘內重啟 3 次以上），systemd 的 StartLimitBurst 阻止無限重啟、改為發送告警通知人工介入。

存取控制

Day-one 的 dashboard 預設無認證 — 同區網內的任何裝置都能打開 dashboard URL。這是同區網信任模型的設計選擇，和 collector 的 HTTP endpoint 無認證一致。

風險告知

無認證的 dashboard 暴露以下資訊給同區網的所有裝置：

• DevOps dashboard：SDK 版本、平台、IP、collector 的磁碟用量
• Developer dashboard：error stack trace（可能包含檔案路徑和程式碼片段）、session 回放（使用者操作序列）
• 中台 dashboard：行為事件明細、funnel 轉換率

家用 LAN 的場景下，家裡的其他裝置（IoT、家人的電腦）也能存取這些資訊。

最小防護

Go 的 net/http middleware 可以用幾行程式碼加 basic auth：

 1func basicAuth(next http.Handler, user, pass string) http.Handler {
 2    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 3        u, p, ok := r.BasicAuth()
 4        if !ok || u != user || p != pass {
 5            w.Header().Set("WWW-Authenticate", `Basic realm="monitor"`)
 6            http.Error(w, "Unauthorized", 401)
 7            return
 8        }
 9        next.ServeHTTP(w, r)
10    })
11}

帳密在 collector 的配置檔設定。Day-one 可選（不設就不啟用），但配置檔中應有 commented-out 的範例讓使用者知道這個選項存在。

Tripwire

Collector 暴露到公網或跨網路存取時，dashboard 的認證從可選變成必要。公網上的無認證 dashboard 等於公開了 error stack trace 和行為資料。

下一步路由

• Developer dashboard 設計 → Developer Dashboard 設計
• 中台 dashboard 設計 → 中台 Dashboard 設計
• Rule engine 的告警設計 → Rule engine 設計
• Collector 自我監控的 bootstrapping 問題 → 規模演進
• 服務探活與自動恢復 → DevOps 服務探活

和 DevOps dashboard 的差異：DevOps 看「基礎設施是否健康」，Developer 看「程式碼是否正確」。Error 趨勢上升在 DevOps 眼中是「事件量異常」，在 Developer 眼中是「程式碼 bug」。

日常監控視圖

Error 摘要

一個數字卡顯示最近 24 小時的 error 總數 + 和前一天的比較（上升 / 下降 / 持平）。旁邊標注「新 error」數量 — 過去 24 小時首次出現的 error name。

新 error 的偵測邏輯：error.name 在最近 24 小時的事件中存在、但在更早的事件中不存在。這是開發者最需要立即注意的 — 新版本引入的 bug 通常表現為「之前沒見過的 error name」。

Error 列表

表格按 error.name 分群，每行顯示：error 名稱、最近 24 小時出現次數、影響的 session 數、首次出現時間、最近出現時間。按出現次數降序排列。

點擊某行進入 Error 詳情視圖。

 1-- SQLite 層可用
 2SELECT name,
 3       COUNT(*) as count,
 4       COUNT(DISTINCT session_id) as sessions,
 5       MIN(ts) as first_seen,
 6       MAX(ts) as last_seen
 7FROM events
 8WHERE type = 'error'
 9  AND ts >= datetime('now', '-1 day')
10GROUP BY name
11ORDER BY count DESC;

Error 趨勢

折線圖顯示過去 7 天每天的 error 數量。可選按 error.name 過濾看單一 error 的趨勢，或看全部 error 的總趨勢。

趨勢的判讀訊號：

• 穩定持平 → 已知的 recurring error，排優先處理
• 新版本部署後突然上升 → 該版本引入的 regression
• 逐漸上升 → 累積性問題（記憶體洩漏、資源耗盡）

版本健康

按 source.version 分群的 error 率比較。每個版本顯示：error 數量、error rate（error / 總事件比）、最常見的 error name。

版本健康視圖幫助判斷「這個版本該不該 rollback」— 如果新版本的 error rate 顯著高於前一版，rollback 決策有數字依據。

Debug 深入視圖

從日常監控的 Error 列表點擊某個 error 進入深入視圖。

Error 詳情

單個 error name 的完整資訊：

• Stack trace（最近一次出現的 error.data.stack_trace）
• 首次出現時間和總出現次數
• 影響的 session 數和佔比
• 按版本分佈（哪些版本有、哪些沒有）
• 按平台分佈（iOS / Android / Web）
• 最近 10 次出現的時間軸

Session 回放

選擇一個受影響的 session，顯示該 session 的完整事件序列。事件按時間排列，每筆事件顯示類型、名稱、時間、data 摘要。Error 事件用顯眼的樣式標記，讓開發者快速定位「error 發生前使用者做了什麼」。

Session 回放需要同一個 session_id 的所有四類事件。這是 event-enumeration-method 中「Debug — 最近操作」事件的核心消費場景。

1-- SQLite 層可用
2SELECT type, name, ts, data
3FROM events
4WHERE session_id = ?
5ORDER BY ts;

平台分佈

某個 error name 在不同平台和 OS 版本的分佈圖。幫助判斷「這個 error 是全平台問題、還是特定平台的 bug」。

1-- SQLite 層可用
2SELECT json_extract(source, '$.platform') as platform,
3       json_extract(source, '$.os') as os_version,
4       COUNT(*) as count
5FROM events
6WHERE type = 'error' AND name = ?
7GROUP BY platform, os_version;

事件覆蓋確認

Developer dashboard 需要的所有事件在目前的事件設計中已完整覆蓋：

SQLite 層 vs PostgreSQL 層

Developer dashboard 的多數視圖在 SQLite 層就能運作 — 都是單表 GROUP BY 和 WHERE 過濾。

開發者 debug 場景不需要 PostgreSQL — SQLite 層的查詢能力已涵蓋所有核心視圖。PostgreSQL 的需求來自效能指標的高級分析（P95 趨勢），但這屬於效能監控動機而非 debug 動機。

下一步路由

• DevOps dashboard 設計 → DevOps Dashboard 設計
• 中台 dashboard 設計 → 中台 Dashboard 設計
• Error 事件的枚舉方法 → 事件枚舉與補齊檢查
• 功能分層與 Backend 選擇 → 功能分層與 Backend 選擇
• Error fingerprint 分群取代 name 分群 → Error Fingerprint 與去重分群

中台 dashboard 的所有深入分析視圖都需要 PostgreSQL 層（功能分層與 Backend 選擇），因為它們依賴跨 session 的 JOIN 和大規模聚合查詢。SQLite 層只能提供基礎的事件計數。

日常監控視圖

DAU / MAU

每日活躍使用者數（DAU）和每月活躍使用者數（MAU）的趨勢折線圖。活躍使用者的定義是「該時間段內至少有一筆 session.start 事件的唯一 session」。

DAU / MAU 比值（粘性指數）是產品健康的基本訊號 — 比值越高代表使用者回訪越頻繁。一般 SaaS 產品的 DAU/MAU 在 10-20% 為正常範圍，社交類產品期望 50% 以上。

1-- PostgreSQL
2SELECT date_trunc('day', ts) as day,
3       COUNT(DISTINCT session_id) as dau
4FROM events
5WHERE type = 'lifecycle' AND name = 'session.start'
6  AND ts >= NOW() - INTERVAL '30 days'
7GROUP BY day
8ORDER BY day;

核心漏斗

主要業務流程的每步轉換率。漏斗的步驟從 動機驅動的事件設計 的商業動機段定義。

日常視圖顯示最近 7 天的整體轉換率 — 營運人員每天看「昨天的漏斗有沒有異常」。轉換率突然下降是產品問題的早期訊號（UI 改版影響操作流程、第三方服務異常阻擋流程）。

功能使用排行

按 event.name 計數的排行榜。營運用它判斷「哪些功能有人用、哪些沒人用」— 功能投資的 ROI 判斷依據。

1-- SQLite 層可用（基礎計數）
2SELECT name, COUNT(*) as usage_count
3FROM events
4WHERE type = 'event'
5  AND ts >= datetime('now', '-7 days')
6GROUP BY name
7ORDER BY usage_count DESC
8LIMIT 20;

功能使用排行是 SQLite 層就能提供的視圖 — 單表 GROUP BY。

分析深入視圖

日常視圖發現異常後，營運人員進入分析視圖深入探究。所有分析視圖都需要 PostgreSQL 層。

Funnel 漏斗圖

互動式漏斗圖：選擇步驟 → 看每步轉換率 → 點擊某步看流失使用者的行為。

Funnel 需要 session 級 JOIN — 「同一個 session 完成了步驟 1 到步驟 N 中的哪些步驟」。完整的 SQL 查詢見 從 collector 資料做基礎 funnel 分析。

Cohort 留存表

按「使用者首次出現日期」分群的留存率矩陣。行是 cohort（第 N 週註冊的使用者），列是「第 1/2/3/…週的回訪率」。

需要的事件：user.first_seen（cohort 分群依據）+ session.start（回訪判定）。

user.first_seen 是 collector 端計算的衍生事件 — 當某個 session_id 或 user identifier 在系統中第一次出現時記錄。和 SDK 端送來的原始事件不同，它的產生者是 collector 的計算邏輯。

A/B 測試結果

實驗的 variant 間轉換率比較 + 統計顯著性指標（p-value、信賴區間）。

需要的事件：experiment.{name}.assigned（分組）+ experiment.{name}.converted（轉換）。這些事件在 動機驅動的事件設計 的 A/B 測試段定義。統計分析的方法見 A/B test 的統計基礎。

RFM 分群散佈圖

三維度（Recency / Frequency / Monetary）的使用者分群。每個使用者計算 R/F/M 分數，按分數分群後在散佈圖上顯示。

需要的事件：event 類的購買/使用事件 + lifecycle 的 session 事件。計算方法見 RFM 分群。

通路歸因

使用者從哪裡來（哪個廣告、哪個推薦連結、自然流量），每個通路帶來多少轉換。

需要的事件：attribution.install_source（SDK 首次啟動時從 referrer / UTM 參數 / deep link 取得安裝來源）+ conversion.{type}（轉換事件）。

attribution.install_source 只在 SDK 首次啟動時送一次。來源資訊的取得方式依平台不同 — Web 從 URL 的 UTM 參數取、mobile app 從 deferred deep link 或 install referrer API 取。

需要的缺口事件

中台 dashboard 暴露了三個目前事件表未覆蓋的事件：

這三個事件的共同特徵：前兩個是「只發生一次」的事件（首次出現、首次安裝），第三個是 collector 端的即時計算結果。操作盤點和四類補齊檢查聚焦在「反覆發生的使用者操作」，容易遺漏「只發生一次」的生命週期轉折點和 collector 端的衍生計算。

中台的權限隔離

營運和行銷人員看行為資料，但不需要也不應該看到 stack trace、raw error message、session 級別的原始事件明細。權限隔離在 collector 的查詢 API 層實作 — 不同的 API scope 回傳不同粒度的資料。

Scope 的實作可以是 API key 分級（不同 key 有不同 scope）、或 HTTP header 帶 role。Day-one 可以跳過（自用場景只有 developer 一個角色），tripwire 是「第一個非開發者要看 dashboard 時加入 scope 機制」。

下一步路由

• DevOps dashboard 設計 → DevOps Dashboard 設計
• Developer dashboard 設計 → Developer Dashboard 設計
• Funnel 分析的完整方法 → Funnel analysis
• 功能分層與 Backend 選擇 → 功能分層與 Backend 選擇
• 去識別化是中台 dashboard 的入場條件 → 模組七 資安與隱私
• 畫面狀態矩陣定義了 funnel 步驟的操作來源 → 畫面狀態矩陣