可預期突發

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

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

預備清單

不可預期突發

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

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

監控系統的 error storm

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

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

下一步路由

• 突發時的降級策略 → 降級策略
• Queue 做 burst 緩衝 → Queue 緩衝
• 不同規模的應對方案 → 規模分級應對表

背壓 vs Rate Limit

背壓和 rate limit 都是流量控制，但觸發邏輯不同：

背壓在系統承載達到上限時才觸發，rate limit 在到達預設上限時就觸發（即使系統還有餘裕）。兩者互補：rate limit 防止單一來源打爆系統，背壓防止所有來源加起來打爆系統。

實作模式

有限 buffer + 回壓訊號

最常見的背壓實作是在處理管線中加一個有限容量的 buffer。Buffer 滿了代表下游處理不完，這時對新請求回傳「忙碌」訊號。

在 Go 的 HTTP server 中，buffer 可以是一個有限容量的 channel：

 1var ingestCh = make(chan Event, 10000) // 有限 buffer
 2
 3func handleIngest(w http.ResponseWriter, r *http.Request) {
 4    event := parseEvent(r)
 5    select {
 6    case ingestCh <- event:
 7        w.WriteHeader(http.StatusAccepted) // 202
 8    default:
 9        w.Header().Set("Retry-After", "5")
10        w.WriteHeader(http.StatusTooManyRequests) // 429
11    }
12}

Buffer 容量的選擇取決於下游的處理速度和可接受的記憶體用量。每個 event 約 1KB 時，10000 容量的 buffer 佔 ~10MB — 對多數服務來說可以接受。

HTTP 429 + Retry-After

HTTP 429 Too Many Requests 是標準的回壓訊號。Retry-After header 告訴 client 多少秒後重試。

Retry-After 的值可以是固定的（如 5 秒），也可以根據 buffer 的填充程度動態計算 — buffer 越滿、Retry-After 越長。

TCP 層的背壓

TCP 協議本身有背壓機制 — 接收端的 receive window 縮小時，發送端自動減速。但 HTTP 層的背壓比 TCP 層更精確，因為 HTTP 可以回傳語意化的狀態碼和 header，client 可以根據語意做出更智慧的回應（如優先重試 error 事件、放棄 event 事件）。

監控系統的應用

監控系統的 collector 是背壓的典型場景：多個 SDK 同時 flush 事件到 collector，collector 的寫入速度（SQLite / PostgreSQL）是瓶頸。

背壓鏈路：SDK flush → collector HTTP endpoint → 寫入 channel（有限容量）→ 寫入 goroutine → storage。Channel 滿時回 429，SDK 的離線 buffer 機制接手 — 事件暫存本地，等 collector 恢復後補發。

這個設計讓 collector 在高峰時不崩潰（有限 buffer 控制記憶體）、SDK 端不丟事件（離線 buffer 暫存）。代價是事件的到達有延遲（Retry-After 時間 + 補發時間）。

下一步路由

• 主動的流量限制 → Rate Limiting
• 依賴服務失敗時的防護 → 熔斷器
• 突發流量時的組合策略 → 模組七 突發流量

Memory 限制設計

觀察 baseline

在限制之前先觀察服務的真實記憶體使用。用 docker stats 看 container 的 MEM USAGE，跑至少 24 小時涵蓋日常操作和定期 job（降採樣、清理）。

Baseline 包含：

• 應用程式本身的 heap + stack
• Runtime 開銷（Go 的 GC metadata、JVM 的 metaspace、Python 的 interpreter）
• 內嵌資料庫的 page cache（如 SQLite 的 PRAGMA cache_size）
• HTTP server 的連線 buffer

設定 limit

1Memory limit = baseline peak × 1.5（安全係數）

安全係數 1.5 是經驗值 — 預留 burst 時的記憶體波動（如大 batch 的 JSON 反序列化、查詢結果集暫存）。安全係數太大浪費資源、太小在 burst 時 OOMKill。

OOMKill 排查

OOMKill 的症狀是 container 突然消失、沒有 application log。排查步驟：

1docker inspect <container> | jq '.[0].State.OOMKilled'
2# true = 被 OOM killer 終止
3
4dmesg | grep -i oom
5# kernel log 中的 OOM 記錄、包含被殺的 process 和當時的記憶體使用

OOMKill 後的處理：提高 memory limit，或找出記憶體使用異常的原因（memory leak、unbounded cache、大結果集查詢）。

不同 runtime 的記憶體特性

CPU 限制設計

--cpus vs --cpu-shares

CPU throttle 症狀

CPU throttle 不會 crash（和 OOMKill 不同）。症狀是延遲上升 — request 處理時間從 10ms 變成 100ms，因為 container 的 CPU time 被 cgroup 暫停。

1cat /sys/fs/cgroup/cpu/cpu.stat
2# nr_throttled: 被限制的次數
3# throttled_time: 累計被暫停的時間（奈秒）

I/O bound 的服務（如監控 collector — 主要時間花在 SQLite 寫入和 HTTP 收發）通常不需要嚴格 CPU 限制。CPU 只在查詢處理（JSON 反序列化、聚合計算）時短暫使用。

磁碟 I/O 考量

Overlay filesystem 的寫入放大

Docker 的 overlay2 storage driver 把 container 的寫入操作分層管理。每次寫入新檔案或修改檔案，overlay 在上層（upper layer）建立副本再修改（copy-on-write）。對 SQLite 這類頻繁 fsync 的嵌入式資料庫，overlay 層增加 20-40% 的寫入延遲。

Volume mount 繞過 overlay

把需要高 I/O 效能的目錄掛載為 host volume（-v /host/path:/container/path），寫入直接到 host 檔案系統、繞過 overlay。

適用 volume mount 的場景：

• 嵌入式資料庫的資料目錄（SQLite、BoltDB）
• 需要持久化的 log 檔案
• 大量小檔案寫入（cache 目錄）

不適用 volume mount 的場景（用 overlay 即可）：

• 暫存檔（處理完就刪）
• 只讀的設定檔（-v config:/config:ro，overlay 讀取開銷小）

tmpfs mount

記憶體中的暫存目錄，不寫磁碟。適合不需要持久化的高頻寫入（如 SDK 的離線 buffer、session 暫存）：

1docker run --tmpfs /tmp:size=64m ...

Health Check 設計

Container 的 health check 告訴 orchestrator「這個 container 是否正常運作」。Process 活著但 HTTP 不回應的場景（deadlock、資源耗盡）只靠 process 監控抓不到。

Dockerfile HEALTHCHECK

1HEALTHCHECK --interval=30s --timeout=5s --retries=3 \
2  CMD wget -q --spider http://localhost:8080/health || exit 1

Docker Compose healthcheck

1healthcheck:
2  test: ["CMD", "wget", "-q", "--spider", "http://localhost:8080/health"]
3  interval: 30s
4  timeout: 5s
5  retries: 3
6  start_period: 10s

start_period 是啟動寬限期 — container 啟動後前 10 秒的 health check 失敗不算。避免服務還在初始化時就被標記 unhealthy。

Kubernetes probe 對應

Docker 的 HEALTHCHECK 只有一種、等同 Kubernetes 的 livenessProbe。Kubernetes 的 readinessProbe 和 startupProbe 在 Docker 單機環境沒有對應物 — 它們是多 pod 場景下的流量控制機制。

下一步路由

• 監控 collector 的 container 部署實例 → Container 部署設計
• 服務探活與自動恢復 → DevOps 服務探活
• 負載平衡設計 → DevOps 負載平衡

待寫章節

• 反向代理的職責（TLS 終止、路由、負載分散、健康檢查）
• 負載分散演算法（round-robin / least-connections / IP hash / consistent hash）
• nginx 實務配置（upstream + health_check + 常見 gotcha）
• 健康檢查路由設計（被動 vs 主動、check interval、unhealthy threshold）
• 和模組二（水平擴展）的銜接：LB 是水平擴展的前提

跨分類引用

• → monitoring 模組四 Collector 架構：Collector 多實例部署時的 LB 設計
• → backend 部署平台：PaaS / container 的 LB 內建 vs 自管
• → infra 模組三：網路地基：ALB 掛在 public subnet、後端在 private subnet 的網路分層設計
• → infra 模組五：入口上 IaC：ALB 的 listener、target group、TLS 與健康檢查在 IaC 裡怎麼描述

兩個粒度

Per-client（每來源限速）

限制每個 client（by API key / IP / SDK instance）的請求速率。防止單一來源打爆系統。

自用場景下 per-client 限速的價值不高（只有自己的 SDK），但開源工具被多人部署後，per-client 限速防止某個失控的 SDK 影響其他來源。

Global（全局限速）

限制系統的總吞吐量。不管多少個 client，collector 每秒最多處理 N 個事件。

Global 限速是系統保護的最後一道線 — 即使每個 client 都在限速內，所有 client 加起來可能超過系統承載。Global 限速確保總量不超過系統能力。

演算法

Token Bucket

桶裡有固定數量的 token，每個請求消耗一個 token，token 按固定速率補充。桶空了就拒絕。

特點：允許短暫 burst（桶滿時一次消耗多個 token），但長期平均不超過補充速率。適合「允許偶爾的高峰但長期平均要在限制內」的場景。

Sliding Window

在固定的時間窗口（如 1 分鐘）內計數請求。超過上限就拒絕。窗口結束時計數重設。

特點：嚴格的速率限制（窗口內不會超過 N 個），但窗口邊界有突增風險（上一個窗口末尾 + 下一個窗口開頭各 N 個 = 瞬間 2N）。滑動窗口（sliding window log / counter）解決邊界問題但記憶體較高。

選擇

自架監控系統推薦 token bucket — 允許 SDK 的 flush burst（一次送 100 個事件是正常行為），但限制長期平均速率。

HTTP 429 + Retry-After

限速觸發時回 HTTP 429 Too Many Requests，帶 Retry-After header 和 rate limit 相關 header：

1HTTP/1.1 429 Too Many Requests
2Retry-After: 5
3X-RateLimit-Limit: 1000
4X-RateLimit-Remaining: 0
5X-RateLimit-Reset: 1719302400

SDK 收到 429 後觸發離線 buffer 暫存事件，Retry-After 秒後重試。

優先級豁免

某些請求不應被限速：

優先級的判斷依據是「這個事件丟了的代價」。Error 事件丟了影響 debug 能力，event 事件丟了影響行為分析精度 — 前者的代價更高。

下一步路由

• 被動的流量控制 → 背壓機制
• 依賴失敗時的快速失敗 → 熔斷器
• 不同工作負載的資源隔離 → Bulkhead 隔離
• Backend 的 rate limit 實作（middleware / Redis / 配額設計）→ Rate Limit 實作

動態取樣

流量超過閾值時自動降低取樣率。平時 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 的基礎 → 模組三 流量管控

待寫章節

• Stateless 設計原則（狀態放 DB / cache / 外部儲存、不放 process memory）
• Session 處理（sticky session / session store / JWT stateless）
• Shared storage 的選型（NFS / S3 / DB — 不同 workload 的適合方案）
• 擴展的觸發訊號和縮回條件
• 垂直擴展 vs 水平擴展的判斷（什麼時候加 CPU、什麼時候加實例）

跨分類引用

• ← devops 模組一 負載平衡：LB 是水平擴展的前提
• → monitoring 模組四 Collector：Collector 的 stateless 設計讓多實例可行
• → backend 資料庫：Shared storage 的 DB 選型

為什麼不直接寫 DB

直接寫 DB（SQLite / PostgreSQL）的問題是 ingestion 速度被 DB 寫入速度限制。DB 寫入慢（鎖定、WAL flush、索引更新）時，HTTP handler 的 goroutine 等在 Storage.Store() 上 — goroutine 積壓 → 記憶體上升 → 最終 OOM 或 response timeout。

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 非同步佇列

三狀態模型

Closed（正常）

所有呼叫正常通過。熔斷器記錄成功和失敗的計數。

Open（熔斷）

當失敗率或連續失敗次數超過閾值時，熔斷器進入 open 狀態。此後所有呼叫立即回傳錯誤，不實際呼叫外部依賴。

Open 狀態持續固定時間（如 30 秒），時間到後進入 half-open。

Half-open（探測）

允許少量呼叫（如 1 個）實際通過到外部依賴。如果成功 → 回到 closed；如果失敗 → 回到 open（重設計時器）。

Half-open 的目的是自動探測依賴是否恢復，不需要人工介入。

熔斷判斷條件

「失敗」的定義需要明確：HTTP 5xx 是失敗、4xx 通常不是（client 的問題）、timeout 是失敗、connection refused 是失敗。

熔斷時的 fallback

熔斷觸發後，呼叫端收到的是「快速失敗」而非逾時。呼叫端需要有 fallback 策略：

沒有 fallback 的依賴被熔斷 = 對應功能完全不可用。熔斷器保護的是「不讓不可用的功能拖垮整個服務」。

監控系統的應用

Collector 的 rule engine 在規則命中時可能呼叫外部服務（Slack webhook、HTTP POST 到 alert endpoint）。如果外部服務掛了，每個命中的規則都會等待逾時 — 大量規則命中時 goroutine 積壓。

熔斷器包在 rule engine 的「執行外部動作」環節：連續 5 次外部呼叫失敗 → 熔斷 → 後續規則命中不再嘗試外部呼叫、改寫本地 log → 30 秒後探測一次 → 外部服務恢復 → 恢復正常呼叫。

下一步路由

• 被動的流量控制 → 背壓機制
• 主動的速率限制 → Rate Limiting
• 不同工作負載的資源隔離 → Bulkhead 隔離

待寫章節

• 背壓機制（下游慢時上游怎麼減速）
• Rate Limiting（主動限制每個來源的請求速率）
• 熔斷器（依賴服務失敗時怎麼快速失敗而非拖慢自己）
• Bulkhead 隔離（不同工作負載的資源池隔離）

跨分類引用

• → monitoring 模組四 Collector：Collector 的 ingestion 防護是本模組的應用場景
• → devops 模組七 突發流量：突發流量時這四種機制怎麼組合使用
• → backend 可靠性：熔斷和 bulkhead 也是 backend 的可靠性設計元件

隔離什麼

服務中的共享資源是 bulkhead 的隔離對象：

實作模式

獨立 Goroutine Pool

Go 中用有限容量的 channel 模擬 goroutine pool：

 1var (
 2    ingestPool = make(chan struct{}, 100)  // ingestion 最多 100 goroutine
 3    queryPool  = make(chan struct{}, 20)   // query 最多 20 goroutine
 4    rulePool   = make(chan struct{}, 10)   // rule engine 最多 10 goroutine
 5)
 6
 7func handleIngest(w http.ResponseWriter, r *http.Request) {
 8    select {
 9    case ingestPool <- struct{}{}:
10        defer func() { <-ingestPool }()
11        processIngest(r)
12    default:
13        http.Error(w, "ingestion overloaded", http.StatusServiceUnavailable)
14    }
15}

Ingestion 的 100 個 goroutine 全部被佔用時，新的 ingestion 請求被拒絕（503），但 query 和 rule engine 的 goroutine 不受影響。

獨立 Connection Pool

資料庫連線池按工作類型分開：

1// driver name 依實際使用的 driver 而定（modernc.org/sqlite 用 "sqlite"、mattn/go-sqlite3 用 "sqlite3"）
2ingestDB := sql.Open("sqlite", "events.db")
3ingestDB.SetMaxOpenConns(10) // ingestion 專用
4
5queryDB := sql.Open("sqlite", "events.db")
6queryDB.SetMaxOpenConns(5)   // query 專用

SQLite 的特殊情況：SQLite 是檔案級鎖定，多個連線池打開同一個檔案時仍共享 write lock。連線池隔離在 SQLite 上主要隔離的是 Go 層的 goroutine 等待，不是 DB 層的鎖定。PostgreSQL 的連線池隔離則是真正的資源隔離。

容量分配

Bulkhead 的每個隔艙分配多少資源是設計決策。分配依據是「這個工作負載的優先順序和預期併發量」：

分配比例不需要精確 — 重點是每個隔艙有獨立的上限，而非共享一個無差別的總上限。

監控系統的應用

Collector 同時承載 ingestion（接收事件）、query（dashboard 查詢）和 rule engine（規則評估）三種工作。不隔離時，一個複雜的 dashboard 查詢（full table scan）可能佔住所有資料庫連線，讓 ingestion 的寫入也排隊等待。

Bulkhead 設計讓 ingestion 和 query 各自的過載互不影響：

• Ingestion 的 goroutine pool 滿了 → SDK 收到 429 → 離線 buffer 接手
• Query 的 goroutine pool 滿了 → dashboard 暫時顯示 loading → 不影響 ingestion
• Rule engine 的 goroutine pool 滿了 → 規則評估延遲 → 不影響事件接收和查詢

下一步路由

• 背壓的流量控制 → 背壓機制
• 依賴失敗的快速失敗 → 熔斷器
• 突發流量時的綜合策略 → 模組七 突發流量

四級分級

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 非同步佇列

待寫章節

• Health check endpoint 設計（什麼算健康、什麼算不健康、check 的深度）
• Liveness vs Readiness（活著 vs 準備好接流量 — Kubernetes 的兩種 probe）
• systemd watchdog + 自動重啟（WatchdogSec + Restart=on-failure）
• Process supervisor 的選型（systemd / supervisord / Docker restart policy）
• Graceful shutdown（收到 SIGTERM 後的清理流程）

跨分類引用

• → monitoring 模組四 Dashboard DevOps：DevOps dashboard 的服務狀態卡依賴 health check
• → backend 部署平台：部署平台的 health check 整合

待寫章節

• 流量模型建立（平均 / 峰值 / burst 的估算方法）
• 壓力測試工具和方法（k6 / wrk / locust — 測什麼、怎麼測、結果怎麼讀）
• 峰值估算（行銷活動的倍率、歷史峰值的安全係數）
• 成本模型（資源規格 × 使用時間 × 計費模式 — reserved / on-demand / spot）
• 規模拐點判斷（什麼訊號代表該擴容、什麼訊號代表可以縮容）
• 容器化資源設計（memory / CPU / 磁碟限制、overlay fs、health check）

跨分類引用

• → backend 效能容量：Backend 的效能基準和容量估算
• → devops 模組七 突發流量：突發流量的容量預備

待寫章節

• 單點故障盤點（服務實例 / DB / LB / DNS — 哪些掛了整個系統就掛）
• 冗餘設計模式（active-passive / active-active / multi-region）
• Failover 機制（自動 vs 手動、failover 時間、資料一致性）
• Disaster recovery 策略（RPO / RTO 目標、備份恢復演練）
• 高可用的成本（冗餘 = 至少 2x 資源成本 — 值不值得）

跨分類引用

• → backend 可靠性：Backend 的可靠性設計
• → devops 模組四 服務探活：探活是 failover 的觸發條件
• → Infra 核心服務上 IaC — Stateful 資源保護：multi-AZ 是 infra 層的可用區冗餘能力，本模組的 HA 策略（健康檢查、自動恢復、failover 機制）建立在這個能力之上
• → Infra 網路地基：跨可用區的 subnet 與 NAT 冗餘設計是 HA 的網路前提

待寫章節

• 突發流量的分類（可預期 vs 不可預期、持續時間和倍率）
• 降級策略（動態取樣、事件優先級、功能降級、聚合前移）
• Queue 緩衝（Kafka / NATS / Redis Streams 做 burst buffer）
• 規模分級應對表（自用 → 中型 → 大型 → 商業網站）

跨分類引用

• ← devops 模組三 流量管控：背壓和 rate limit 是突發應對的基礎元件
• → monitoring 模組四 Collector：Collector 的 ingestion scaling 是本模組的應用場景
• → backend 非同步佇列：Queue 的選型和操作實務
• → devops 模組五 容量規劃：預期突發的容量預備
• → 端到端資料完整性：被自己 SDK DDoS 的三種場景

使用模式是混合型：平時靠告警被動通知，收到通知後到 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 服務探活

待寫章節

• 計費模式理解（on-demand / reserved / spot / savings plan — 各自的承諾和折扣）
• Right-sizing（實際用量 vs 配置規格的差距 — 過度配置是最大的浪費來源）
• 成本監控和告警（每日帳單趨勢、異常支出告警、部門歸屬標記）
• 開發環境的成本控制（自動關機、共用環境、spot instance 用於 CI）
• 自架 vs 雲端的成本交叉點

跨分類引用

• → devops 模組五 容量規劃：容量規劃的成本面
• → infra 模組八 治理好習慣：成本歸因的 tagging 地基 — tag 在 IaC 裡強制長出來，這裡的部門歸屬與帳單拆分才有依據
• → monitoring 模組六 商業方案：監控 SaaS 的帳單也是成本管理的一部分

和其他系列的關係

Backend 教「服務怎麼設計」，DevOps 教「設計好的服務怎麼在 production 活下來」。

教學模組

學習路線