如何確保服務正常運作？應該監控服務？

程式仍在執行不代表功能可以正常完成。單一健康檢查成功，也無法說明錯誤是否持續增加、處理是否變慢，或相依項目是否已經影響結果。監控要先定義正常狀態，再收集足以判斷偏差的資料，最後把需要處理的問題轉成可以採取行動的告警。

本章使用「服務」統稱需要持續觀察的執行單位。目標系統如果是批次程式、桌面程式或其他形式，仍可按照實際使用方式改用完成率、等待時間、輸出正確性或最近成功時間等指標。

先定義正常運作的結果

「正常」必須能被檢查。每項重要功能應該先連回已確認的需求、風險及穩定條件，再選擇監控資料。

可以使用服務水準指標（Service Level Indicator, SLI）表示實際量測結果，再以服務水準目標（Service Level Objective, SLO）記錄指定期間內要達到的門檻。SLI 與 SLO 要採用使用對象能感受到的結果，例如成功比例與延遲，而非只觀察內部執行資源。

用四項黃金訊號建立起點

Google SRE 的四項黃金訊號包含延遲、流量（Traffic）、錯誤與飽和度。這組訊號源自持續提供回應的服務，套用至其他系統時要改成符合實際工作的量測方式。

平均值可能掩蓋少數極慢或連續失敗的操作。延遲應該觀察符合需求的百分位數，錯誤則要按照類型、功能與版本分類。飽和度也要包含即將超過限制的趨勢，避免等到功能失敗後才發現問題。

為不同執行方式選擇指標

監控清單要按照系統實際構成建立，不需要預設所有系統都有相同元件。

每個指標都要回答一個實際問題。無法連回需求、風險、容量限制或處理動作的資料，可以先保留在除錯記錄，不必全部轉成長期指標。

分清記錄、指標與追蹤的責任

遙測（Telemetry）可以從不同角度描述同一項操作。OpenTelemetry 的訊號說明將追蹤、指標與記錄列為不同訊號，它們適合處理的問題也不同。

已經採用 operationId 的系統，可以用它串連錯誤結果、記錄與追蹤。指標則要使用有限且穩定的維度聚合資料，不能把每次操作的識別碼直接放進指標標籤。

從異常事件產生可彙整指標

異常事件已經具有穩定欄位時，可以按照時間範圍與結果分類產生指標。常見轉換如下：

例如，errorCode 在十分鐘內持續增加可以形成錯誤率指標，再由告警連結查詢該時間範圍的記錄。相關人員可以從代表性事件取得 operationId，繼續查看同一次操作的處理路徑。這樣既能發現整體變化，也能保留調查單次問題的入口。

控制指標名稱與維度數量

相同指標的每組標籤值都會形成獨立時間序列。把 operationId、原始路徑、錯誤訊息或其他不受限制的內容放入標籤，會讓序列數量持續增加。Prometheus 的指標命名建議也提醒避免使用識別碼等高基數（High Cardinality）內容作為標籤。

建立指標時應該：

• 使用能表達量測對象、單位與類型的穩定名稱。
• 只加入查詢、告警或容量判斷確實需要的維度。
• 預估每個維度的可能值數量，以及組合後的時間序列數量。
• 將完整路徑、識別碼與錯誤細節保留在記錄或追蹤中。
• 定義計數重設、缺少資料、延遲上報與重複資料的判斷方式。

指標值為零與沒有收到資料代表不同情況。告警及儀表板要能辨識程式沒有工作、收集流程中斷與實際沒有錯誤，避免把遙測缺口解讀成正常狀態。

區分存活、就緒與功能健康

不同健康檢查要觸發不同動作。

如果部署平臺支援自動重新啟動與工作分派，可以按照平臺語意提供對應檢查。Kubernetes 的探測說明指出，存活探測失敗可觸發重新啟動，就緒探測失敗則停止把工作送至該 Pod。其他部署方式仍可沿用問題分類，但處理動作要按照實際能力設計。

存活檢查不適合依賴所有外部項目。外部相依暫時失效時重新啟動大量正常程序，可能擴大問題。健康檢查應該快速、具有限時，並且避免產生資料變更。完整功能驗證則由冒煙測試、合成操作或其他受控案例負責。

用儀表板呈現狀態與變更

儀表板應該回答「目前是否正常」、「影響多大」與「甚麼時候開始改變」。首頁可以先呈現重要功能的 SLI、錯誤、延遲、處理量與飽和度，再提供組成項目與單次操作的深入查詢。

圖表至少要能按照環境、部署單位與版本篩選，並標記部署、設定或相依項目變更時間。比較變更前後時要使用相同時間範圍與統計方式，不能只憑兩張縮放比例不同的圖表判斷改善或退化。

儀表板適合呈現需要持續觀察但沒有立即動作的趨勢。必須由人員在指定時間內處理的狀態才適合告警。

建立可採取行動的告警

告警條件應該對應使用對象能感受到的問題、即將超過的限制，或已確認需要人工介入的故障。每項告警至少要包含：

• 使用穩定指標、判斷期間、門檻與恢復條件。
• 記錄嚴重程度、影響範圍、目標環境與目前版本。
• 指定接收責任、通知方式、回應時間與升級條件。
• 提供儀表板、記錄查詢、代表性 operationId 與處理手冊入口。
• 說明可以立即採取的確認、隔離、降級、復原或停止動作。
• 記錄靜默、合併重複通知與維護期間的處理方式。

短暫波動可以使用持續時間避免立即觸發。Prometheus 的告警規則提供 for 條件，讓狀態持續指定時間後才進入觸發。實際時間仍要按照問題影響與可接受偵測時間決定。

無法採取任何動作的通知只會增加雜訊。每次事件處理後，應該檢查告警是否過早、過晚、重複，或缺少必要脈絡，再調整門檻、合併方式與處理說明。

管理遙測資料的保存與保護

記錄、指標與追蹤的資料量、查詢方式與敏感程度不同，應該分別設定：

• 按照問題追查、趨勢比較與規範需求設定保存期限。
• 限制可查詢、匯出、修改與刪除的範圍，並記錄重要管理操作。
• 在產生端移除密碼、權杖、私鑰、個人資料與不必要的輸入內容。
• 控制追蹤抽樣與記錄層級，並確認抽樣後仍能判斷重要錯誤。
• 定義收集或保存端失效時的緩衝、捨棄、降級與告警方式。
• 定期確認過期資料、備份與匯出副本都按照規則處理。

監控資料本身也需要監控。收集延遲、資料缺口、查詢失敗或告警通知失敗都可能讓問題無法被發現，應該有獨立的檢查與替代通知方式。

用故障演練驗證監控效果

設定完成後，要用受控情境確認從問題發生到採取動作的完整流程：

1. 模擬程式停止、處理延遲、錯誤增加或相依項目逾時。
2. 確認健康檢查、記錄、指標與追蹤在預定時間內反映問題。
3. 確認告警包含環境、版本、影響範圍、查詢入口與處理方式。
4. 由實際負責人按照處理手冊完成確認、暫時處置與恢復。
5. 記錄偵測時間、通知時間、開始處理時間與恢復時間。
6. 修正遺漏訊號、錯誤門檻、無效通知與過期處理步驟。

演練不能只確認通知有送出。最終還要驗證功能與資料結果已恢復，並且告警會在恢復條件成立後結束。部署方式、版本、重要功能或相依項目改變時，也要重新執行相關情境。

完成監控設計的檢查

• 重要功能是否具有可檢查的正常狀態、SLI 與目標門檻？
• 延遲、需求量、錯誤與飽和度是否已按照實際執行方式量測？
• 結構化記錄、指標、追蹤與健康檢查的責任是否清楚？
• 異常事件是否能按照穩定欄位彙整，並從指標查回代表性操作？
• 指標名稱、單位與標籤是否受控，且沒有使用不受限制的高基數內容？
• 存活、就緒與功能健康檢查是否觸發符合語意的動作？
• 儀表板是否能按照環境與版本比較部署前後的狀態？
• 每項告警是否具有判斷期間、嚴重程度、影響範圍、接收責任與處理入口？
• 遙測資料是否具有保存、存取、遮蔽、抽樣與刪除規則？
• 收集與通知流程本身失效時，是否能被發現？
• 故障演練是否已驗證偵測、通知、處理、恢復與告警結束？

重點整理

• 監控要從可檢查的正常狀態開始，按照系統實際執行方式選擇延遲、需求量、錯誤、飽和度與功能結果。
• 結構化記錄保留單次事件，指標呈現整體變化，追蹤還原處理路徑，健康檢查則觸發快速處置。
• 告警必須包含影響、版本、查詢入口與可執行動作，並透過故障演練確認整個處理流程有效。