Rate-Limiting on Tarragonhttps://tarrragon.github.io/blog/tags/rate-limiting/Recent content in Rate-Limiting on TarragonHugo -- gohugo.iozh-TWTarragon (CC BY 4.0)Wed, 24 Jun 2026 00:00:00 +0000Rate Limitinghttps://tarrragon.github.io/blog/monitoring/knowledge-cards/rate-limiting/Wed, 24 Jun 2026 00:00:00 +0000https://tarrragon.github.io/blog/monitoring/knowledge-cards/rate-limiting/<p>速率限制（rate limiting）的通用概念見 <a href="https://tarrragon.github.io/blog/backend/knowledge-cards/rate-limit/" data-link-title="Rate Limit" data-link-desc="說明限流如何保護服務入口、下游依賴與租戶公平性">Backend 知識卡：Rate Limit</a> — 限制某個主體在一段時間內可使用的資源量。本卡聚焦監控系統中的具體實作：限制每個 client（API key / source.app）在單位時間內可送出的事件數量，保護 collector 不被單一 SDK 的 bug（事件風暴）或偽造流量消耗處理能力。可先對照 <a href="https://tarrragon.github.io/blog/monitoring/knowledge-cards/backpressure/" data-link-title="Backpressure" data-link-desc="下游處理能力不足時向上游回傳「慢下來」訊號的流量控制機制 — 監控系統中 collector 用 HTTP 429 向 SDK 傳遞背壓">backpressure</a>（全域的容量訊號）和 <a href="https://tarrragon.github.io/blog/monitoring/knowledge-cards/sampling/" data-link-title="Sampling" data-link-desc="在事件產生階段按比例丟棄部分事件降低管線負載 — 分靜態取樣（config 固定比例）和動態取樣（背壓觸發自動降低）">sampling</a>（SDK 端的主動降載）。</p> <h2 id="和-backpressure-的差異">和 backpressure 的差異</h2> <p>Rate limiting 和 backpressure 都限制流量，但保護的維度不同。Rate limiting 是 per-client 的配額機制 — 每個 API key 有獨立的速率上限，一個 client 超限不影響其他 client。Backpressure 是全域的容量訊號 — collector 的寫入 channel 滿時對所有 client 回 429，不區分來源。一個 client 的失控用 rate limiting 處理（隔離問題源），全域流量過大用 backpressure 處理（全體降速）。</p> <h2 id="可觀察訊號與例子">可觀察訊號與例子</h2> <p>Rate limiting 觸發的訊號是 collector 端對特定 API key 回 429 的次數上升、而其他 key 正常。典型場景：某個 SDK 版本有 bug 導致每秒產生 1000 筆事件 → per-key rate limiter 超過閾值 → 該 key 的後續 request 被回 429 → 其他 SDK 不受影響。</p> <h2 id="設計責任">設計責任</h2> <p>Rate limiting 承擔的設計責任是「在公平性和可用性之間取得平衡」。閾值設太低，正常的 burst flush（攢批後一次送出）會被誤觸；閾值設太高，失控的 SDK 要送很多筆才被擋。合理的閾值需高於正常 burst 的事件速率。</p> <h2 id="完整章節">完整章節</h2> <p>Per-SDK rate limiting 的實作 → <a href="https://tarrragon.github.io/blog/monitoring/04-collector/ingestion-scaling/" data-link-title="Ingestion Scaling" data-link-desc="四層防線應對 ingestion 端的流量擴展 — SDK 取樣、Collector 背壓、水平擴展、Queue 解耦">Ingestion Scaling</a>。Rate limiting 在 collector access control 中的角色 → <a href="https://tarrragon.github.io/blog/monitoring/07-security-privacy/collector-access-control/" data-link-title="Collector Access Control 實作" data-link-desc="認證（誰在送資料）/ 授權（允許送什麼）/ access log（誰在什麼時候送了什麼）— collector 端的三層存取控制">Collector Access Control 實作</a>。偽造流量場景下 rate limiting 和其他防護層的配合 → <a href="https://tarrragon.github.io/blog/monitoring/07-security-privacy/client-sdk-authentication/" data-link-title="Client-side SDK 認證的根本限制" data-link-desc="嵌在 client 端的 credential 必然可被提取 — 認清 architecture 天花板後的多層緩解策略，從 origin 驗證到 device attestation">Client-side SDK 認證</a>。</p>速率限制（rate limiting）的通用概念見 Backend 知識卡：Rate Limit — 限制某個主體在一段時間內可使用的資源量。本卡聚焦監控系統中的具體實作：限制每個 client（API key / source.app）在單位時間內可送出的事件數量，保護 collector 不被單一 SDK 的 bug（事件風暴）或偽造流量消耗處理能力。可先對照 backpressure（全域的容量訊號）和 sampling（SDK 端的主動降載）。

和 backpressure 的差異

Rate limiting 和 backpressure 都限制流量，但保護的維度不同。Rate limiting 是 per-client 的配額機制 — 每個 API key 有獨立的速率上限，一個 client 超限不影響其他 client。Backpressure 是全域的容量訊號 — collector 的寫入 channel 滿時對所有 client 回 429，不區分來源。一個 client 的失控用 rate limiting 處理（隔離問題源），全域流量過大用 backpressure 處理（全體降速）。

可觀察訊號與例子

Rate limiting 觸發的訊號是 collector 端對特定 API key 回 429 的次數上升、而其他 key 正常。典型場景：某個 SDK 版本有 bug 導致每秒產生 1000 筆事件 → per-key rate limiter 超過閾值 → 該 key 的後續 request 被回 429 → 其他 SDK 不受影響。

設計責任

Rate limiting 承擔的設計責任是「在公平性和可用性之間取得平衡」。閾值設太低，正常的 burst flush（攢批後一次送出）會被誤觸；閾值設太高，失控的 SDK 要送很多筆才被擋。合理的閾值需高於正常 burst 的事件速率。

完整章節

Per-SDK rate limiting 的實作 → Ingestion Scaling。Rate limiting 在 collector access control 中的角色 → Collector Access Control 實作。偽造流量場景下 rate limiting 和其他防護層的配合 → Client-side SDK 認證。

]]>