指標管線捨棄 gostatsd，Atlassian 改採 OTel Collector
CNCF Blog（Atlassian 客座文章）· 2026-09-17
Atlassian 把用了近十年的 gostatsd 指標管線，整條換成 OpenTelemetry Collector，但刻意不動服務端看到的 StatsD UDP 介面，讓遷移對應用程式完全無感。這篇案例來自 CNCF Blog 於 2026 年 9 月 17 日刊出的 Atlassian 客座文章，作者為 Iris Grace Endozo、Farzad Vazirnia 與 Albert Kerr。文章描述的是一個橫跨多年、涵蓋 100,000 台主機、14 個地區的指標基礎設施改造。
原本的問題
gostatsd 是 Atlassian 自製的 StatsD 實作，運作將近十年算是穩定，但架構本身卡在 UDP-only 協定上，天生不支援 trace 與 log，也無法原生處理 OpenTelemetry 的資料格式。隨著社群工具往 OTel 收斂，Atlassian 得自己手動重建對方免費附贈的功能，維護成本逐年墊高、逐漸撐不住。
規模數字說明了問題有多急迫：這條舊管線要撐住 99.95% 的 SLA，每分鐘吃進約 4.8 billion 個資料點。用來做彙整與路由的 aggregator 與 nomad routing proxy 兩層合計吃掉 38% 的 CPU request，其中光是 nomad routing proxy 一項就占了整體資源的 13%——等於有一大塊運算資源花在「把資料從 A 搬到 B」，而不是真正處理指標。
採用的方法
團隊的核心策略是「換掉收集與管線，介面留著不動」：service owner 端看到的仍是原本的 StatsD UDP endpoint，後端則整套重做。遷移拆成四層：
- Collection 層：gostatsd sidecar 換成 OTel Collector distribution，維持相同 StatsD UDP 介面，額外加上 OTLP receiver，並把 metrics 與 tracing 合併進同一個 sidecar。
- Ingest 層：從「依 service 做 hash」改成以
streamID為單位、透過 contrib 的loadbalancingexporter做負載平衡，解決各服務指標量不均造成的 hot-shard 問題。 - Aggregation 層：自行開發 delta aggregation processor，CPU 使用量降低約
50%，並透過 atlassian-labs 開源釋出。 - Forward 層：把內部自製的 forwarder 換成無狀態的 Collector distribution，靠設定檔就能做到多目的地分流（SignalFx、S3），並直接沿用社群內建的 retry 與 backpressure 機制。
- Lambda / serverless：另做一個 OTel Lambda extension 取代 gostatsd sidecar，沿用相同的 StatsD address 與環境變數，函式端零改動。
| 管線層 | 舊架構 | 新架構 |
|---|---|---|
| Collection | gostatsd sidecar（僅 StatsD） | OTel Collector（StatsD + OTLP） |
| Ingest | 依 service 做 hash 路由 | 依 streamID 做負載平衡 |
| Aggregation | gostatsd 內建彙整 | 自製 delta aggregation processor |
| Forward | 內部自製 forwarder | 無狀態 Collector，多目的地 fan-out |
執行上，團隊先挑痛點最深、最願意迭代的早期採用團隊下手，靠正式環境的持續 profiling 而非合成測試來驗證，並用 1% → 10% → 50% → 100% 的漸進式放量、從非關鍵環境開始逐步擴大範圍。整個過程中新舊系統必須維持運維對等，這也是為什麼要橫跨多年才走完。
實際效果
各 shard 的 CPU 使用型態從「幾根長條加一堆閒置副本」變成平坦而均勻的分佈，hot-shard 相關告警也隨之消失。Aggregation 層 CPU 用量降低約 50%，整併 sidecar 後單一服務省下 3.9% CPU，資源消耗較高的服務整體 sidecar 成本再降 30%。彙整前後的資料量對比也很明顯：每分鐘 4.8 billion 個原始資料點，經彙整後只剩約 220 million，等於過濾掉 96% 的資料量才送進下游。
運維上因為所有階段共用同一套 Collector 程式碼，新增能力變成「加元件」而非「加一個新服務」，也讓自動擴縮的空間變窄、真正能在離峰時段縮容。移除 gostatsd 的 aggregator 與 nomad routing proxy 之後，等於省下這兩層原本佔掉的大部分基礎設施開銷，文章將此列為邁向全 OpenTelemetry 端到端管線的重要一步，而非單純換個 exporter。
對於還在用 DogStatsD / Datadog client 或既有 StatsD library 埋點的團隊，以及維運 nomad routing proxy、gostatsd aggregator 的 SRE，這份案例點出的下一步很具體：先確認自己服務用的是哪一種 client library，再評估能否直接改用 OpenTelemetry SDK。Atlassian 已表明要淘汰 vendor-specific client 與舊版 StatsD library，長期目標是連「埋點」這一端也整條換成 OTel，不再只是後端管線換血。對其他正在評估 OTel 遷移的維運團隊來說，這裡示範的「介面不動、後端全換」與「先挑痛點最深的早期採用者、正式環境 profiling 驗證、漸進式放量」兩個做法，比單純的 exporter 設定範例更值得直接參考。
原始來源：CNCF Blog：OpenTelemetry everywhere: Migrating a metrics platform at scale