Go 部落格
Go 1.23 及之後版本中的遙測
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 遙測的第一個反覆運算步驟發佈於v0.14版 Go 語言伺服器gopls
中,時間為 2023 年 10 月。隨著發佈,大約有 100 位使用者啟用上傳功能,他們可能是受到發佈備註或Slack Gophers頻道中的討論激發,並且資料開始逐漸湧入。沒多久,遙測便發現了 gopls 中的第一個錯誤

IDE 提示
雖然看到遙測在實務中運作很不錯,而且我們也感謝早期採用者的支持,但只有 100 位參與者還不足以測量我們想要測量的事項。
如 Russ Cox 在其原始部落格文章中指出的,遙測採用預設停用的方式有一個缺點,就是需要持續鼓勵參與。外展工作必須讓樣本使用者人數達到足夠大,才能進行有意義的量化資料分析,並且具備使用者族群的代表性。儘管部落格文章和發佈備註可以提升參與度(如果各位在閱讀完本文之後願意啟用遙測功能,我們會很感謝!),但它們會導致樣本傾斜。例如,我們幾乎沒有收到 gopls 中遙測早期採用者提供,且與 GOOS=windows
相關的資料。
為了觸及更多使用者,我們在VS Code Go 外掛程式中加入提示,詢問使用者是否要啟用遙測功能。

截至這篇部落格文章,提示已對 5% 的 VS Code Go 使用者推出,並且遙測樣本數量已成長到約 1800 位每週參與者

(最初的不順利可能是由於提示所有 VS Code Go nightly 擴充套件使用者)。
不過,與 最近的 Go 調查結果 相比,它造成明顯偏向 VS Code 使用者的趨勢。

我們透過使用語言伺服器協定的功能,計劃提示使用 gopls 的所有相容 LSP 編輯器來解決這個不平衡問題。
遙測優點
出於謹慎,我們提議僅收集幾個基本指標,作為 gopls 遙測功能初始發布的依據。其中之一是 gopls/bug
堆疊計數器,用來記錄 gopls 遇到的意外或「不可能」狀況。實際上,它是一種斷言,但是它不會停止程式,而是在遙測中記錄它在某個執行中已到達,並附上堆疊。
在進行 gopls 可擴充性 的工作中,我們已經新增許多這一類的斷言,但在測試或我們自己使用 gopls 時,我們幾乎沒有看到它們失敗。我們預期這些斷言幾乎都無法到達。
當我們開始提示 VS Code 中的隨機使用者啟用遙測時,我們發現許多這些狀況實際上已到達,而且堆疊追蹤的內容通常能讓我們重現並修正長期存在的臭蟲。我們開始在 gopls/telemetry-wins
標籤底下收集這些問題,以追蹤透過遙測功能獲得的「優點」。
對「遙測優點」的第二個含義,我已經開始這樣思考:將有遙測和無遙測的 gopls 開發做比較時,遙測勝出。

來自遙測功能的臭蟲中最令人驚訝的方面是有多少個是實際存在的。當然,其中有些對使用者而言不可見,但其中不少實際上是 gopls 的錯誤行為,例如在特定罕見狀況下缺少交叉參照或完成度略有偏差。它們正是某個使用者可能會感到些許惱怒,但可能不會費心回報為問題的那種類型。使用者也許會假設這個行為是故意的。如果他們回報了問題,他們可能不確定如何重現臭蟲,或者我們需要在問題追蹤器上經過一番冗長的來回討論來擷取堆疊追蹤。若沒有遙測,沒有合理的方法能讓大部分這些臭蟲被發現,更不用說修正它們了。
而且這一切都只是來自幾個計數器。我們只為已知的潛在臭蟲加入堆疊追蹤的工具。而我們沒想到的問題呢?
自動化崩潰報告
1.23 版的 Go 新增了一個 runtime.SetCrashOutput
API,可用於透過監控器程式實作自動當機回報。從 0.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 開發人員的地方。
Go 將於今年 11 月滿 15 年,不論程式語言或其生態系統都持續在成長。遙測資料將扮演關鍵角色,協助 Go 貢獻者加快腳步,朝正確的方向更安全的邁進。
下一篇文章:分享您使用 Go 進行開發的意見回饋
上一篇文章:新的 unique 套件
網誌索引