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 包
博客索引