本機服務也值得使用 OpenTelemetry，但不要照搬企業預設

最近我花了一些時間，把幾個服務放進自己的家用網路裡。這次設定不只是把程式跑起來而已，我也加上了身分提供者（IdP）、OpenTelemetry、VPN，以及用來集中查看遙測資料的 OpenObserve。

這個過程讓我學到一件很重要的事：本機服務值得使用 OpenTelemetry，但不需要不加思考地照搬企業環境的所有預設。

我並不是覺得在家裡跑 OpenTelemetry 沒有意義。相反地，日誌與 trace 對本機服務非常有用，尤其當我們開始期待 AI 幫忙診斷問題、找出故障依賴，甚至自動提出修復方式時，結構化的執行紀錄會變得更加重要。

真正需要重新思考的是：哪些訊號應該一直收集？它們要保留多久？metrics 是否真的值得在目前的使用情境下持續開啟？

企業環境的直覺

提到可觀測性，我很自然會想到三種訊號：

• logs
• traces
• metrics

對服務大量使用者的 API 來說，這是很合理的做法。當每天有幾十萬人呼叫你的 API，延遲、錯誤率、吞吐量、資源使用量與各種 instance 狀態，都可能直接影響產品品質。很多問題不會出現在單一請求裡，而是要透過長時間累積的統計資料才看得出來。

這也是 OpenObserve 這類平台很有價值的地方。它可以集中接收不同服務送出的遙測資料，讓團隊搜尋、交叉比對與保留這些資訊，並在使用者大量回報之前找出異常。

但當我把同一套想法搬到家用網路時，情況完全不同。

我的本機服務不是生產環境叢集

本機服務可能一樣有 API、登入、VPN、資料庫與好幾個依賴，看起來很像一個縮小版的 production system。但它的流量和使用者行為可能完全不一樣。

在我的情況裡，使用者通常只有我自己，偶爾是家人。服務可能一個小時只有幾個請求，接著在大家睡覺時完全沒有流量。這種環境沒有足夠的樣本讓長期 metrics 很有意義，也沒有一個 on-call 團隊等著看儀表板處理問題。

所以我現在會問的不是「metrics 有沒有用」，而是：「這個 metric 會幫我做出什麼決定？」

如果儀表板告訴我今天收到三個請求、昨天收到兩個請求，我會因此採取不同的行動嗎？如果服務在沒有人使用時仍然持續計算、匯出與儲存指標，這些工作到底提供了多少價值？

相較之下，下面這些問題通常更符合本機服務的需要：

服務現在連得上嗎？
上一個請求為什麼失敗？
這次工作流程中間發生了什麼事？
是哪一個依賴服務沒有回應？
這台機器現在是否出現異常負載？

這些問題需要健康檢查、結構化 logs，以及對重要工作流程保留 traces。它們不一定需要把每一個元件能產生的 metric 都持續送出去。

OpenTelemetry 對本機 AI 自動化仍然很重要

這裡很容易產生一個誤解：既然 metrics 可能沒有必要，是不是連 OpenTelemetry 都不該在家裡使用？

我的答案是否定的。

OpenTelemetry 不只是拿來畫圖表的工具。它可以提供一致的格式，描述一次請求經過哪些服務、哪一個依賴變慢、哪個錯誤在什麼上下文裡發生。這些資料對人類除錯有用，對 AI 也同樣有用。

如果未來希望 AI 能夠自動找出故障原因、判斷某個 dependency 是否失效、分析一個慢速流程，甚至提出並套用修復方式，那麼只丟給它一段零散的文字 log 往往不夠。結構化 logs 和 traces 能提供更完整的上下文。

因此，我仍然會在本機服務使用 OpenTelemetry，尤其是 logging 與 tracing。它們能讓服務留下可理解、可搜尋、也能被自動化工具利用的執行紀錄。

Metrics、儲存空間，以及被忽略的 retention

本機遙測最容易被低估的地方，是大家常常只想到「資料送不送得進去」，卻忘了「資料要留多久」。

安裝 OpenObserve 時，通常會先專注在 collector、儲存後端與 dashboard 能不能正常工作。當資料已經開始出現在畫面上，就很容易覺得設定完成了。但如果沒有同時決定 retention，系統其實只完成了一半。

遙測資料會持續累積。logs、traces 和 metrics 都會佔用儲存空間，之後還會帶來清理、容量規劃與保留期限管理的問題。對一個只有自己使用的服務來說，長期保留大量低價值 metrics，通常很難證明是值得的。

而且成本不只有硬碟空間：

• 應用程式要持續產生與匯出資料。
• OpenTelemetry SDK 或 agent 要持續處理資料。
• collector 和 OpenObserve 要接收、索引與儲存資料。
• 本機服務可能因此一直保持活動狀態，影響睡眠、耗電與背景負載。
• 一旦有了 dashboard，就會讓人覺得還需要維護 alert、threshold 與 retention。

所以 retention 不是事後的 housekeeping，而是 observability 設計的一部分。

我現在會在安裝時就先問幾個問題：

• logs 要保留幾天，才足以調查常見問題？
• 一個工作流程結束後，trace 還有多少天的價值？
• metrics 是否真的要儲存？如果要，解析度與保留期限是多少？
• 儲存空間快滿時，系統會怎麼處理？
• 舊資料能不能自動刪除，而不影響主要服務？

答案不一定要很長。traces 可能只需要保留幾天；logs 可以多留一點，方便追查偶發錯誤；metrics 則可以先關掉，直到我有一個明確問題需要它來回答。

重點不是找到一個所有人都適用的 retention 數字，而是不要讓系統在沒有明確決定的情況下，替我選了一個永遠保留的策略。

我現在會採用的遙測策略

對家用網路裡的服務，我會把「支援」和「永遠開啟」分開看：

這不是降低標準，而是讓標準配合環境。若我正在開發某個功能，可能會暫時提高 trace 詳細程度；問題找到之後，再把設定調回合理範圍。若某個本機資料庫真的需要觀察資源使用量，metrics 當然可以重新打開。

但在目前階段，我沒有足夠的實際需求，所以很可能會把 metrics 關掉，同時繼續使用 logs 和 traces。

自架產品的 enterprise 牆

另一個讓我不太舒服的發現，和產品授權及功能分層有關。

現在有不少開源產品允許我們自行部署。對本機基礎設施來說，這很有吸引力：資料可以留在自己的網路裡，服務由自己控制，也不用為了使用一個小功能把個人資料交給第三方。

但有些產品雖然可以自架，卻把 OIDC、OAuth、角色管理或進階 OpenTelemetry 整合放在 enterprise 方案裡。結果是：我可以把程式跑起來，卻未必能把它接進已經建立好的身分與可觀測性系統。

我並不是認為每一項功能都必須免費，也不是反對開源專案透過商業方案維持發展。問題是，當被限制的功能其實是基本整合能力時，「可以自架」和「可以真正使用」之間就出現了很大的落差。

例如，我已經在家用網路裡建立一個身分提供者，若每個自架服務都不能使用 OIDC，我就只能替每個應用程式建立另一套帳號。這不是企業才會遇到的需求，而是希望讓本機服務維持一致安全邊界的人很自然會有的需求。

因此我現在會把自架軟體分成兩個問題來評估：

1. 我能不能自己執行它？
2. 我能不能把它和現有的系統整合起來？

第一題的答案可能是「可以」，第二題卻變成「付費後才可以」。這個差異應該在文件與功能比較表裡被清楚說明，而不是等到實際部署後才發現。

本機基礎設施應該服務真正的決策

這次經驗讓我重新思考本機服務的設計方式。它不需要變成一個縮小版的企業平台，而應該按照實際使用者數量、流量、設備的活動時間、故障後果，以及我真正需要做的決定來設計。

對我來說，這可能代表：

• 一個共用的 IdP，而不是每個應用程式各自建立帳號
• 用 VPN 建立私有邊界，而不是把每個服務直接暴露在公開網路
• 使用 OpenTelemetry 收集有用的 logs 與 traces
• 把遙測資料保留到足以除錯，但不要無限期保存
• 只有在 metrics 能回答具體問題時才啟用它
• 讓自架軟體能透過標準協定彼此整合

OpenTelemetry 我還是會繼續用。對我而言，它不只是監控工具，也是一種讓人類和 AI 都能理解服務狀態的共同語言。只是這套能力要搭配清楚的 retention 策略，metrics 也應該按照需求開關，而不是因為「企業通常都這樣做」就全部打開。

企業的設計模式仍然值得學習，但家用網路有不同的規模、節奏與「足夠」的定義。好的本機設定，不是收集最多訊號、安裝最多整合，而是在提供足夠上下文的同時，不讓自己多養出一個需要每天照顧的系統。