觀察服務與使用者

從問題開始

監控檢查已知條件。可觀察性協助調查系統行為，包括未預料的故障。更多儀表板，不會自動帶來更好的答案。

對虛構匯出服務，先問一個使用者問題：有權限的使用者，能否在約定時間內取得正確匯出？再選擇能回答這個問題、並協助解釋失敗的訊號。

OpenTelemetry 提供遙測的量測工具與標準，可將訊號送到相容後端。但仍需要儲存、查詢、存取控制、保留規則，以及依證據採取行動的人員。可觀察性入門。

連結不同形式的證據

指標衡量數量隨時間的變化。記錄檔記錄事件。追蹤（trace）在請求經過系統時，連結相關操作。Span 則代表一段追蹤中的單一操作。

對非同步工作，在提交的工作與工作程序執行之間，保留安全的關聯。HTTP 202 回應可能表示工作已接受，不代表匯出已完成。

需要行動時才發出告警

設定 SLO 前，先定義 SLI 與分母。在範例中，計算符合條件、且在約定時間內正確完成的匯出。定義長時間執行與已放棄工作如何計入衡量。

錯誤預算描述 SLO 期間內容許的失敗程度。消耗率描述失敗消耗預算的速度。Google 指引使用多個時間視窗，平衡及時偵測與告警雜訊。依 SLO 告警。

條件需要及時操作時，通知值班人員。較不緊急的工作送入佇列。每項告警都需要負責人、影響說明、調查連結和應變指示。檢視反覆出現卻不需採取行動的告警。

不要為每項服務套用同一個通用門檻。使用者影響、流量、營業時間和應變資源，都會影響決定。

保護遙測管線

遙測可能包含個人資料、權杖、請求參數和機密文件。蒐集前，定義允許欄位。限制存取與保留時間。匯出到外部後端前，遮蔽機密值。敏感遙測資料。

不要用客戶電子郵件或唯一工作 ID 作為指標標籤。無上限的標籤會增加時間序列數量，也可能暴露識別資訊。指標使用受控維度；核准的關聯識別碼，則放在有存取控制的記錄檔或追蹤中。

也要衡量管線本身。檢查接收失敗、丟棄資料，以及最新觀察距今多久。平坦的錯誤圖表，可能代表沒有錯誤，也可能代表沒有收到遙測資料。清楚呈現這個差別。

調查具體故障

虛構服務對每個請求都回報 HTTP 202，但佇列等待時間從幾秒增加到 15 分鐘。工作程序記錄檔顯示重複的資料庫逾時。取樣追蹤顯示，工作程序大部分時間花在資料庫呼叫。

這些證據支持有方向的調查，但不能確定原因是查詢變更、連線耗盡，還是資料庫容量。使用除錯方法比較這些假設。

Taiga Monitoring 提供產品健康狀態檢視，包括可用性與瀏覽器體驗訊號。它補充基礎架構和應用程式可觀察性，不會取代那些系統。Monitoring。