換過可觀測性廠商的企業都懂一個道理：真正耗費成本與時間的從來不是合約本身，而是重新埋點、重寫 exporter，還要把整個 on-call 團隊重新訓練一遍新的 agent。這正是 OpenTelemetry 想解決的問題——也難怪它的官方 Vendors 名單，逐漸成為可觀測性產業裡最受關注的一份清單。畢竟，這是目前市場上最接近「中立答案」的名單，回答的正是一個關鍵問題：到底哪些平台，真正值得被信任來處理 OTel 資料？
TrueWatch 現在正式列在這份名單上——與 AWS、Microsoft Azure、Google Cloud、Datadog、Dynatrace、Elastic、Grafana Labs、New Relic、Splunk 並列，名字旁邊掛著兩個屬性標籤：Commercial：Yes 與 Native OTLP：Yes。
為什麼「廠商中立遙測」正在變成產業標配
OpenTelemetry（OTel）是 CNCF 旗下的開源標準，用來以廠商中立的格式產生、採集、傳輸 Traces、Metrics、Logs 等遙測資料。它的出現其實很好理解：當可觀測性從一次性的技術選型，變成企業要持續好幾年、換過好幾家廠商的長期決策，「埋一次點、就被綁一輩子」這種模式，早就難以為繼。
「企業已經不想再用『先選好廠商、再期待工具跟得上』這種做法。OpenTelemetry 讓標準走在最前面——符合這個標準的廠商能持續留在討論桌上，不符合的就會被排除在外。這次入選，意味著任何正在導入 OTel 標準的團隊，現在都會自然把 TrueWatch 納入評估名單。」——Mike Loong，TrueWatch CEO
這件事對正在快速成長的市場格外關鍵。像台灣這種雲端優先、又常常混合架構並存的環境，把可觀測性的資料標準統一到 OpenTelemetry，代表不管後端平台換誰、機房搬到哪個地區、廠商換過幾輪，最底層的埋點邏輯都能穩穩不動。
TrueWatch 在 OpenTelemetry Vendor 版圖上的定位
OpenTelemetry 官方 Vendors 頁面不是廠商自吹自擂的行銷名錄，而是一份門檻清單：只收錄真正能透過 OTLP 原生消費 OTel 資料、並把它轉化成能落地的可觀測性方案的廠商。換句話說，單方面宣稱「我們支援 OTel」，是進不了這份名單的。
對正在比較平台的團隊來說，這代表 TrueWatch 已經不是那種「剛好也能處理 OTel 資料」的替代方案，而是跟名單上其他廠商具備同等競爭力的選項。
「對同時在評估我們跟 Datadog、Grafana、New Relic 的團隊來說，這件事把問題從『我們該被綁定在哪一家的私有 Agent』，變成『哪一個原生支援 OTel 的後端最適合我們的技術棧』。這讓客戶更容易做決定——就算之後想更換，也不用擔心受制於單一廠商。——Brandon Foo，TrueWatch Head of Growth & GTM
原生 OTLP 支援，TrueWatch 實際做了什麼
原生支援 OTLP，聽起來不過就是接資料、存資料。但真正的難題是：收到一個 OTLP 封包，跟讓這些資料在生產環境的真實流量下派上用場，是完全不同等級的兩件事。
TrueWatch 透過 DataKit 的 OpenTelemetry 輸入端，原生接收 Traces、Metrics、Logs，把不同語言、不同框架產生的遙測資料，統一收進同一個可觀測性情境。在協議層，TrueWatch 支援：
- OTLP over gRPC
- OTLP over HTTP/Protobuf
- Traces、Metrics、Logs 各自獨立的資料端點
- HTTP 與 gRPC 的 gzip 壓縮傳輸
- OpenTelemetry Java Agent V1、V2 版本
「支援 OTLP 不是把 gRPC 或 HTTP 的埠打開就算了。真正的工程難度在資料進來『之後』——採樣策略怎麼定、基數怎麼控制，還要在生產環境的規模下讓鏈路跟日誌的關聯不中斷。這些才是我們真正拿到這個席位的理由，不是靠一個設定開關就能解決的。」——Jimmy Soh，TrueWatch Head of Product & Solutions Engineers
真正上線到生產環境後，TrueWatch 提供鏈路採樣、稀有資源保留、錯誤過濾、標籤黑白名單、本地快取等治理能力，讓團隊只留下真正有價值的訊號，不必為了「資料全部留著」額外支付一筆儲存費用；同時也能直接從鏈路資料算出請求量、錯誤率、延遲跟 Apdex 這些指標，還相容既有的 DDTrace 埋點，讓團隊不必全部重寫，就能一步一步遷移過去。
一個平台，650+ 整合——OpenTelemetry 只是起點
OpenTelemetry 只是進入 TrueWatch 的其中一條路，不是唯一一條。TrueWatch 目前支援 650+ 種技術棧整合，範圍涵蓋主機、容器、Kubernetes、雲平台、資料庫、中介軟體、網路設備、日誌、應用程式跟 RUM，同時也相容 OpenTelemetry、Prometheus、Telegraf 這幾種採集方式。
這個廣度，在實務上非常關鍵：多數工程團隊真正在運作的，從來不是單一、純粹的 OTel 技術棧，而是 OTel 跟 Prometheus exporter、舊有 agent，甚至既有的 OpenTelemetry Collector 部署，並存運作的環境。DataKit 的統一採集層，讓團隊不用「選一種、丟掉其他」——可以按自己的節奏把 OpenTelemetry 導進來，其他既有整合照樣回報進同一個可觀測性情境裡。
不過，OpenTelemetry 解決的終究是遙測資料怎麼產生、採集、傳輸的問題；資料進了平台之後，怎麼發現異常、怎麼把上下文串起來、怎麼定位根因、怎麼把問題真正解決掉，靠的還是一套完整的可觀測性產品能力 。TrueWatch 把 OTel 資料跟 APM、基礎設施與容器監控、日誌管理、真實使用者體驗監測（RUM）、告警跟故障管理串在一起，讓一條鏈路不只是「進來了」，而是真正被串進「發現—分析—定位—解決」的完整閉環裡。
了解更多：
- OpenTelemetry Official Vendors page: https://opentelemetry.io/ecosystem/vendors/
- TrueWatch OpenTelemetry integration docs: https://docs.truewatch.com/integrations/opentelemetry/