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 构建的

当我们发布 [email protected] 时,我们样本中只有少数用户使用 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 包
博客索引