.title: OpenTelemetry Kubernetes Attributes Processor 達成 v1.0.0 穩定版：語意慣例成熟如何改變觀測資料的可用性
.slug: opentelemetry-kubernetes-attributes-processor-v1-stable
在雲端原生環境中，觀測資料（telemetry，也就是 logs、metrics、traces 這類用來描述系統狀態的訊息）本身通常沒有太多意義。當你拿到一段日誌或指標，卻不知道它來自哪個 Pod、哪個 Namespace、哪個節點，這些資料就只能被搜尋，難以被關聯分析。OpenTelemetry 是一個用來統一產生、收集與匯出觀測資料的開放專案，其核心元件 OpenTelemetry Collector（負責接收、處理與轉送觀測資料的中繼節點）透過各種 processor（處理器）來改寫或補強資料。其中 Kubernetes Attributes Processor 的角色，就是自動讀取叢集內的資源資訊，並把這些資訊附加到觀測資料上。
根據 InfoQ 於 2026 年 10 月由 Craig Risi 撰寫的報導，OpenTelemetry 已將 Kubernetes Attributes Processor 晉升為 v1.0.0。這代表該元件正式達到專案的穩定度要求，涵蓋測試、效能基準（benchmarking）、文件與自身遙測資料的一致性等面向。對自行打造 Collector 發行版或二進位檔的組織而言，這也意味著 API 已具備穩定承諾，下游整合不必再擔心元件內部實作隨版本變動而破壞。
核心內容：元件做了什麼
Kubernetes Attributes Processor 的工作方式是主動探索（discover）Kubernetes 叢集中的資源，然後把 Pod、Namespace、節點（node）與工作負載（workload）等中繼資料附加到流經 Collector 的 logs、metrics 與 traces 上。原本只有「某個服務在某個時間點發生錯誤」的泛用資料，經過這一步之後，就能被依 Kubernetes 語境來查詢與關聯。目前該元件對 logs、metrics 與 traces 皆已達到穩定狀態，但 profiles（剖析資料，用於分析程式執行效率）仍在開發中。
為何現在才達成 v1.0.0，關鍵原因在於語意慣例（semantic conventions）的成熟。語意慣例是 OpenTelemetry 對資料欄位名稱與意義的共用定義；若每個廠商、每個元件都用不同的欄位名稱描述同一件事，跨系統的查詢與整合就會失效。OpenTelemetry 的 Kubernetes 語意慣例在 Semantic Conventions v1.42.0（2026 年 6 月）達到穩定狀態，並於同年 3 月先進入 release candidate 階段。專案方面表示，Collector 與 Kubernetes Semantic Conventions 兩個特別興趣小組（SIG）必須密切協調，因為 processor 要穩定，所依賴的語意慣例也必須先穩定。
遷移影響：不只改個元件版本
這次穩定版採用較新的 Kubernetes 語意慣例，因此部分欄位名稱改變，且與舊版不完全相容。例如 container.image.tag 改為 container.image.tags；Kubernetes label 與 annotation 欄位則從 k8s.pod.labels、k8s.pod.annotations 這類複數形式，改為 k8s.pod.label 與 k8s.pod.annotation。節點與 Namespace 的 label、annotation 也套用相同變更。
對觀測團隊而言，這比單純升級 Collector 元件版本更棘手。儀表板、告警規則、recording rules（預先計算並儲存的查詢結果，用來加速重複運算）、查詢語句、資料管線，以及任何引用舊欄位名稱的下游整合，都可能需要一併更新。為降低風險，OpenTelemetry 提供 feature gate（功能開關），讓新舊兩套慣例在遷移期間可以同時輸出，使用者可在完全切換到穩定 schema 之前逐步轉換。
技術與脈絡：穩定從來不是孤立完成
這項進展也是 OpenTelemetry「Stable by Default」（預設穩定）計畫的一環。Collector SIG 從 2025 年底開始聚焦於高使用率元件的穩定度，並透過社群回饋與 Collector 調查，找出使用者最在意可靠性的元件。Kubernetes Attributes Processor 隨後進入正式的畢業（graduation）流程，涵蓋程式碼所有權（code ownership）、測試、效能基準、文件與遙測穩定性等面向。這件事也顯示了觀測標準的一個特性：單一元件很難獨自穩定。若它輸出的中繼資料語義會隨時間變動，那麼依賴它的觀測資料就無法保持一致，因此 processor 的畢業必須與語意慣例的定案同步完成。
運維特性：穩定不等於無成本
升級到 v1.0.0 不會改變該元件的運作特性。它會為所監控的 Pod 維護中繼資料的記憶體快取，因此在大型環境中，記憶體消耗可能相當可觀，若未透過篩選條件限制要收集的 metadata，壓力會更明顯。OpenTelemetry 的文件也指出元件在 host-networked pods（使用網路命名空間的 Pod）與 sidecar 部署（與主容器並行運作的容器）上的限制。專案已公開涵蓋 CPU 與記憶體行為的效能基準報告。這點對把 Collector 當作生產平台一部分的組織格外重要：Kubernetes metadata enrich（補充中繼資料）本身就是一項工作負載，其資源消耗需要被理解與管理。
與廠商方案的差異
OpenTelemetry 的做法也與廠商專屬的 Kubernetes 觀測代理不同。例如 Datadog 在其 Datadog Distribution of the OpenTelemetry Collector 中提供 infraattributes processor，讓元資料由 Datadog Node Agent 與 Cluster Agent 取得，而不是讓每個 Collector 都直接查詢 Kubernetes API。Datadog 認為這樣可降低 API 負載，並在大規模環境中提供更一致的標籤結果。OpenTelemetry 的 Kubernetes Attributes Processor 則採取更偏供應商中立（vendor-neutral）的路線：直接透過 Kubernetes API 探索資源，並依專案標準語意慣例補強觀測資料。差異不在於能否附加 Kubernetes metadata，而在於補強發生在哪一層、由誰負責探索中繼資料，以及產出的資料在不同觀測後端之間的可攜程度。
限制與意義
v1.0.0 是一個值得追蹤的里程碑，但不代表 Kubernetes 觀測問題就此解決。欄位名稱變更會延伸到整個資料管線，profiles 支援尚未穩定，host-networked pods 與 sidecar 的行為仍有已知限制，記憶體消耗在大型叢集也不可忽略。對採用 OpenTelemetry 的團隊而言，現在的實際意義在於：觀測資料的 schema 開始具備可預期性，跨元件、跨後端的關聯分析有了穩定基礎，但遷移成本與運維成本必須同時納入評估。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。