Observability Signals
可觀測性訊號
可觀測性訊號是系統為了說明自身行為而送出的證據。常見訊號包含追蹤、指標、日誌，以及在服務間傳遞少量背景資訊的 `Baggage` 背景資料。
另一個例子
結帳的 p95 延遲超過 800ms。指標指向歐盟地區，範例連結會開啟追蹤 `7af…`，追蹤區段找到 `inventory.reserve`，相連的日誌顯示逾時類型，但不包含卡號。部署欄位把錯誤縮小到 `2026.07.30` 版本，而且抽樣仍會保留錯誤。
主要部分
- 01儀測 Telemetry
- 02關聯 Trace／Metric／Log
- 03收集、取樣、儲存與查詢
什麼時候用
依使用者能感受到的服務目標設計訊號。要傳遞追蹤情境、串連 ID、限制標籤值的數量，並移除敏感資料。
什麼時候不要用
收集所有資料不等於可觀測性。不要記錄機密或無限制的使用者 ID，也不要建立沒有調查方式或告警處理計畫的儀表板。
程式裡的名稱
OpenTelemetry traces + metrics + logs + resource/attribute conventions + context propagation 上線前要檢查
檢查環境與預先準備的測試資料。定義看得到的預期結果、失敗與邊界案例。也要定義隔離方式、固定輸入、查錯資訊與清理流程。設定執行時間預算、負責人與不穩定測試的處理規則。
預期成果：用 可觀測性訊號 (Observability Signals) 收集可重複驗證這項行為或品質風險的證據。 使用者情境：結帳的 p95 延遲超過 800ms。指標指向歐盟地區，範例連結會開啟追蹤 `7af…`，追蹤區段找到 `inventory.reserve`，相連的日誌顯示逾時類型，但不包含卡號。部署欄位把錯誤縮小到 `2026.07.30` 版本，而且抽樣仍會保留錯誤。 驗證方式：可觀測性訊號 (Observability Signals)。 適用理由：依使用者能感受到的服務目標設計訊號。要傳遞追蹤情境、串連 ID、限制標籤值的數量，並移除敏感資料。 不應使用的情況：收集所有資料不等於可觀測性。不要記錄機密或無限制的使用者 ID，也不要建立沒有調查方式或告警處理計畫的儀表板。 測試要求：說明要測的系統與環境。定義預先準備的測試資料（Fixture）、其他輸入，以及看得到的預期結果。加入預期失敗、邊界案例、容許值、隔離方式與清理流程。 測試維護：讓失敗原因容易查找，並控制隨機或會改變的輸入。指定負責人。測試速度與維護成本要符合發布前檢查的需要。 驗收條件：已知缺陷存在時測試會失敗，修正後通過。測試能在目標環境重複執行，提供可採取行動的證據，且不洩漏或改動無關資料。 證據與限制（證據邊界）：它只代表該來源的官方說法。其他平台或團隊可能有不同用法。 待確認：發布前必過的檢查、環境、測試資料、容許值、執行時間預算、負責人，以及不穩定測試的處理規則。
檢查這份需求
請 AI 程式助手檢查目前如何使用 可觀測性訊號 (Observability Signals)。 定義：可觀測性訊號是系統為了說明自身行為而送出的證據。常見訊號包含追蹤、指標、日誌，以及在服務間傳遞少量背景資訊的 `Baggage` 背景資料。 正式環境檢查：檢查環境與預先準備的測試資料。定義看得到的預期結果、失敗與邊界案例。也要定義隔離方式、固定輸入、查錯資訊與清理流程。設定執行時間預算、負責人與不穩定測試的處理規則。 修改程式前，先列出看到的證據、缺口、嚴重程度，以及最小且安全的修正。