https://opentelemetry.io/blog/2026/we-broke-the-demo/
就在這週，OTel Demo 出 v3 了。
v2 支援了行動裝置的遙測。那 v3? 這可複雜了 噗

第一個新功能就是加入 agentic service (langchain+langgraph) 以及mcp + chatbot

第二個就原本 load testing 用 locust, 這版本改成 k6, 因為k6有個插件是 xk6-otel, 讓每個測試腳本的請求都能帶著 trace context 以及一些metadata。這是lucust目前還不支援的。

最後一個
OTel 組織很大的時間都在定義 Semantic Conventions 這塊的內容，有了他才能保證遙測模型的語意是一致的。（"語意"這概念很抽象，但不在這多解釋）
但落地到團隊中總會有客製化的議題冒出來，所以 OTel 在大概幾年前弄了個 Weaver (程式語言能編譯做檢查，遙測就是靠這玩意兒做編譯檢查）
正式把 Weaver 納入demo專案中做檢查
https://github.com/open-telemetry/opentelemetry-demo/tree/main/telemetry-schema
這裡定義的靜態schema就是weaver用的。
乾，他還用v2的schema格式 (schema v1? v2? ; 這又說來話長了）鐵人賽再分享。v1 都都沒人鳥跟分享，v2 又還在alpha ... 真難寫文章。

weaver check 寫在 CI 中。
https://github.com/open-telemetry/opentelemetry-demo/blob/main/.github/workflows/checks.yml#L128

語意一致性光靠寫文件是守不住的,Weaver 就是把 semantic conventions 這份文件變成「registry check 過不了就別想合併」的強制關卡。

語意模型的變化，最直接的一點也呈現在blog的前半段。
The rename nobody wanted but everyone needed

發生了什麼?
OTel Demo 從 2022 年開始寫的時候,自己土砲了一堆自訂欄位,通通掛在 app.* 這個命名空間下,比如:

• app.product.id(商品 ID)
• app.order.id(訂單 ID)
• app.payment.amount(付款金額)

結果到了 2023 年,OTel 把 app.* 這個命名空間收回去正式定義了——變成專門描述「client-side 應用程式」(網頁 app、手機 app)的保留欄位,不是隨便哪個服務都能用。

也就是說 Demo 從 2022 年用到 2023 年之後,一直在盜用一個後來變成官方保留字的命名空間。這是命名衝突,長期下來會混淆——你看到 app.xxx 到底是官方定義的、還是 Demo 自己土砲的,傻傻分不清楚。

為什麼拖到 2026 年 v3 才修? 作者自己坦白了兩個原因:

1. 工具跟不上:要把整個 codebase 幾十個服務裡所有 app.* 改成新命名空間,靠人工搜尋替換很容易漏掉、改錯、或漏掉某個服務用了不同大小寫/格式。要有工具幫忙才敢大規模改。→ 這就是
   把 Weaver 導入 Demo 的原因,Weaver 可以拿 schema 去檢查全 codebase 有沒有照規則命名,改完也能立刻驗證有沒有漏改的。

專案跟程式都能有 unit test保護業務邏輯了，遙測當然也是要！畢竟 o11y engineering 目的就是要你把遙測當成一等公民。

只要遙測是一等公民又有標準保證無歧義。
AIOps 要上路就容易了 XD

其實還有個議題也想知道，聽到蠻多公司都導入 OTel 數年了。
但是 semantic conventions 其實好幾版了，變化很大。
各公司是怎麼 migrate? transfer? 還是視而不見？還是拒絕升版 XD