Go 官方部落格

Go 1.23 及更高版本中的遙測功能

Robert Findley
2024 年 9 月 3 日

Go 1.23 提供了一種新的方式來幫助改進 Go 工具鏈。透過啟用遙測資料上傳,您可以選擇與 Go 團隊分享有關工具鏈程式及其使用情況的資料。這些資料將幫助 Go 貢獻者修復錯誤、避免迴歸並做出更好的決策。

預設情況下,Go 遙測資料僅儲存在您的本地計算機上。如果您啟用上傳,每週會將您的資料中的有限子集釋出到 telemetry.go.dev

從 Go 1.23 開始,您可以使用以下命令啟用本地遙測資料上傳

go telemetry on

要停用甚至本地遙測資料收集,請執行以下命令

go telemetry off

遙測文件包含更詳細的實現說明。

Go 遙測的簡要歷史

雖然軟體遙測不是一個新概念,但 Go 團隊經過多次迭代,尋找一種滿足 Go 對效能、可移植性和透明性要求的遙測實現。

最初的設計旨在做到非常不顯眼、開放和隱私保護,以便預設啟用是可接受的,但在冗長的公開討論中,許多使用者提出了擔憂,最終該設計被更改為要求使用者明確同意才能進行遠端上傳。

新設計於 2023 年 4 月被接受,並在那個夏天進行了實施。

gopls 中的遙測

Go 遙測的首次迭代隨 Go 語言伺服器 goplsv0.14 版本於 2023 年 10 月釋出。釋出後,大約 100 名使用者啟用了上傳,他們可能是受釋出說明或 Gophers Slack 頻道討論的啟發,資料開始緩慢傳入。不久後,遙測就在 gopls 中發現了它的第一個錯誤

Telemetry found its first bug
Dan 在他上傳的遙測資料中注意到的一份堆疊跟蹤報告導致一個錯誤被報告並修復。值得指出的是,我們完全不知道是誰報告了這份堆疊。

IDE 提示

雖然很高興看到遙測在實踐中發揮作用,並且我們感謝早期採用者的支援,但 100 名參與者不足以衡量我們想要衡量的事物型別。

正如 Russ Cox 在他最初的部落格文章中指出的那樣,預設關閉遙測的一個缺點是需要持續鼓勵參與。維持一個足夠大以進行有意義的定量資料分析且代表使用者群體的使用者樣本需要進行推廣。雖然部落格文章和釋出說明可以提高參與度(如果您在閱讀本文後啟用遙測,我們將不勝感激!),但它們會導致樣本偏差。例如,我們從 gopls 遙測的早期採用者那裡幾乎沒有收到關於 GOOS=windows 的資料。

為了幫助覆蓋更多使用者,我們在 VS Code Go 外掛中引入了一個提示,詢問使用者是否要啟用遙測

The VS Code prompt
VS Code 顯示的遙測提示。

截至本部落格文章釋出時,該提示已向 5% 的 VS Code Go 使用者推出,遙測樣本已增長到每週約 1800 名參與者

Weekly Uploads vs Prompt Rate
提示有助於覆蓋更多使用者。

(最初的增加可能是由於提示了 VS Code Go nightly 擴充套件的所有使用者所致)。

然而,與最近的 Go 調查結果相比,這導致樣本明顯偏向 VS Code 使用者

Skew toward VS Code users
我們懷疑 VS Code 在遙測資料中的代表性過高。

我們計劃透過利用語言伺服器協議本身的一個功能,提示所有使用 gopls 的支援 LSP 的編輯器來解決這種偏差。

遙測的成功

出於謹慎考慮,我們建議在 gopls 遙測首次釋出時僅收集少數基本指標。其中之一是 gopls/bug 堆疊計數器,它記錄 gopls 遇到的意外或“不可能”的情況。實際上,它是一種斷言,但它不會停止程式,而是在遙測中記錄在某些執行中達到了該狀態,並附帶堆疊資訊。

在我們的 gopls 可伸縮性工作中,我們添加了許多此類斷言,但我們很少在測試或我們自己使用 gopls 時觀察到它們失敗。我們曾預期幾乎所有這些斷言都是無法達到的。

當我們開始提示 VS Code 中的隨機使用者啟用遙測時,我們發現許多這些條件在實踐中確實被觸發了,而且堆疊跟蹤的上下文通常足以讓我們重現並修復長期存在的錯誤。我們開始將這些問題歸類在 gopls/telemetry-wins 標籤下,以記錄遙測帶來的“成功”。

我開始從另一個角度理解“遙測的成功”:當比較使用遙測和不使用遙測的 gopls 開發時,遙測更勝一籌

Telemetry wins.
感謝 Paul 的建議。

從遙測資料中發現的錯誤最令人驚訝的一點是,其中有多少是真實存在的。當然,其中一些對使用者來說是不可見的,但 상당 部分是 gopls 的實際錯誤行為——例如缺失交叉引用,或在某些罕見條件下微妙不準確的補全。它們正是那種使用者可能只會輕微惱火但可能不會費心報告為問題的事物。也許使用者會認為這種行為是故意的。如果他們確實報告了一個問題,他們可能不確定如何重現該錯誤,或者我們需要在問題跟蹤器上進行長時間的來回溝通才能捕獲堆疊跟蹤。沒有遙測,幾乎沒有合理的方法能夠發現這些錯誤,更不用說修復了。

而這一切僅僅來自於幾個計數器。我們只針對我們已知的潛在錯誤進行了堆疊跟蹤的檢測。那麼我們沒有預料到的問題呢?

自動崩潰報告

Go 1.23 包含一個新的 runtime.SetCrashOutput API,可用於透過守護程序實現自動崩潰報告。從 v0.15.0 開始,當 gopls 崩潰時,它會報告一個 crash/crash 堆疊計數器,前提是 gopls 本身是使用 Go 1.23 構建的

當我們釋出 gopls@v0.15.0 時,樣本中只有少數使用者使用未釋出的 Go 1.23 開發版本構建了 gopls,然而新的 crash/crash 計數器仍然發現了兩個錯誤

Go 工具鏈及更高版本中的遙測

考慮到遙測僅用少量工具檢測和部分目標樣本就已證明其有用性,未來前景光明。

Go 1.23 在 Go 工具鏈內部記錄遙測資料,包括 go 命令以及編譯器、連結器和 go vet 等其他工具。我們已將遙測新增到 vulncheck 和 VS Code Go 外掛中,並且我們提議將其新增到 delve 中。

最初的遙測部落格系列集思廣益了許多關於如何利用遙測改進 Go 的想法。我們期待著探索這些想法以及更多內容。

在 gopls 內部,我們計劃使用遙測來提高可靠性併為決策和優先順序排序提供資訊。透過 Go 1.23 啟用的自動崩潰報告,我們預計在預釋出測試中捕獲更多崩潰。展望未來,我們將新增更多計數器來衡量使用者體驗——關鍵操作的延遲、各種功能的使用頻率——以便我們可以將精力集中在最能使 Go 開發者受益的地方。

今年 11 月,Go 將迎來 15 歲生日,Go 語言及其生態系統持續增長。遙測將在幫助 Go 貢獻者更快、更安全地朝著正確方向前進方面發揮關鍵作用。

下一篇文章:分享您使用 Go 開發的反饋
上一篇文章:新的 unique 包
部落格索引