The Go Blog
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テレメトリーの最初のイテレーションは、2023年10月にGo言語サーバーgoplsのv0.14でリリースされました。リリース後、リリースノートやGophers Slackチャネルでの議論に動機付けられたのか、約100人のユーザーがアップロードを有効にし、データが少しずつ流れ込み始めました。テレメトリーがgoplsで最初のバグを発見するのに時間はかかりませんでした。
IDEによるプロンプト表示
テレメトリーが実際に機能しているのを見るのは素晴らしく、これらの早期採用者のサポートに感謝しましたが、測定したい種類のものを測定するには100人の参加者では不十分です。
Russ Coxが元のブログ投稿で指摘したように、テレメトリーのデフォルトでオフのアプローチの欠点は、継続的に参加を促す必要があることです。意味のある定量データ分析に十分な大きさで、ユーザー集団を代表するユーザーサンプルを維持するには、アウトリーチが必要です。ブログ投稿やリリースノートは参加を促進できますが（これを読んだ後にテレメトリーを有効にしていただければ幸いです！）、偏ったサンプルにつながります。例えば、goplsにおけるテレメトリーの早期採用者からは、GOOS=windowsのデータがほとんど得られませんでした。
より多くのユーザーにリーチするために、VS Code Goプラグインに、ユーザーがテレメトリーを有効にするかどうかを尋ねるプロンプトを導入しました。
このブログ記事の執筆時点では、プロンプトはVS Code Goユーザーの5%に展開されており、テレメトリーサンプルは毎週約1800人の参加者に増加しています。
（最初の急増は、VS Code Go nightly拡張機能の**すべての**ユーザーにプロンプトが表示されたことによるものと思われます）。
しかし、最新のGoアンケート結果と比較して、VS Codeユーザーへの顕著な偏りが生じています。
言語サーバープロトコル自体の機能を使用して、goplsを使用する**すべてのLSP対応エディタにプロンプトを表示**することで、この偏りに対処する計画です。
テレメトリーの成功事例
慎重を期して、goplsでのテレメトリーの初期起動のために、いくつかの基本的なメトリクスのみの収集を提案しました。そのうちの1つはgopls/bugスタックカウンターで、goplsが遭遇した予期せぬ、または「不可能な」状態を記録します。これは実質的にアサーションの一種ですが、プログラムを停止させるのではなく、その実行で到達したことをテレメトリーにスタックとともに記録します。
goplsのスケーラビリティ作業中に、このようなアサーションを多数追加しましたが、テストや私たち自身のgoplsの使用では、それらが失敗するのをほとんど観察しませんでした。これらのアサーションのほとんどは到達不可能であると予想していました。
VS Codeでランダムなユーザーにテレメトリーを有効にするよう促し始めたところ、これらの条件の多くが実際に**到達**しており、スタックトレースのコンテキストが、長年のバグを再現して修正するのに十分であることがよくありました。テレメトリーによって促進された「成功事例」を追跡するために、これらの問題をgopls/telemetry-winsラベルの下で収集し始めました。
私は「テレメトリーの成功事例」を別の意味で考えるようになりました。テレメトリーの有無にかかわらずgoplsの開発を比較すると、**テレメトリーが勝利する**と。
テレメトリーから来るバグの中で最も驚くべき点は、それらの多くが**本物**であったことです。確かに、一部はユーザーには見えないものでしたが、かなりの数がgoplsの実際の誤動作でした。例えば、相互参照の欠落や、特定のまれな条件下でのわずかに不正確な補完などです。これらはまさに、ユーザーがわずかに不快に感じるかもしれないが、おそらく問題として報告する手間をかけないような種類のものでした。おそらくユーザーは、その動作が意図されたものであると仮定するでしょう。もし彼らが問題を報告したとしても、バグを再現する方法がわからないか、スタックトレースをキャプチャするために問題トラッカーで長いやり取りが必要になるでしょう。テレメトリーがなければ、これらのバグのほとんどは発見され、ましてや修正される**合理的な方法がありません**でした。
そして、これはわずかなカウンターから得られたものでした。**私たちが知っていた**潜在的なバグのためにスタックトレースを計測しただけでした。私たちが予想していなかった問題はどうでしょうか？
自動クラッシュ報告
Go 1.23には、ウォッチドッグプロセスを介して自動クラッシュ報告を実装するために使用できる新しいruntime.SetCrashOutput APIが含まれています。v0.15.0以降、goplsがクラッシュすると、**gopls自体がGo 1.23でビルドされている場合**、crash/crashスタックカウンターを報告します。
gopls@v0.15.0をリリースしたとき、私たちのサンプル中の少数のユーザーだけが、リリースされていないGo 1.23の開発ビルドを使用してgoplsをビルドしていましたが、新しいcrash/crashカウンターはまだ2つのバグを発見しました。
Goツールチェーンとそれ以降のテレメトリー
ほんのわずかな計測と目標サンプルの一部だけでもテレメトリーがどれほど有用であることが証明されたかを考えると、将来は明るいです。
Go 1.23は、goコマンドやコンパイラ、リンカー、go vetなどの他のツールを含むGoツールチェーン内でテレメトリーを記録します。私たちはvulncheckとVS Code Goプラグインにテレメトリーを追加しました。また、delveにも追加することを提案しています。
元のテレメトリーに関するブログシリーズでは、テレメトリーがGoを改善するためにどのように使用できるかについて多くのアイデアをブレインストーミングしています。私たちはそれらのアイデアなどを探求することを楽しみにしています。
gopls内では、テレメトリーを使用して信頼性を向上させ、意思決定と優先順位付けに役立てることを計画しています。Go 1.23で有効になった自動クラッシュ報告により、プレリリーステストでさらに多くのクラッシュを捕捉できると予想しています。今後、主要な操作のレイテンシ、さまざまな機能の使用頻度など、ユーザーエクスペリエンスを測定するためのカウンターを追加し、Go開発者に最も役立つ場所に私たちの努力を集中できるようにします。
Goは今年11月で15周年を迎えます。言語とそのエコシステムはともに成長を続けています。テレメトリーは、Goの貢献者がより速く、より安全に、正しい方向に進むのを助ける上で重要な役割を果たすでしょう。
次の記事: Goでの開発に関するフィードバックを共有してください
前の記事: 新しいユニークパッケージ
ブログインデックス