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 遙測技術的第一版已於 2023 年 10 月在 Go 語言伺服器 goplsv0.14 版本中釋出。釋出後,約有 100 名使用者啟用了上傳,這可能是受釋出說明或 Gophers Slack 頻道討論的啟發,資料開始涓涓細流。不久之後,遙測技術在 gopls 中發現了第一個 bug。

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

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 中的隨機使用者啟用遙測技術時,我們看到在實際應用中,許多這些條件確實被達到了,而堆疊跟蹤的上下文通常足以讓我們重現並修復長期存在的 bug。我們將這些問題歸集在 gopls/telemetry-wins 標籤下,以跟蹤由遙測技術促成的“勝利”。

我開始從第二個含義來理解“遙測技術的勝利”:與沒有遙測技術相比,在 gopls 開發過程中,遙測技術帶來了勝利

Telemetry wins.
感謝 Paul 的建議。

遙測技術帶來的 bug 中最令人驚訝的方面是其中許多是真實的。當然,有些對使用者來說是不可見的,但相當一部分是 gopls 的實際錯誤行為——例如,缺失交叉引用,或在某些罕見條件下完成度微妙不準確。這些正是使用者可能會感到輕微惱怒但可能不會 bother 報告為 issue 的事情。也許使用者會認為這種行為是故意的。如果他們確實報告了一個 issue,他們可能不確定如何重現 bug,或者我們需要在 issue 跟蹤器上進行長時間的來回溝通才能捕獲堆疊跟蹤。沒有遙測技術,大多數這些 bug 就沒有合理的方式被發現,更不用說修復了。

而這一切僅僅來自幾個計數器。我們只為我們已知的潛在 bug 進行了堆疊跟蹤的儀器化。那些我們沒有預料到的問題呢?

自動崩潰報告

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 計數器仍然發現了 兩個 bug

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

鑑於遙測技術僅透過少量儀器化和一小部分目標樣本就已被證明非常有用,未來前景光明。

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

最初的遙測技術部落格系列 頭腦風暴了許多想法,探討了如何使用遙測技術來改進 Go。我們期待探索這些以及更多的想法。

在 gopls 中,我們計劃使用遙測技術來提高可靠性並指導決策和優先順序排序。藉助 Go 1.23 啟用的自動崩潰報告,我們預計將在預釋出測試中捕獲更多崩潰。未來,我們將新增更多計數器來衡量使用者體驗——關鍵操作的延遲、各種功能的 usar 頻率——以便我們可以將精力集中在最能使 Go 開發人員受益的地方。

Go 今年 11 月將滿 15 週歲,語言及其生態系統都在不斷發展。遙測技術將在幫助 Go 貢獻者更快、更安全地朝著正確的方向前進方面發揮關鍵作用。

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