背景：一個不能中斷的指標平台
Atlassian 近期公開了自家指標平台的改造過程，把核心從 gostatsd 換成 OpenTelemetry。這套平台要接收來自約 10 萬台主機、橫跨 14 個區域的資料，原本對外承諾 99.95% 的 SLO（服務水準目標，代表平台在一段時間內可接受的不可用比例上限）。這意味著團隊不能採用先停機再重建的做法，因為生產環境的告警完全依賴這些指標，一旦指標中斷，告警就會跟著失準。
gostatsd 是 Atlassian 內部使用多年的 StatsD 伺服器實作，長年運作穩定。問題出在它的設計只支援 UDP 傳輸，而且只處理指標，無法承接 trace（追蹤）與 log（日誌）。與此同時，越來越多服務開始產生 OpenTelemetry 格式的資料。如果繼續留在 gostatsd，Atlassian 就得自己重做那些 OpenTelemetry Collector 社群已經在開發的功能。這形成了典型的自建與開源取捨：繼續維護自家元件，等於長期承擔一條與社群平行、卻又反覆重造相同功能的路線。這份說明由 Iris Grace Endozo、Farzad Vazirnia 與 Albert Kerr 發表在 CNCF 部落格。
核心做法：保留介面，換掉後面所有東西
這項改造最關鍵的決策，是不要求數千個服務立刻從 StatsD 用戶端改寫成 OpenTelemetry SDK。團隊保留原本的 StatsD-over-UDP 介面，只把介面後方的管線整段重建。三位作者形容，這個選擇把工作性質從全組織的應用程式遷移，變成平台團隊自己的遷移。換句話說，應用端完全不必改動，就能繼續送出一樣的封包。
Atlassian 為此打造了四種用途明確的 Collector 發行版，分別負責收集、接收、聚合與轉送。這樣的切法對應 OpenTelemetry Collector 的管線模型：receiver（接收器）收下資料，processor（處理器）修改資料，exporter（匯出器）把資料送到一個或多個目的地。把平台拆成四個階段的好處，是每次只需要改動其中一段，不必連帶替換其他部分。
在收集階段，Atlassian 用追蹤團隊已在使用的 Collector 發行版，取代原本的 gostatsd sidecar（伴隨主應用程式執行的輔助程序）。應用程式照舊把 StatsD 封包送到相同位址，同時新增 OTLP receiver，讓較新的服務可以直接送出 OpenTelemetry 指標。把指標併入追蹤用的 sidecar，平均為 Atlassian 成本最高的 Micros 服務各省下 3.9% CPU；團隊估計整體 sidecar 成本降低約三成。對於無法執行 sidecar 的 serverless 工作負載，則以 OpenTelemetry Lambda 擴充套件維持相同介面。
接收層與聚合層：有狀態才是難題
接收層的問題不一樣，因為指標聚合是有狀態的。同一個時間序列的每個資料點，都必須送到同一個聚合器，否則算出來的結果會不完整。Atlassian 舊有的 nomad proxy 以服務加環境為單位做雜湊，把每個服務固定導向某個分片，結果是規模最大的服務擠在少數幾個忙碌的副本上。新系統改用 OpenTelemetry contrib 的 load-balancing exporter，以 stream ID 做雜湊。如此一來，個別時間序列仍然待在一起，但單一大型服務可以被拆散到整個池子裡，CPU 分布更平均、熱分片更少，離峰時段的擴縮也更順暢。
聚合階段帶來的資料量縮減最為可觀。平台每分鐘收到約 48 億個資料點，實際儲存約 2.2 億個，縮減幅度接近 96%。由於上游元件沒有辦法依照 Atlassian 的需求聚合 delta 指標，公司自行開發並開源了專用的 aggregation processor。改造後在相同流量下只用到約一半的 CPU。團隊特別強調，小型測試與基準測試並不足以找出真正的瓶頸，只有在生產環境持續做 profiling（效能剖析），才會真的指出該優化的位置。
最後一段轉送層，Atlassian 用一個名為 metrics-gateway 的無狀態 Collector 發行版，取代原本的特製轉送服務。上游 exporter 現在把資料分散送到 SignalFx 與 S3 等目的地，重試、排隊與背壓（backpressure，指下游來不及處理時向上游施加的壓力）行為則交由 Collector 提供。作者指出，之後要新增一個目的地，只需要改設定，不再是另一項獨立的整合專案。
與其他公司路線的差異
Atlassian 的做法與 Airbnb 近期的 OpenTelemetry 指標遷移略有不同。Airbnb 從共用指標函式庫進行雙軌發送，並選擇 VictoriaMetrics 的 vmagent 做串流聚合，最終處理每秒超過 1 億個樣本。Atlassian 則保留 StatsD 端點，只把底下的管線搬走。兩者的共同點，是把應用程式的遷移與中央基礎設施的替換分開處理。InfoQ 先前報導過的 Skyscanner 可觀測性改造則是另一條路：Skyscanner 先把 instrumentation 與傳輸統一在 OpenTelemetry 上，再透過更新共用函式庫搬移超過 300 個微服務。Atlassian 的相容層解決的是另一種情境，也就是如果要求所有服務立刻重新埋點，會變成一個更長、風險也更高的計畫。
影響與限制
在成本方面，Atlassian 表示 gostatsd 的聚合功能與 nomad 合計約占其指標叢集 CPU 要求的 38%，其中 nomad 單獨就占了總資源約 13%。把這兩個元件移除後，端到端的 OpenTelemetry 管線才算真正完成。下一步是把應用程式的埋點從 StatsD、DogStatsD 與各家廠商用戶端，轉移到 OpenTelemetry SDK。至於遷移過程的操作建議，團隊主張從開發與預備環境的工作負載開始，挑選本身能從改動中受益的早期採用者，再依 1%、10%、50%、100% 的階段逐步放量；新舊系統並行期間，也應盡量保留團隊熟悉的操作流程，並且在生產負載下做剖析，而不是只依賴小型基準測試。
這套做法並非毫無疑問。GREE 的監控基礎設施負責人 Iwahori 在一份會議紀錄的翻譯中，稱 Atlassian 的作法思慮周延，特別肯定以 stream ID 做路由以及自製的 delta 聚合處理器；但他也提出一個實務問題：有狀態的聚合層該如何擴充？報告指出，Atlassian 的回應顯示這部分仍仰賴手動設定。這也點出整套設計的邊界——把應用端與基礎設施解耦，確實降低了遷移風險，卻沒有讓有狀態聚合的擴充難題自動消失。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。