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テレメトリの最初のイテレーションは、2023年10月にGo言語サーバーgoplsのv0.14で出荷されました。リリース後、約100人のユーザーがアップロードを有効にしました。おそらくリリースノートやGophers Slackチャンネルでの議論に促されたのでしょう。そしてデータが少しずつ流れ始めました。すぐにテレメトリは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ラベルの下にこれらの問題を集約し始めました。
私は「テレメトリの成果」を2番目の意味で考えるようになりました。テレメトリの有無によるgopls開発を比較した場合、テレメトリの成果が勝ります。
テレメトリから得られたバグで最も驚くべき側面は、その多くが本物であったことです。確かに、その中にはユーザーに認識されないものもありましたが、かなりの数のものはgoplsの実際の誤動作、つまり、クロスリファレンスの不足や、特定のまれな条件下での微妙に不正確な補完などでした。これらは、ユーザーが多少イライラするようなことですが、おそらく問題として報告するほどではないようなものです。おそらく、ユーザーは、その動作が意図されたものだと仮定するでしょう。問題を報告した場合でも、バグを再現する方法が分からなかったり、スタックトレースを取得するために、イシュートラッカーで長々とやり取りする必要があったりするかもしれません。テレメトリがなければ、これらのバグの大部分は、発見されるどころか修正される妥当な方法がありませんでした。
そして、これはほんの一握りのカウンターからのものでした。私たちが知っている潜在的なバグのスタックトレースしか計測していませんでした。予期していなかった問題はどうでしょうか？
自動クラッシュレポート
Go 1.23には、監視プロセスを介して自動クラッシュレポートを実装するために使用できる新しいruntime.SetCrashOutput APIが含まれています。v0.15.0以降、gopls自体がGo 1.23でビルドされている場合、goplsはクラッシュ時に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での開発に関するフィードバックを共有する
前の記事：新しいuniqueパッケージ
ブログインデックス