可預期突發

事前知道流量會增加，有時間準備。

可預期突發的應對核心是容量預備 — 活動前擴容、活動後縮回。

容量預備的前置時間與 collector 在活動前要準備的項目

可預期突發能事前準備，而準備要從活動前多久開始，由各準備項目的產出交給誰、它發現的狀況要多久修好決定。容量估算、配額申請、壓力測試（Load Test）、故障演練（Game Day）與預先擴容各排在活動前幾天、為什麼排在那裡，以及準備時間不夠時被壓縮掉的是什麼，在 9.11 高峰事件準備〈T-90 → T-0 準備時程〉與〈Event tier 分級〉。容量估算有兩種算法：平常的流量乘上歷史倍率、再加安全係數，在 峰值估算〈用歷史倍率階梯推可預期峰值〉與〈安全係數的數學根據在飽和曲線〉；從業務預估經換算鏈與三點估計算出各層台數，連同活動的預算，在 預知的大流量要加多大、編多少預算：從業務預估到擴容規格與費用區間的換算鏈、給決策者與會計的數字，以及每次活動之後的校準〈從業務預估到台數：換算鏈、換算係數的來源與三點估計〉。

套到 collector 上，活動前要準備的是三件事。接收端的台數與配額，從活動期間 SDK 送出的事件量估，事件量跟著使用者數與每人觸發的事件數變。壓力測試除了量接收端，也要量寫入儲存層的處理量：直接寫 PostgreSQL 的架構，背壓（Backpressure）常常先從寫入那一段出現（規模分級應對表〈Tier 3：大型（10000-100000 events/sec）〉）。SDK 端的動態取樣與事件優先級，在活動前設好觸發條件並演練一次；SDK 從 collector 回傳的 429 判斷要不要降低取樣率（降級策略〈觸發條件〉）。這一項的前置時間取決於設定怎麼送到客戶端：取樣設定由遠端設定下發時，活動前幾天改得到；編在 app 裡時，改設定要發新版，設定要比活動提早至少「發版審查加上使用者更新」所需的時間改好（新版本的流量峰值在推送後 24-48 小時，見上面〈可預期突發〉的來源表）。

配額申請被拒、或壓測測出的寫入瓶頸在活動前修不完時，collector 有兩種處置。一是超出容量的事件量由 queue 先接住、事後追趕（Queue 緩衝），代價是排在 queue 裡的事件在活動期間看不到；錯誤與延遲這類要即時看的事件，依事件優先級走不排隊的路徑。二是由 SDK 降低取樣率，減少送進來的事件。

不可預期突發

事前不知道流量會增加，只能靠架構設計吸收。

依賴恢復時積壓請求一起到達的第二波湧入，以及它轉成停在失效的條件，見 9.16 負載超過容量時服務的表現。

不可預期突發的應對核心是降級 — 系統在超載時自動犧牲非核心功能，保住核心功能。

監控系統的 error storm

Error storm 是監控系統特有的突發場景：被監控的 app 出了 bug，每個受影響的使用者都在送 error 事件。如果有 10 萬使用者同時遇到同一個 bug，collector 瞬間收到 10 萬筆 error 事件。

Error storm 的矛盾：error 事件是 debug 最需要的資料，但 storm 時的大量 error 可能塞滿 collector 的接收佇列，collector 開始回 429 或丟掉資料。處理策略是保留前 N 筆完整 error（含 stack trace）、後續的 error 只計數不存原始資料。第一筆 error 的 stack trace 足夠 debug，後續的 10 萬筆只是確認影響範圍。

下一步路由

• 突發時的降級策略 → 降級策略
• 不可預期突發依來源（真人需求、應用層濫用流量、體積型攻擊）分流的處置，以及負載卸除、等候室與流量清洗 → 9.15 無預警瞬時大流量：流量來源辨識、擴展緩衝、請求優先等級、准入控制、體積型攻擊與退路
• Queue 做 burst 緩衝 → Queue 緩衝
• 可預期突發的擴容規格與預算怎麼從業務預估算出來、做成給決策者與會計的數字 → 預知的大流量要加多大、編多少預算：從業務預估到擴容規格與費用區間的換算鏈、給決策者與會計的數字，以及每次活動之後的校準
• 不同規模的應對方案 → 規模分級應對表

動態取樣

流量超過閾值時自動降低取樣率。平時 100% 收集、超載時降到 10% — 仍有資料可分析，只是精度下降。

觸發條件

取樣的公平性

動態取樣不應該只丟新事件保留舊事件（FIFO 丟棄）— 這會讓取樣偏向「burst 初期的事件」。更好的策略是隨機取樣（每個事件有 sampling_rate 的機率被保留），讓取樣後的資料仍然能代表整體分佈。

取樣後的事件帶 _sampling_rate 欄位，分析時用 1 / sampling_rate 做加權還原。

事件優先級

不同事件類型的 debug 價值不同。超載時先丟價值低的，保留價值高的。

優先級的判斷原則：「這個事件丟了、要花多少時間從其他來源補回相同資訊」。Error 的 stack trace 丟了幾乎不可能從其他來源補回；event 的 click 計數可以從後續資料的趨勢推測。

功能降級

非核心功能暫時關閉或降低更新頻率，把資源留給核心功能。

降級的觸發和恢復應該自動化 — 用 collector 的內部 metric（goroutine pool 使用率、寫入延遲）作為訊號。

聚合前移

讓 SDK 端做預聚合，減少送到 collector 的事件數量。

平時：每次 click 送一筆 button.clicked 事件 → 100 次 click = 100 筆事件。 聚合前移：SDK 累積 10 秒內的 click → 送一筆 button.clicked 帶 count: 17 → 100 次 click = ~10 筆事件。

聚合前移犧牲的是事件粒度（失去每次 click 的精確時間戳），換取的是 10x 的事件量減少。適用於高頻但單筆資訊量低的事件（click、scroll、mousemove）。

聚合前移的觸發也可以是動態的 — collector 回 429 時 SDK 自動啟用聚合前移，流量恢復後關閉。

下一步路由

• 突發流量的分類 → 突發流量的分類
• Queue 做更大規模的緩衝 → Queue 緩衝
• 不同規模的應對方案 → 規模分級應對表
• 背壓和 rate limit 的基礎 → 模組三 流量管控

為什麼不直接寫 DB

直接寫 DB（SQLite / PostgreSQL）的問題是 ingestion 速度被 DB 寫入速度限制。DB 寫入慢（鎖定、WAL flush、索引更新）時，HTTP handler 的 goroutine 等在 Storage.Store() 上 — goroutine 積壓 → 記憶體上升 → 最終 OOM 或 response timeout（記憶體先到上限是程序終止，用戶端的逾時先到是無回應，判斷標準與監控訊號見 9.16 負載超過容量時服務的表現）。

Queue 的解決方式是把「接收」和「寫入」分開：接收端只做 JSON 驗證 + 寫入 queue（微秒級），處理端從 queue 讀取 + 寫入 DB（毫秒級）。接收端的吞吐量不再受 DB 限制。

取捨

自用工具場景不需要 queue — 單 collector + SQLite 的直接寫入足夠。Queue 的引入條件是「直接寫 DB 的背壓開始頻繁觸發」。

候選類型

選型判斷

已有 Redis → 先用 Redis Streams（零新增元件）。Go 為主的技術棧 → NATS JetStream（Go 原生 client、單 binary 部署）。需要跨消費者群組或日誌級持久化 → Kafka。

引入條件

Queue 的引入是架構複雜度的顯著上升（一個元件變三個）。明確的觸發條件：

• 背壓（429 回應）頻繁觸發（每天 > 100 次）且持續（不只是瞬間 burst）
• 寫入延遲的 P95 超過 500ms（DB 成為瓶頸）
• 需要多個 consumer（同一批事件要送到不同的下游 — analytics DB、alert engine、archive）

監控系統的 Queue 架構

1SDK ──→ Collector (ingestion only)
2           │
3           ├─ 驗證 JSON Schema
4           ├─ Redaction
5           └─ 寫入 Queue
6                 │
7                 ├── Worker A → PostgreSQL（主 storage）
8                 ├── Worker B → 降採樣 → Summary tables
9                 └── Worker C → Rule engine → Alert

Collector 瘦身為 ingestion-only — 只做接收、驗證、redaction 和寫入 queue。Storage 寫入、降採樣、rule engine 都移到 worker 群。Collector 的吞吐瓶頸從 DB 寫入變成 queue 寫入（queue 的寫入吞吐通常是 DB 的 10-100 倍）。

下一步路由

• 突發流量的分類 → 突發流量的分類
• 降級策略 → 降級策略
• 規模分級的完整應對 → 規模分級應對表
• Queue 的選型和操作實務 → backend 非同步佇列

四級分級

Tier 1：自用級（< 100 events/sec）

1SDK ──→ Collector (單 binary + SQLite)

Tier 1 的假設是峰值流量不超過 SQLite WAL mode 的寫入能力（每秒數千筆）。自用場景下這個假設幾乎永遠成立。

Tier 2：中型（100-10000 events/sec）

1         ┌─ Collector A ──→ PostgreSQL
2SDK ──→ LB ─┤
3         └─ Collector B ──→ PostgreSQL

Tier 1 → Tier 2 的觸發：SQLite 的 database is locked 頻繁出現，或 dashboard 的聚合查詢需要 PostgreSQL 的能力。

Tier 3：大型（10000-100000 events/sec）

1         ┌─ Collector A ─┐
2SDK ──→ LB ─┤               ├─→ Queue ──→ Worker 群 ──→ PostgreSQL
3         └─ Collector B ─┘

Tier 2 → Tier 3 的觸發：直接寫 PostgreSQL 的背壓頻繁觸發（即使有多個 collector 寫入）。

Tier 4：商業網站級（> 100000 events/sec）

1SDK ──→ CDN/Edge ──→ LB ──→ Collector 群 ──→ Kafka ──→ Worker 群 ──→ 分層 DB
2                                                                      ├─ 即時查詢 DB（ClickHouse / TimescaleDB）
3                                                                      └─ 歸檔 DB（S3 + Athena）

Tier 3 → Tier 4 的觸發：Kafka 單 cluster 的吞吐不夠、或查詢需要跨日誌級的時間序列分析。

多數自架開源工具不需要超過 Tier 2。Tier 3 和 Tier 4 是商業 SaaS 的領域。

規模遷移路徑

每一級的遷移成本遞增。Tier 1 → 2 是 config change 級、Tier 2 → 3 是架構重構級、Tier 3 → 4 是團隊級。選擇起始 tier 時選最低的足夠 tier — 過早引入高 tier 的複雜度是浪費。

下一步路由

• 流量管控的四種機制 → 模組三 流量管控
• 容量預備和壓力測試 → 模組五 容量規劃
• Collector 的可插拔 storage 架構 → monitoring 模組四 規模演進
• Queue 的選型 → backend 非同步佇列