"Monitoring"
- Collector 架構
HTTP endpoint → JSON Schema 驗證 → 儲存 → 查詢 → rule engine 的五段式處理鏈路
- event.schema.json 完整欄位解說
監控事件的 JSON Schema 定義 — 每個欄位的語意、必填/選填、資料型別和設計理由
- Funnel Analysis
說明追蹤使用者在多步驟流程中每一步的轉換率和流失率的分析方法
- JS/TS 平台適配
CORS 限制、Service Worker 攔截、SPA 路由變換偵測 — 瀏覽器環境中 SDK 需要處理的平台特殊問題
- SDK Redaction API 設計
預設 redaction rule 過濾已知敏感欄位、自訂 pattern 擴展應用特有的 secret 格式 — redaction 在 SDK 端執行，敏感資料不離開 client
- SDK 公開 API 設計
init / event / error / metric / flush / close 六個方法構成 SDK 的完整生命週期 — 跨平台共用相同 API 介面
- 四類事件的完整定義
Event / Error / Metric / Lifecycle 四類事件各自的語意、觸發時機和典型用途 — 分類是監控體系的統一語言
- 自架 vs 商業的判斷決策表
使用者數、網路範圍、功能需求、合規要求四個維度判斷該自架還是用商業方案
- 行為事件設計
事件命名規範、屬性設計、funnel 定義 — 行為分析的品質取決於事件設計的品質
- Refusal Rate
LLM 拒絕回答 prompt 的比例、是 production LLM 服務偵測對齊強度跟異常行為的常用訊號
- 部署光譜：從 BaaS 到自架的四條路徑
監控方案的部署選擇不是二元的 — BaaS + Serverless 和 PaaS 是完全自架和商業 SaaS 之間兩條常被忽略的中間路徑
- Flutter 平台適配
Isolate 安全、Platform channel 攔截、app lifecycle 事件 — Flutter SDK 的平台特殊考量
- Funnel Analysis
使用者在哪一步流失 — 從事件序列計算每步轉換率、找出流失最嚴重的步驟、區分設計問題和技術問題
- JSONL 匯出與備份格式
JSONL 作為匯出和備份格式的設計 — 人類可讀、grep 友好、SQLite 損壞時的重建來源
- Redaction
說明在事件資料離開 client 之前把敏感欄位的值替換成遮罩或移除的機制
- Sentry 深入
Error tracking + performance monitoring + session replay 的架構 — Sentry 從 error-first 出發如何擴展到全面可觀測性
- Transport 安全
HTTPS / basic auth / 同區網也要加密的理由 — 監控資料在傳輸途中的保護機制
- 自動攔截機制
JS window.onerror / Flutter FlutterError.onError / Python sys.excepthook — 各平台攔截未捕獲例外的機制和限制
- 事件命名規範
namespace.action 格式的事件命名、命名一致性的工程價值、和商業方案命名慣例的對應
- 欄位設計原則
source 標明來源、data 自由欄位、v 版本演進 — 三個設計原則讓 schema 在不同階段都能使用
- Cohort Analysis
按共同特徵分群、比較不同群體的留存率和行為差異 — 從「平均值」到「誰在用、誰離開了」
- Cohort Analysis
說明把使用者按共同特徵分群、比較不同群組行為差異的分析方法
- Collector Access Control 實作
認證（誰在送資料）/ 授權（允許送什麼）/ access log（誰在什麼時候送了什麼）— collector 端的三層存取控制
- Firebase 套件
Crashlytics + Analytics + Remote Config 的整合 — Firebase 把 error tracking 和行為分析拆成獨立產品的設計取捨
- Python 平台適配
GIL 與 threading、atexit 可靠性、subprocess 監控 — Python SDK 的平台特殊考量
- Schema 版本演進策略
Backward compatible 的增量變更 — 新增欄位不改版、改名或改型別才改版、collector 同時支援多版本
- 查詢 API 設計
CLI grep 友好的 JSONL 結構 + HTTP 查詢 endpoint — 兩種查詢介面各自的適用場景和設計要點
- 商業方案的事件類型對應
Sentry / Crashlytics / GA4 / Datadog RUM 各自如何對應四類事件 — 理解商業方案的分類邏輯才能正確接入
- 攢批送出策略
flush interval / buffer size / flush on close 三個控制點決定事件何時離開 SDK — 平衡即時性和網路效率
- 斷網環境的監控與可觀測性
Self-hosted 監控（Prometheus + Grafana）、離線 log 收集（Loki / ELK）、不能 phone home 的告警、NTP 時間同步
- Attribution
使用者從哪來、哪個渠道帶來轉換 — last-touch / first-touch / multi-touch 歸因模型的差異和選擇
- Datadog RUM
全棧 APM 的 client-side 觀點 — client action 到 server trace 的完整鏈路追蹤
- Go 平台適配
Graceful shutdown、signal handling、HTTP server 自身監控 — Go SDK 和 collector 端共同面對的平台問題
- RFM
說明用 Recency / Frequency / Monetary 三個維度把使用者分成可操作群組的分群方法
- Rule engine 設計
條件 → 動作 → 模板的三段式規則結構 — 讓 collector 從被動儲存變成主動回應
- 去識別化策略
IP 截斷 / user agent 簡化 / stack trace 路徑清理 / session UUID — 四種去識別化技術的適用場景和實作方式
- 從需求推導「該收集哪些事件」
從 debug 需求、行為分析需求、效能需求、合規需求四個方向推導事件收集策略 — 避免「什麼都收」和「什麼都不收」
- 跟 OpenTelemetry 的 schema 差異對照
自架 event schema 和 OTLP 的設計差異 — 為什麼 client-side 監控用簡化 schema、什麼時候切換到 OTLP
- 離線 buffer 與重試
網路不可用時的事件保存策略 — FIFO 丟棄、本地 persistence、恢復後補發的取捨
- 服務掛了怎麼自動知道：從肉眼盯到主動告警
不想每次都手動 systemctl 檢查服務死活、想讓機器在 service 掛掉時主動推播通知、或擔心整台機器當掉沒人知道時回來讀
- Error Fingerprint
從 error 事件的 type、normalized message、stack trace 計算 hash，把相同根因的 error 歸為同一 error group
- 事件枚舉與補齊檢查
從操作盤點系統性地推導出完整的事件清單 — 四類補齊檢查確保沒有遺漏、粒度判準確保每個事件只記一個事實
- A/B Test 的統計基礎
假設檢定、樣本量計算、多重比較校正 — A/B test 不只是「比較兩個數字」，統計方法決定結論是否可靠
- GDPR 最小化原則的工程落地
資料最小化、目的限制、儲存限制 — GDPR 三個核心原則在監控系統的工程實作方式
- Mixpanel / Amplitude
行為分析專用方案 vs 通用監控的差異 — Mixpanel 和 Amplitude 的 funnel / cohort / retention 分析能力
- SDK redaction helper
在事件離開 SDK 前移除敏感資訊 — 預設 redaction rule 處理常見 pattern，自訂 rule 處理業務特定的 secret
- 規模演進
可插拔 Storage Backend 架構 — SQLite 預設、PostgreSQL 觸發切換、時間序列 DB 長期演進
- 跨平台 timestamp 一致性
時區、精度、clock drift — 不同平台產生的 timestamp 在 collector 端需要能正確比對和排序
- Backpressure
下游處理能力不足時向上游回傳「慢下來」訊號的流量控制機制 — 監控系統中 collector 用 HTTP 429 向 SDK 傳遞背壓
- 功能分層與 Backend 選擇
SQLite 層和 PostgreSQL 層各自承載哪些功能 — 分界線是查詢模式而非資料量、觸發升級的是功能需求而非規模成長
- 前端感測器設計
什麼行為值得埋感測器、每類感測器的實作方式、取樣策略和效能影響 — 和 auto-intercept 的被動攔截互補
- 動機驅動的事件設計
Debug / 商業 / 資安 / 效能四個動機各自需要什麼事件 — 從「為什麼收」反推「收什麼」和「什麼階段啟用」
- 推薦系統概論
Collaborative filtering / content-based / 混合方法 — 推薦系統的三種基本架構和各自的資料需求
- 監控資料洩漏的 Threat Model
監控系統本身是攻擊面 — 四個威脅場景（傳輸竊聽 / 儲存入侵 / endpoint 濫用 / 內部越權存取）的風險評估和防護措施
- Sampling
在事件產生階段按比例丟棄部分事件降低管線負載 — 分靜態取樣（config 固定比例）和動態取樣（背壓觸發自動降低）
- 查詢消費模式
Debug / Alerting / 產品決策 / 安全審計 / 效能監控 — 五種查詢場景各需要什麼事件、什麼欄位、什麼查詢模式
- 感測器生命週期管理
產品生命週期的五個階段各啟用什麼感測器 — feature flag 整合、取樣率動態調整、感測器開關的可觀察性
- RFM 分群
Recency / Frequency / Monetary 三維度的使用者分群 — 從行為事件計算 RFM 分數、定義使用者群體、驅動差異化策略
- Client-side SDK 認證的根本限制
嵌在 client 端的 credential 必然可被提取 — 認清 architecture 天花板後的多層緩解策略，從 origin 驗證到 device attestation
- Rate Limiting
限制每個 client 在單位時間內可送出的事件數量 — 防止單一 SDK bug 或偽造流量消耗整個 collector 的處理能力
- DevOps Dashboard 設計
Collector 和 SDK 是否健康 — 日常監控的服務狀態卡、吞吐量曲線、儲存用量，以及告警觸發後的排障視圖
- 從 collector 資料做基礎 funnel 分析
SQLite 層能做什麼程度的 funnel、PostgreSQL 層提供什麼進階能力、JSONL 匯出後的臨時分析
- Developer Dashboard 設計
Bug 在哪、多嚴重、怎麼重現 — Error 列表和趨勢的日常監控、Session 回放和 Stack trace 的深入 debug
- 中台 Dashboard 設計
使用者怎麼用、在哪流失、怎麼讓他們回來 — 營運和行銷的日常指標監控與深入分析視圖，全部需要 PostgreSQL 層
- Ingestion Scaling
四層防線應對 ingestion 端的流量擴展 — SDK 取樣、Collector 背壓、水平擴展、Queue 解耦
- SQLite Backend 效能基準
寫入吞吐 / 查詢延遲 / 資源消耗的量化預期 — 不同硬體環境下 SQLite 能撐多少、邊界在哪、怎麼實測
- 無 SSH 環境的監控與告警
無 SSH 環境沒辦法裝 agent、沒辦法串 log pipeline，用外部 HTTP check、錯誤追蹤服務與效能基線建立最低成本的監控能力
- 讀寫分離與查詢擴展
Monitor 在 PostgreSQL 層之後的讀寫競爭問題、Read Replica 分離策略、CQRS 判讀訊號
- Container 部署設計
Docker 部署 collector 的設計 — SQLite 在 overlay filesystem 的 I/O 考量、volume mount、graceful shutdown、資源限制
- 端到端資料完整性
從 SDK 到 storage 的資料損失地圖 — 每個環節的損失類型、控制策略、完整性指標、被自己 SDK DDoS 的防護
- Error Fingerprint 與去重分群
把大量 error 事件歸組成可管理的 issue 列表 — fingerprint 演算法、message normalization、error_groups 表設計、自架方案的務實邊界
- 監控資料的雙重用途：行為分析與訊號治理
同一份 event data 如何同時服務行為分析（funnel / cohort / attribution）和訊號治理（cardinality / cost / signal governance）— 格式交叉、治理衝突與分流架構
- LLM Service 偵測訊號覆蓋
production LLM 服務的 detection 訊號設計：tool call 異常模式、prompt injection 觸發徵兆、abuse 跟濫用模式、跟既有 detection-coverage 框架的接合
- TUI 監控工具：btop、htop、k9s 的遠端使用與刷新率調校
全螢幕 TUI 監控工具在遠端 SSH 情境的使用：htop 進程操作、btop 多資源儀表板、k9s 管 Kubernetes，以及慢速連線下刷新率與頻寬的取捨。
- 終端機圖形化工具總覽：遠端操作下的 TUI、文字圖表與多工器
在純文字終端機裡用 ASCII 與製圖字元做出監控儀表板、資料圖表與多視窗操作的工具總覽，並針對 SSH 伺服器、手機平板、低頻寬三種遠端情境給出選型判讀。