當組織開始仰賴 Observability 確認服務狀態時，一個容易被忽略的問題是：「監控我們的工具，自己會不會壞？」如果連監控系統都倒了，異常便會在沒人察覺的情況下發生。本章整理 Observability 工具在 Production 環境中常被強調的兩個能力：可擴展性（Scalability）與高可用（HA, High Availability），順帶討論這些和單點故障（SPOF, Single Point of Failure）的關係。

為什麼這兩件事都很重要#

在微服務架構底下，這兩個面向相輔相成：

• 可擴展性：當被觀察服務數變多、流量變大、查詢需求變高時，工具能隨需求水平擴展，且不影響當下效能與使用體驗。
• 高可用：即便面對硬體故障、網路問題或其他不確定因素，服務仍能維持穩定運作，常透過冗餘（redundancy）與故障轉移機制達成。

Observability 工具不只是被動地觀察別人，自己也必須具備同等等級的彈性，才能在各種狀況下持續可用。

Scalability#

水平擴展（Horizontal Scaling）是微服務世界的主流做法：透過增加實例數量分擔負載。相對的垂直擴展（Vertical Scaling）受限於單機硬體上限。要支援水平擴展，資料的讀寫機制從一開始就需要設計成可分散處理。

實務上會把資料流拆成寫入（Write）與讀取（Read）兩條路徑，並依需求各自擴展，這也呼應了命令查詢責任區隔（CQRS, Command Query Responsibility Segregation）的觀念。

Grafana 全家桶的共通骨架#

Loki、Mimir、Tempo 都承襲了 Cortex 的架構設計，主要讀寫路徑上的元件名稱幾乎一致：

• Write 路徑
  • Distributor：接收資料並把它分發給合適的 Ingester。
  • Ingester：負責把資料寫到物件儲存（Object Storage）。
• Read 路徑
  • Querier：從物件儲存讀取資料，回傳給前端。
  • Query Frontend：接收使用者查詢，並把查詢分派給多個 Querier。

這三套工具通常提供三種部署模式：

• Monolithic Mode：單一服務扛起全部功能，使用簡單但無法擴展。
• Scalable Monolithic：在 Monolithic 基礎上拆分為 Read、Write、Backend 等角色（Loki、Mimir 屬此類），可分組擴展；Tempo 目前以整體擴展為主，未來預計也會走向細分。
• Microservices Mode：每個元件獨立佈署，可達到最細緻的擴展粒度，通常搭配 Kubernetes 使用。

官方對不同模式都提供了 Helm Chart：

• Loki：loki（Monolithic 與 Scalable Monolithic，透過 singleBinary 參數切換）、loki-distributed（微服務）。
• Mimir：mimir-distributed（微服務）。
• Tempo：tempo（單體）、tempo-distributed（微服務）。

用 Kafka 當緩衝#

Kafka 等 Message Queue 在這類架構中常被拿來當緩衝區，避免後端被瞬間流量擊垮。例如以 OpenTelemetry Collector 或 Fluent Bit 把 Logs/Traces 先寫進 Kafka，再由另一條 Pipeline 從 Kafka 讀出送往 Loki 或 Tempo。對即時性需求沒那麼高的訊號（例如非告警相關的 Logs、Traces），這種延後寫入的代價通常是可接受的，能換來更穩定的後端。

Jaeger 原生就支援 Kafka 模式：Jaeger Collector 不直接寫入 Storage，而是先丟到 Kafka，再由 Jaeger Ingester 讀出寫入 Storage Backend，達到類似效果。

High Availability#

微服務文化通常假設「每個服務都可能壞」，HA 就是讓系統能在部分元件失效時仍維持運作。常見做法：

• 選擇本身支援 HA 的工具，或依官方文件設計 HA 部署。例如 Prometheus 可同時跑多個實例抓取相同來源，再交給 Mimir 做後端去重儲存，避免單一 Prometheus 故障導致資料遺失。
• 把 Observability 工具當作第一線業務服務看待：收集它們的 Metrics 和 Logs、設定告警通知。Fluent Bit、OpenTelemetry Collector 都內建監控資訊；Loki、Tempo、Mimir 也都有官方提供的 Dashboard 與 Runbook。

「自己吃自己的狗糧（eating your own dog food）」：用守護其他服務的方式守護 Observability 工具自己，是避免它變成單點故障最直接的做法，也順帶能讓災難復原（Disaster Recovery, DR）規劃考慮到觀測平台本身。

小結#

如果 Observability 工具自己無法穩定運作，它們不但無法守護其他服務，反而會成為監控體系的單點故障。要避免這種情況，工具本身必須同時具備可擴展性與高可用，並且接受跟其他線上服務一樣（甚至更高）的 SLO（Service Level Objective）標準與監控強度。當 Observability 平台自身也有完整的觀測，整個系統的韌性才算真正完備。

原文出處#

• 原書/iThome：https://ithelp.ithome.com.tw/articles/10339110