OpenTelemetry（開放遙測）
/ OH-pen-tel-eh-MEH-tree /
一旦系統有了 metrics、logs、traces，一個實務上的亂局就出現了：每種語言有自己的日誌函式庫、每個追蹤工具都想要自己的代理程式、每家監控廠商都講自己的傳輸格式，於是替一個應用程式插樁就把你綁進一套工具，要換工具就得重新插樁、很痛苦。OpenTelemetry，通常簡稱 OTel，就是修正這點的開放標準——一個單一、廠商中立的方式，去產生、描述、運送遙測資料（metrics、logs、traces），好讓同一份插樁能餵給任何後端。
具體來說，OpenTelemetry 是三樣協同運作的東西。第一，一組規格與資料模型，定義一個 span、一個 metric、一筆 log 紀錄長什麼樣，外加跨服務傳播追蹤上下文的標準（traceparent 標頭）。第二，給每種程式語言的一族 SDK 與函式庫，你在程式碼裡呼叫它們（或由它們自動替常見框架插樁）來發出那些遙測，外加一個叫 OTLP 的共同傳輸協定來載運它。第三，OpenTelemetry Collector，一個你運行的獨立行程，以 OTLP 接收遙測，可以處理它（批次化、丟棄或取樣、加上或抹除屬性），再把它匯出到你選的任何後端。決定性的好處是解耦：你針對 OpenTelemetry API 把程式碼插樁「一次」，就能把 Collector 指向任何相容後端——還能更換後端——而不必改你的應用程式。
它之所以重要，是因為它已成為業界遙測的共同語言：藉由把資料模型與傳播格式標準化，它讓 traces 真正能跨越用不同語言寫、存在不同工具裡的各服務流動，而這正是真實系統上分散式追蹤的整個前提。給學習者的誠實定位：OpenTelemetry 是一個用來「產生與運送」遙測的標準與工具組——它本身不是儲存你資料的資料庫、也不是顯示資料的儀表板；你仍要替儲存與視覺化搭配一個後端（開源的或廠商的）。它的廣度與快速演進也意味著 metrics、logs、traces 三部分成熟的速度不同，所以實務上有些部分比其他部分更經得起考驗。
你的程式碼 -> OpenTelemetry SDK（單一 API）-> OTLP -> Collector -> [任何後端] # 插樁一次；把 Collector 的匯出器從廠商 A 換成開源 B # 不必改任何應用程式碼
針對 OTel API 插樁一次；Collector 往後匯出，於是儲存／儀表板後端可以更換而不必動你的程式碼。
一個常見誤解是 OpenTelemetry 會儲存或視覺化你的資料。它不會——它把遙測標準化並運送出去，你仍需要一個後端（開源或商業）來儲存與做儀表板；OTel 的價值在於你能更換那個後端而不必重新插樁。