"Monitoring"
- 4.0 服務端監控的分層：容器與程序的自檢、服務網路內的探測、元件指標、應用層訊號、告警規則與分送、告警鏈的監看與使用者路徑的合成監控
以每一層監控檢查的對象、看不到的範圍與接手的那一層，把服務端監控串成一條監控鏈，以及拿它盤點一個服務時怎麼判讀缺口的性質（檢查範圍、位置、讀取與訊號失真），涵蓋自架主機、Kubernetes 與雲端託管的情形；使用者路徑那一層另寫合成監控與真實使用者監測的差別，以及盤點時各種缺口的補法
- 4.0.1 監控鏈事前偵測不到的異常：業務結果、資料正確性、到期事件、排程與背景工作、備份、安全、第三方依賴與成本的監看
監控鏈各層都正常時仍會發生的幾類異常：業務停了而程式回應正常、資料寫錯、TLS 憑證與網域到期、排程工作與佇列消費端沒跑、備份還原不回來、以帳號正常操作進行的攻擊、第三方業者停掉與帳單失控，各自要先定義的預期、檢查它的規則與承接的專章
- 4.0.2 以監控鏈盤點單機短網址服務：各層現有的監控、缺口的性質與補法，以及監控鏈事前偵測不到的異常
把一台主機上以 Docker Compose 跑的短網址服務現有的每一種監控放進監控鏈的各層，逐層判讀還開著的缺口屬於檢查範圍盲區、位置盲區、讀取缺口還是訊號失真，各自的補法，以及補上失效域以外的觀察者之前，主機整台停掉時沒有任何一層會通知的情形；另逐類查業務結果、資料正確性、安全、成本、到期事件與備份
- 4.0.3 以監控鏈盤點 Kubernetes 上的電商 checkout：叢集內的監控、託管資料庫與第三方金流各自的失效域，以及佇列消費端與外部依賴的缺口
把一個跑在託管 Kubernetes 上、有訊息佇列消費端、託管資料庫與第三方金流的電商 checkout 現有的監控放進監控鏈的各層，逐層判讀缺口與補法；另寫付款服務的 readiness 納入金流業者時對付款回呼的影響、失效域從主機換成叢集與雲端帳號之後觀察者要放在哪裡，以及業務結果、對帳、到期事件、消費端、備份、安全、第三方依賴與成本的逐類盤點
- 4.0.4 以監控鏈盤點交易撮合系統：觀察者讀數字的位置、沒有新委託時分辨市場安靜與路徑停住、分段量測延遲，以及委託序號、帳戶部位的對帳與其他監控鏈事前偵測不到的異常
把一個交易撮合系統的監控放進監控鏈的各層判讀缺口：撮合引擎單一執行緒時觀察者為什麼要從輸出日誌讀數字、沒有新委託時怎麼分辨市場安靜還是處理路徑停住、委託延遲怎麼依段量測與時鐘同步的前提、依序日誌多數節點與同一可用區的失效域，以及輸出序號的斷號、帳戶部位與行情資料的一致性這類監控鏈事前偵測不到的異常
- 邊緣安全事件的判讀與監控：處理層與事件欄位、背景流量的分類、處置留下的紀錄、監控分級、從事件回寫規則
網站放在 CDN 或 WAF 後面、手上有一個事件頁或一份匯出的事件紀錄，要分出背景掃描、爬蟲與針對這個網站的請求，或決定哪些事件要即時告警時，先從這裡確認這組文章涵蓋哪些判斷、各篇目前的發佈狀態
- Meta Pixel 與 Conversions API：廣告平台轉換追蹤的瀏覽器端與伺服器端
Meta Pixel 在頁面上送出的標準事件與它的資料消費者、瀏覽器端事件被攔截的路徑、Conversions API 從伺服器補送同一批事件的必填欄位，以及兩路並送時以 event_id 去重與用 Test Events 驗證的方式
- 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 服務偵測對齊強度跟異常行為的常用訊號
- Google Tag Manager：追蹤碼的部署層、資料層約定與發布治理
GTM 容器在頁面上承擔的部署責任、資料層作為前端與行銷之間的事件約定、預覽模式與版本發布的驗證方式、自訂 HTML 代碼帶來的安全與效能成本，以及伺服器端代碼管理改變的資料路徑
- 部署光譜：從 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 在不同階段都能使用
- Meta Pixel 實測頁：在瀏覽器裡觀察 fbq 呼叫、送出的請求與寫下的 cookie
在這一頁按按鈕載入 Meta Pixel、送 PageView、ViewContent 與帶 eventID 的 Purchase，並用頁面上的面板對照每個呼叫送出的請求參數，以及 _fbp 與 fbclid 帶出的 _fbc cookie
- 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 — 平衡即時性和網路效率
- Google Tag Manager 實測頁：在瀏覽器裡觀察容器載入、資料層事件與代碼送出的請求
在這一頁按按鈕載入 GTM 容器、往資料層推 purchase 事件，並用頁面上的面板對照 window.dataLayer 的內容、容器載入的代碼與它們送出的請求
- 斷網環境的監控與可觀測性
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、恢復後補發的取捨
- 用 Playwright 擷取追蹤碼請求：擷取方式、記錄欄位與各次結果
以 Playwright 操作 Meta Pixel 與 GTM 實測頁、記錄各家 script 實際送出的請求與 cookie 的方式，結果檔記錄的欄位與它們的用途，擷取用的測試帳號，以及每一次擷取觀察到的事件請求形式、cookie 與請求參數的對應、無頭瀏覽器下的差異與 script 自動送出的事件
- 服務掛了怎麼自動知道：從肉眼盯到主動告警
不想每次都手動 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 端需要能正確比對和排序
- 追蹤資產的歸屬：Meta、GTM 與 GA4 的擁有層級、權限分級與移交方式
Meta Pixel 的資料集、GTM 容器與 GA4 資源（property）各自屬於哪一層的擁有者，三家的權限怎麼分級，哪些資產能換到另一個擁有者底下，以及公司自營、委託代理商、換代理商與事業轉手時的歸屬安排
- 小型服務的兩到三台主機配置：第二台與第三台主機的用法、監控主機的位置與連線、兩台主機互相監看，以及雲端業者負責的範圍
一台主機的服務擴充到兩到三台時，每一台放什麼：第二台給監控、給應用程式的副本或給資料庫各自換到什麼與前提，與第三方心跳監看服務的比較，監控主機放在另一個業者或地端時經 VPN 讀取、連線中斷的誤判，兩台主機互相監看的條件，第三台給資料庫或兩台應用主機搭配託管資料庫，備份的位置，以及加主機也換不到、由雲端業者或入口設定處理的故障與攻擊
- ntfy：推送通知服務怎麼運作、公共站 vs 自架
用 ntfy 把機器的告警推到手機、想搞懂它是誰維護的開源服務、topic 的安全模型、以及該用公共站還是自架時回來讀
- Backpressure
下游處理能力不足時向上游回傳「慢下來」訊號的流量控制機制 — 監控系統中 collector 用 HTTP 429 向 SDK 傳遞背壓
- 功能分層與 Backend 選擇
SQLite 層和 PostgreSQL 層各自承載哪些功能 — 分界線是查詢模式而非資料量、觸發升級的是功能需求而非規模成長
- 前端感測器設計
什麼行為值得埋感測器、每類感測器的實作方式、取樣策略和效能影響 — 和 auto-intercept 的被動攔截互補
- 動機驅動的事件設計
Debug / 商業 / 資安 / 效能四個動機各自需要什麼事件 — 從「為什麼收」反推「收什麼」和「什麼階段啟用」
- 推薦系統概論
Collaborative filtering / content-based / 混合方法 — 推薦系統的三種基本架構和各自的資料需求
- 監控資料洩漏的 Threat Model
監控系統本身是攻擊面 — 四個威脅場景（傳輸竊聽 / 儲存入侵 / endpoint 濫用 / 內部越權存取）的風險評估和防護措施
- 多容器服務的存活監看：容器健康檢查、外部探測與指令列查詢的分工
說明一組用 Compose 跑的多容器服務怎麼回答「每個服務還活著嗎」：容器健康檢查、從另一個容器發請求的外部探測、SSH 進主機時用的查詢腳本各自看得到與看不到的範圍，外部探測工具（Gatus、Uptime Kuma）的選擇、TCP 檢查與經過負載平衡的檢查的限制，以及監看工具自己掛掉時怎麼發現
- 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 匯出後的臨時分析
- First-party Cookie（第一方 cookie）
盤點網站寫下的識別碼 cookie、比對追蹤碼的 cookie 期限，或判斷某個 cookie 受不受瀏覽器的第三方 cookie 限制時
- Developer Dashboard 設計
Bug 在哪、多嚴重、怎麼重現 — Error 列表和趨勢的日常監控、Session 回放和 Stack trace 的深入 debug
- Headless Browser（無頭瀏覽器）
用 Playwright 或 Puppeteer 測追蹤碼、分析報表裡的機器流量，或自建統計與商業追蹤碼的訪問數對不上時
- 中台 Dashboard 設計
使用者怎麼用、在哪流失、怎麼讓他們回來 — 營運和行銷的日常指標監控與深入分析視圖，全部需要 PostgreSQL 層
- Autocapture（自動事件收集）
盤點網站實際送出哪些事件與內容、報表裡出現網站沒有呼叫過的事件，或在手動埋點與自動收集之間取捨時
- Ingestion Scaling
四層防線應對 ingestion 端的流量擴展 — SDK 取樣、Collector 背壓、水平擴展、Queue 解耦
- SQLite Backend 效能基準
寫入吞吐 / 查詢延遲 / 資源消耗的量化預期 — 不同硬體環境下 SQLite 能撐多少、邊界在哪、怎麼實測
- 單機 Compose 的最小監控堆疊：各 exporter 的掛載、讀取設定與 Grafana 佈建
以 Docker Compose 在一台主機上接起 Prometheus、Alertmanager、Grafana 與主機、容器、資料庫、快取、入口各層的 exporter：每個掛載與旗標為什麼需要、讀取設定與規則的放法、Grafana 以檔案佈建、連接埠與帳號的權限，以及讀取對象全部 UP 時仍可能漏掉的監控
- 無 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 表設計、自架方案的務實邊界
- 第三方心跳監看與外部探測服務：挑選條件、healthchecks 的 ping 與 /fail、Alertmanager 的接法與演練
以第三方服務當作監控主機失效域以外的觀察者：心跳監看服務的挑選條件與送出的告警資料留在哪裡，healthchecks 的 ping 網址、週期與寬限、/fail 與自架和託管版的回應差異，Alertmanager 送心跳與送失敗通知的 receiver 與路由順序、驗收與暫停，停掉 Alertmanager 的演練，以及外部探測服務的挑選條件
- 4.26 單機容器服務的流量與資源監控：各層的訊號、Prometheus 與 exporter、監控所在層的盲區
健康檢查之外的流量與資源監控：入口、應用程式、容器、主機與資料庫等服務內部各層的訊號從哪裡收、用哪一個 exporter，Prometheus 加 exporter、單一 agent、開箱即用工具與臨時查看指令的取捨，單次取樣與時間窗的差別，監控裝在虛擬機裡時看不到主機的 CPU 負載、看到的磁碟要分清是哪一顆，以及每接上一個來源的驗收與偵測容器停止的寫法；cAdvisor 與 node_exporter 在 OrbStack 上實測過
- 4.27 主機過載時的監控告警：可用與變慢分開判斷、依原因抑制、監控自身的等待
多個服務共用一台主機而主機過載時，各服務的探測與告警會一起失敗：可用性與延遲分成兩個判斷的寫法、間歇的條件怎麼持續成立、以主機飽和抑制各服務變慢的規則與它的取捨、以合成告警驗證抑制、抑制藏起各服務受影響程度的差別、探測與 Prometheus 自己也在等 CPU 時的訊號，以及讓監控不比服務先失效的資源隔離；以一次開發環境的過載為例
- 4.28 單台主機的監控盲區與失效域以外的觀察者：主機停機、使用者路徑中斷與告警鏈中斷，心跳監看與外部探測各自回答的問題與位置，以及與內部探測並排的判讀
服務與監控放在同一台主機時監控結構上看不到的故障：主機整台停掉、使用者到主機的路徑中斷、告警鏈停掉與通知送不出去；從失效域以外送出訊號的心跳監看與外部探測各自回答的問題與成立條件，觀察者由第三方服務、另一個失效域的主機（含兩台主機互相監看）或另一個業者的排程平台提供時的差別，以及心跳監看、外部探測與主機內部探測並排時的判讀
- 監控資料的雙重用途：行為分析與訊號治理
同一份 event data 如何同時服務行為分析（funnel / cohort / attribution）和訊號治理（cardinality / cost / signal governance）— 格式交叉、治理衝突與分流架構
- LLM Service 偵測訊號覆蓋
production LLM 服務的 detection 訊號設計：tool call 異常模式、prompt injection 觸發徵兆、abuse 跟濫用模式、跟既有 detection-coverage 框架的接合
- Synthetic Monitoring（合成監控）
要知道使用者從外面連不連得到服務、或分不清某個「外部探測」從哪裡發出時，查合成監控以排程的請求模擬使用者的做法、探測端的位置怎麼決定它量得到什麼，以及它與真實使用者監測的差別
- White-box and Black-box Monitoring（白箱與黑箱監控）
分不清一個監控是從外部行為判斷還是讀取內部狀態、或把「黑箱探測」當成一定站在服務以外的觀察者時，查白箱與黑箱監控各回答什麼問題、各自看不到什麼，以及黑箱為什麼不等於在失效域以外
- Step Change（步階變化）
判斷一個指標或一項設定的改變能不能從量測的趨勢預測、要用趨勢外推還是跟基準比對才偵測得到時，區分步階變化與逐步累積的變化
- 監控案例庫的來源與預期案例：JSONL 查詢效能、寫入 buffer、SDK 離線緩衝、跨平台時間戳、錯誤去重、遮罩誤判、聚合查詢掃描量
想知道監控案例庫收錄哪一類案例、案例從哪裡來，或想先看實作 SDK 與 Collector 時預期會遇到哪些狀況、各自在什麼條件下出現時讀
- TUI 監控工具：btop、htop、k9s 的遠端使用與刷新率調校
要在遠端 SSH 用全螢幕 TUI 看進程與資源（htop／btop／k9s）、或慢速連線下要調刷新率省頻寬時回來讀
- 終端機圖形化工具總覽：遠端操作下的 TUI、文字圖表與多工器
要在純文字終端機湊出監控儀表板、資料圖表與多視窗操作、或在 SSH 伺服器／手機平板／低頻寬等遠端條件下挑對應工具時回來讀