In Production 2──能力越強責任越大，別成為單點故障

你的可觀測性系統是你在系統故障時的「眼睛」。如果這雙眼睛在最需要它的時刻也一起失明了，那一切投入都白費了。這一章要談的是一個看似矛盾卻至關重要的命題：可觀測性系統本身的可擴展性與高可用性。

可擴展性（Scalability）#

隨著業務成長，被觀測的服務越來越多、資料量越來越大。你的可觀測性系統必須能跟上這個成長速度，否則就會成為瓶頸。

可觀測性系統的擴展和一般應用系統的擴展有相似之處，但也有其獨特的挑戰：

讀寫分離：寫入路徑（Ingestion）和查詢路徑（Query）的負載特性完全不同。寫入是持續的高吞吐量串流，查詢是突發的計算密集型操作。將兩者分離，可以獨立調整資源
Sharding（分片）：將資料按某個維度（如 Tenant、Service Name、時間範圍）分散到不同的節點上，避免單一節點成為瓶頸
多租戶（Multi-Tenancy）：在組織規模較大時，不同團隊的資料需要邏輯隔離，同時又要共享基礎設施以降低成本

Grafana 的 LGTM Stack（Loki、Grafana、Tempo、Mimir）提供了一個很好的漸進式擴展範例，它定義了三種部署模式：

Monolithic（單體模式）：所有元件跑在同一個 Process 中。適合小規模環境或評估階段，部署最簡單，但無法獨立擴展各元件
Scalable Monolithic（可擴展單體）：將讀寫路徑分離成獨立的 Process，但每個 Process 內部仍是單體。這是大多數中型團隊的甜蜜點——比完全微服務化簡單得多，又能處理相當規模的流量
Microservices（微服務模式）：每個功能元件都是獨立的服務，可以個別擴展。適合超大規模環境，但運維複雜度也最高

從 Monolithic 開始，遇到瓶頸時再逐步演進。過早微服務化是常見的過度工程陷阱。Grafana Labs 自己也建議大多數使用者從 Scalable Monolithic 開始。

在大規模環境中，Kafka（或類似的訊息佇列）經常被引入作為可觀測性管線中的緩衝層。它的角色是解耦生產者與消費者：

應對流量尖峰：當應用程式突然產生大量 Telemetry 資料（例如促銷活動、流量暴增），Kafka 可以暫存這些資料，讓後端按自己的速度消費，避免被打爆
多消費者模式：同一份資料可以被多個消費者讀取——一份送去即時告警、一份送去長期儲存、一份送去分析平台
重播能力：如果後端處理出錯，可以從 Kafka 重新消費資料，不會因為一次失敗就丟失資料

Kafka 本身也是一個需要運維的分散式系統。引入它意味著增加了一個需要監控和維護的元件。只有在資料量確實大到需要緩衝時才引入，不要為了架構的「優雅」而增加不必要的複雜度。

高可用性的核心思想很簡單：消除單點故障。對可觀測性系統來說，這意味著任何一個元件掛掉，整體系統仍然可以運作。

即使做了冗餘，極端情況下可觀測性系統仍可能部分失效。這時候需要有優雅降級的策略：

設計降級策略時要考慮一個弔詭的事實：你最需要可觀測性的時刻（系統故障時），往往也是可觀測性系統壓力最大的時刻。故障會產生大量的錯誤日誌、重試 Span、異常 Metrics，形成「觀測風暴」。

一個關鍵的設計原則是：可觀測性系統的可靠度應該高於被觀測系統的可靠度。

這聽起來像是一句廢話，但實務上很多團隊忽略了這一點：

不是所有環境都需要完整的高可用設計。以下是一些判斷依據：

開發/測試環境：通常不需要 HA，單副本即可
非關鍵的內部服務：基本的冗餘就夠了（雙副本 + 健康檢查）
面向客戶的生產服務：需要完整的 HA 設計
依賴可觀測性做自動化決策時：這是最需要 HA 的場景。如果你的系統根據 Metrics 做自動擴縮（Auto Scaling）、根據健康檢查做自動修復（Self-Healing），那可觀測性系統的故障就等同於自動化系統的故障

高可用不等於零停機。HA 的目標是在合理的成本下，將停機時間和資料丟失控制在可接受的範圍內。完美的 HA 不存在，重要的是明確定義你的 RTO（Recovery Time Objective）和 RPO（Recovery Point Objective），然後據此設計。