https://chatgpt.com/c/67ce9f1f-db9c-800d-9f31-ca2e70dfbe45 私は、遠隔計測ワークロードのスケーリングにおける計測器のオーバーヘッドを削減するための方法と技術に関する研究レビューを行う。これには、リソース使用量の最小化、データ収集プロセスの最適化、精度を損なうことなく低遅延テレメトリーを確保するための戦略が含まれます。近日中に結果をご報告します。 はじめに 遠隔測定システムは、パフォーマンスと動作をモニターするために、ソフトウェアとハードウェアからメトリクス、ログ、トレースを収集します。これらのシステムが大容量のワークロードを扱うようにスケールするにつれ、計測のオーバーヘッド（テレメトリーの計測とエクスポートにかかる余分な CPU、メモリー、レイテンシーのコスト）が大きくなる可能性があります（Performance | OpenTelemetry ）。例えば、多すぎる関数をトレースしたり、メモリ使用量を肥大化させる高いカーディナリティのメトリクスを使用する場合など、過剰なインスツルメンテーションは、アプリケーションのパフォーマンスを低下させる可能性があります（Performance | OpenTelemetry ）。課題は、重いオーバーヘッドを課すことなく、豊富で正確な遠隔測定データを収集することです。この研究レビューでは、CPU とメモリーへの影響を最小化し、データ収集を最適化し、低レイテンシーの遠隔測定配信を保証する方法を検討します。我々は、効率的で軽量な計測、スマートなデータ削減（サンプリングとアグリゲーション）、システムレベルの最適化、効率的なネットワーク・モニタリングのためのアプローチなどのテクニックを探求します。また、既存のソリューションと新たなトレンドの比較分析も行います。 遠隔測定オーバーヘッドとスケーリングの課題 遠隔測定ワークロードが増大すると（より多くのサービス、より高いイベントレート、より多くのメトリクス）、「すべてを収集する 」という素朴なアプローチは維持できなくなります。計測はアプリケーションのリソースと競合する CPU サイクルとメモリを消費します。極端なケースでは、インスツルメンテーションコードは、計測される実際の作業よりもアプリケーションを遅くする可能性があります（Performance | OpenTelemetry ）。高頻度のデータ収集や非常に詳細なトレースは、インスツルメンテーションがオペレーションをインターセプトするため、レイテンシが発生する可能性があります。さらに、大量の遠隔測定データ（例えば、毎秒数千のメトリクスやトレース・スパン）の転送は、ネットワークやストレージの I/O に負担をかける可能性があります。主な課題は以下の通りです： CPU オーバーヘッド： 記録された各メトリックやキャプチャされたトレース・スパンには CPU 時間がかかります。アプリケーション・コードとインラインで実行されるインスツルメンテーションは、リクエスト処理を長くする可能性があります。例えば、すべての関数呼び出しでトレーススパンを記録することは、同期的に行われた場合、自明でないオーバーヘッドを追加する可能性がある。高負荷の下では、オーバーヘッドは、テレメトリ量に比例して増加し、制御されなければ、コアを飽和させる可能性があります（3_29-JIP.dvi ）。 メモリのオーバーヘッド： テレメトリはデータ（メトリクス・バッファ、トレース・スパン・オブジェクト、ログ・キュー）を蓄積し、メモリを消費します。高いカーディナリティの遠隔測定（例えば、多くのユニークなラベルでタグ付けされたメトリクスや、全てのリクエストの詳細なトレース）は、大きなインメモリデータセットにつながる可能性があります（Performance | OpenTelemetry ）。インスツルメンテーションが、（いくつかのトレースライブラリがそうであるように）多くの短命のオブジェクトを作成する場合、それはまた、ガベージコレクションやメモリアロケータにプレッシャーをかけるかもしれません（Performance | OpenTelemetry）（Performance | OpenTelemetry ）。 レイテンシへの影響： クリティカルなコードパス上のインスツルメンテーションは、エンドユーザーの操作にレイテンシーを追加する可能性があります。例えば、Istio で最初に使用されたサービスメッシュコンポーネントは、リクエスト毎にテレメトリをアウトオブバンドで処理することで、測定可能なテールレイテンシのオーバーヘッドを導入した。小さなリクエスト毎の遅延であっても、規模が大きくなれば加算される可能性がある（Istio のテレメトリーのオーバーヘッドと MixerV2 の情報 - Policies and Telemetry - Discuss Istio ）。テレメトリが低レイテンシであることを保証することは、テレメトリ・データが素早くレポートされること（我々が最新の観測性を持つこと）と、それを収集する行為がプライマリ・ワークロードを大きく減速させないことの両方を意味する。 ネットワークとI/Oのオーバーヘッド： テレメトリーデータはしばしばエクスポート（ネットワークを介してコレクターに送信、またはディスクに保存）する必要がある。大量の高解像度テレメトリーは、かなりのネットワーク帯域幅やディスク I/O を消費します。例えば、トラフィックの多いサービスから全てのトレースをエクスポートすると、ネットワークやテレメトリバックエンドが水浸しになります。クラウド環境では、これもコストになります。従って、効率的なネットワーク使用は、遠隔測定スケーリングにおける懸念事項です。 精度とオーバーヘッドのトレードオフ：オーバーヘッドを直感的に削減すると（例えば、大量にサンプリングしたり、粗くアグリゲートしたりする）、テレメトリーの忠実度が損なわれる可能性があります。課題は、精度を失うことなくオーバーヘッドを最小化することであり、デバッグやパフォーマンス分析に役立つ十分な詳細を維持することである。 このような課題を理解することで、その課題に取り組む戦略を立てることができる。次に我々は、テレメトリを拡張しながら計測のオーバーヘッドを削減するために開発された具体的なテクニックと方法を掘り下げます。 軽量計測テクニック 主要な戦略の1つは、システム・リソースへの影響を最小限に抑える軽量計測手法を使用することです。これには、インスツルメンテーションを低レベル（カーネルまたはハードウェアに近い）に移動したり、オーバーヘッドが低くなるように設計された最適化フレームワークを使用したりすることがよく含まれます。 eBPFとカーネル・レベル・プローブ： eBPFは、Linuxカーネル内でサンドボックス化されたプログラムを実行し、イベント（システムコール、カーネルトレースポイントなど）にフックし、非常に低いオーバーヘッドでデータを収集することを可能にします（eBPFベースのインスツルメンテーション）。eBPF プログラムはカーネル空間で実行されるため、従来のエージェントのような高価なコンテキストスイッチやユーザー空間のオーバーヘッドを回避することができます（OpenTelemetry and eBPF: Everything You Need to Know ）。これにより、非常に効率的なデータ収集が可能になる。例えば、eBPF はカーネルのトレースポイントや kprobe にアタッチしてイベントを記録し、リング・バッファやマップを使ってデータをユーザー空間にバッチ転送することで、オーバーヘッドを大幅に削減することができます。カーネル・モジュールや侵入的なコード変更を必要とする旧来の手法とは異なり、eBPFはアプリケーション・コードやカーネルを変更することなく、低オーバーヘッドのモニタリングを実現している（OpenTelemetry and eBPF: Everything You Need to Know）（OpenTelemetry and eBPF: Everything You Need to Know ）。eBPFベースのモニタリングは、多くの場合、本番環境でのCPUオーバーヘッドを1%以下に抑えることができると報告されている(open-telemetry/opentelemetry-ebpf-profiler - GitHub)。あるエンジニアは、eBPFカーネル・プローブとリング・バッファを経由して、アプリケーションに目立ったCPUオーバーヘッドを与えることなく、全てのネットワーク・パケット（毎秒100万パケット）をトレースすることができた（All my favorite tracing tools: eBPF, QEMU, Perfetto, new ones I built and more - Tristan Hume ）。これは、カーネルレベルのインスツルメンテーションがいかに効率的に高いイベント・レートにスケールできるかを例証している。多くの可測性ツールは現在、eBPFをメトリクスやトレースの収集（例えばHTTPリクエストのレイテンシーやTCPコネクション・イベントのキャプチャ、あるいは継続的なプロファイリングなど）に活用している（OpenTelemetry and eBPF: Everything You Need to Know ）（OpenTelemetry and eBPF: Everything You Need to Know ）。 静的で効率的なトレースポイント： オペレーティング・システムは、低オーバーヘッドに最適化された組み込みの計測ポイントを提供する。例えば、Linuxのftraceやperfイベント、あるいはWindowsのETW（Event Tracing for Windows）は、コード内で静的なトレースポイントを使用します。アプリケーションコードに新しいインスツルメンテーションを追加する代わりに）これらのOSが提供する機能を使うことで、オーバーヘッドを減らすことができる。これらの機能はシステムレベルで動作し、多くの場合バイナリー・トレース・ログと高性能バッファを活用する。リアルタイム・システムやカーネルでは、これらのスタティック・トレースポイントは、イベントあたり数ナノ秒という速さで設計されている（私のお気に入りのトレース・ツールはすべて、eBPF、QEMU、Perfetto、私が構築した新しいものなど - Tristan Hume ）。開発者は、必要なトレースポイント（例えば、スケジューリングイベントやI/Oイベント）だけを有効にして、システムの他の部分への影響を最小限に抑えながらテレメトリを収集することができます。 非同期かつ非侵入的な計測： 軽量な計測とは、メインの実行をブロックしたり遅くしたりしないことも意味します。テレメトリーデータをメモリーのロックフリーのバッファやキューに書き込み、別のスレッドやエージェントに非同期で消費させるなどのテクニックは、干渉を最小限に抑えるのに役立ちます。アプリケーションスレッドは、イベントを記録するために、素早く、ノンブロッキングの書き込み（多くの場合、ほんの数個の CPU 命令）を実行するだけで、より重い処理（データのフォーマット、ネットワーク経由の送信）は、アウトオブバンドで行われる。これにより、クリティカル・パスに追加されるレイテンシが削減される。非侵入型インスツルメンテーション・フレームワークは、ビジネス・ロジックのすべてのファンクションにコードを挿入するのではなく、境界（ネットワーク・ソケット・コールやプロキシ経由など）でイベントをインターセプトする。例えば、Tsubouchiらによる アプリケーション非侵入型ネットワーク・トレース手法は、アプリケーション・コードをインスツルメンテーションするのではなく、サービスの依存関係をトレースするためにOSソケット・レベルでアタッチする(20240121_dissertation.pdf)。この方法では、カーネル内のeBPFプログラムを使用して、2.2%以下のCPUオーバーヘッドと、各ラウンドトリップに追加されるわずか6マイクロ秒のレイテンシで、ネットワークフローをバンドルして記録している(20240121_dissertation.pdf)。アプリケーション・ロジックへの変更を避けることで、高い接続率でもオーバーヘッドを一貫して低く抑えることができた。 最適化された遠隔測定ライブラリ： 計測がインプロセスでなければならない場合（例えば、OpenTelemetry のクライアントのようなアプリケーション・ライブラリ）、最適化されたライブラリを使うことが鍵になります。最近の遠隔測定ライブラリーは、オブジェクト・プーリング（メモリーの再利用）、メトリクスのバッチ処理、非常に効率的な同時実行制御（ロック・フリーまたは最小限のロック）などのテクニックを使用しています。また、CPUとI/Oのコストを削減するために、冗長なテキストの代わりにビットパックされたバイナリプロトコルを使用することもあります。例えば、OpenTelemetry のインスツルメンテーションは、かなり軽量に設計されていますが、それでも注意を推奨しています：自動トレース・インスツルメンテーションのような機能を全てのメソッドに使用すると、スパンが多すぎてオーバーヘッドが発生する可能性があります。ハイパフォーマンス環境（ゲームエンジンやトレーディングシステムなど）のカスタムインハウスソリューションの中には、外部ライブラリを使用せず、マクロやコンパイル時のインスツルメンテーションを使用して、ナノ秒スケールのオーバーヘッドでイベントをロギングするものもある（All my favorite tracing tools: eBPF, QEMU, Perfetto, new ones I built and more - Tristan Hume ）（お気に入りのトレースツール：eBPF, QEMU, Perfetto, new ones I built and more - Tristan Hume ）。よく設計されたインスツルメンテーション・メカニズムは、イベントごとに最小限の作業（多くの場合、タイムスタンプと必要なデータをバッファに書き込むだけ）を行うことに集中し、それ以上のことは行わないということだ。高価な処理（文字列のレンダリングなど）は、後回しにするか回避する。 要約すると、eBPFや効率的なトレース・ライブラリのような軽量な計測手法は、CPUとメモリの使用量を大幅に削減する。よりメタル（カーネルやハードウェア）に近いところで動作し、合理的な方法でデータを処理することで、パフォーマンスの観点から 「バックグラウンドに溶け込む 」遠隔測定収集が可能になる。次に、我々は、より多く収集するのではなく、よりスマートに収集することで、オーバーヘッドをさらに削減するデータ削減技術を見ていきます。 サンプリングとデータ削減戦略 オーバーヘッドを削減する効果的な方法は、単純に少ないデータを収集することである。サンプリング、アグリゲーション、フィルタリングは、遠隔測定量と CPU 使用量を調整する古典的なテクニックです： トレースとメトリックサンプリング： トレースとメトリックサンプリング：全てのイベントやリクエストを記録するのではなく、サンプリングは代表的なサブセットのみをキャプチャする。分散トレーシングでは、適応サンプリング戦略により、最も有用なトレースを保持する一方で、他のトレースを削除し、オーバーヘッドを劇的に削減することができます。リクエストパターンに基づく適応サンプリングは、クリティカルパスの洞察を維持しながら、計測のオーバーヘッドを65%まで削減できることが研究で示されています（The procedure of observability SMS | Download Scientific Diagram）。例えば、トレースシステムはリクエストの X% だけをサンプリングしたり、テールベースのサンプリングを使って、エラーや高いレイテンシを示す全てのトレースを保持し、ルーチンなものはサンプリングしないようにするかもしれない。OpenTelemetry と他のトレースフレームワークは、オーバーヘッド対データ量のトレードオフをコントロールするために、正確に設定可能なサンプリングポリシーを提供します (Performance | OpenTelemetry)。サンプルレートをチューニングすることによって（例えば、10リクエストに1つだけとか、100リクエストに1つだけフルトレースするとか）、組織はトレーサーが CPU やネットワークを圧倒しないようにする（Performance | OpenTelemetry ）。同様に、メトリクス収集はサンプリングすることができる - 例えば、センサーを毎秒 1000 回読み取る代わりに、100 回読み取り、可能であれば外挿する。重要なのは、システムの動作変化を捕捉できるレートを選択することです。プラットフォームによっては、アダプティブ・サンプリング（適応型サンプリング）を採用しているものもある。これは、サンプリング・レートが負荷やデータの変動性に基づいて動的に調整されるもので、通常運用時にはオーバーヘッドを最小限にとどめ、異常が発生した場合はサンプリングを細かくして詳細を捕捉する。この適応的なアプローチにより、両世界のベストバランスが得られる。 集約と前処理： テレメトリーデータをソースで集約することで、多くのユースケースで忠実度の損失を最小限に抑えながら、エクスポートする必要のあるボリュームを大幅に縮小することができる。例えば、アプリケーションは何千もの同じようなイベント（例えば HTTP リクエスト）を経験するかもしれない。インスツルメンテーションは、各イベントをロギングするのではなく、カウンターやサマリー（例えば、1分あたりのリクエスト数やレイテンシーのパーセンタイル）を保持し、定期的に集約された結果のみを出力することができます。これにより、CPU作業（処理するイベントが減る）とメモリ（1つの集約された記録と何千もの生の記録）が削減される。スケーラブル・テレメトリー設計の核となる原則は、コンテキストが豊富なところでデータ削減を適用することである。アプリケーション・コンテキストの知識があれば、冗長なデータを組み合わせたり、フィルタリングしたりすることができる。例えば、MetricSifterアプローチ（Tsubouchiet al.）は、時系列メトリクスを分析し、与えられた障害シナリオに無関係なメトリクスをフィルタリングすることで、関連するメトリクスのみに焦点を当て、メトリクスの数を効果的に削減します（20240121_dissertation.pdf ）。より一般的には、遠隔測定システムはしばしばロールアップ・カウンター、ヒストグラム、スケッチを採用している。スケッチ（レイテンシの分位スケッチのようなもの）は、全ての個々の測定値の代わりに、非常にメモリ効率の良い近似分布を送信することを可能にする。 フィルタリングと選択的計測： すべての指標やスパンが同じように価値があるわけではありません。不要な計測をオフにすることで、オーバーヘッドが削減されます。オペレーターは、冗長なモジュール（例えば、SQL クエリーのトレースや細かいデバッグ・ログ）を、必要でない時に無効にすることができます（パフォーマンス | OpenTelemetry ）。多くの遠隔測定エージェントは、実行時に特定のデータ収集を有効/無効にする設定オプションをサポートしています。例えば、OpenTelemetry Java エージェントは、（JDBC トレースのような）特定のインスツルメンテーションがうるさすぎる場合、それを無効にすることができます（パフォーマンス | OpenTelemetry ）。これは、それらのコンポーネントが実行されるのを防ぎ、CPUを節約します。同様に、重要度によってイベントをフィルタリングすることができる - 例えば、全ての情報ログではなく、警告とエラーだけをログに残す。コンテキストベースのフィルタリングは強力だ：ソースで、コンテキストに基づいて何を記録するかを決定する。多くのマイクロサービスを経由するユーザーリクエストは、エラーフラグが検出されない限り、オーバーヘッドを減らすために1つか2つの主要なサービスでのみトレースされるかもしれない。このような動的なテレメトリーは、システムが異常の詳細を増加させ、ルーチン操作の詳細を低下させることができる。 早期に（エッジで）削減を適用する： 最近の研究によるアーキテクチャのガイドラインは、可能な限り早い段階でデータを削減することである。インスツルメンテーション・レイヤー（アプリやホスト内）で集約やサンプリングを行うことで、我々は詳細なコンテキストを活用し、どのデータを組み合わせたり省略したりできるかについて、情報に基づいた決定を行うことができる（20240121_dissertation.pdf ）。これにより、どうせ後で集計されるだけの大きな生の遠隔測定ストリームを転送するリソースの無駄を省くことができる。例えば、カーネル内のネットワークフローモニタは、ユーザ空間に送信する前に、多くの小さなソケットイベントを1つのサマリーレコードにまとめるかもしれない（例えば、同じサービスへの複数の短いTCPコネクションをバンドルする）(20240121_dissertation.pdf)。このカーネル内フローバンドルアプローチは、ユーザー空間のフローレコードを減らし、実験ではCPU使用率を大幅に削減した(20240121_dissertation.pdf)。このコンセプトは、様々なシステムで採用されている。例えば、ログ行を組み合わせたり、メトリクスを事前に計算したり、不要な詳細を削除したりといった、よりスマートな収集を、可能な限りソースの近くで行う。こうすることで、パイプラインを通じて伝搬されるデータが少なくなり、下流の各コンポーネントの負荷が軽減される。 サンプリングとアグリゲーションを注意深く使用することで、遠隔測定システムは、モニタリングに必要な主要シグナルを保持したまま、リソースのフットプリントを桁違いに縮小することができる（多くの場合、生データの1～10％しか収集しない）。これらの技術は、精度が許容できるように調整されなければならない。例えば、エラー・イベントが決してサンプリングされないようにしたり、集約されたメトリクスが依然として精度要件を満たすようにする。うまくいけば、データ削減は遠隔計測のエンドユーザーにはほとんど見えません（エンジニアは必要な洞察を得ることができます）。 バッチ処理と効率的なデータ処理 テレメトリーデータがどのようにバッファリングされ送信されるかは、オーバーヘッド、特にレイテンシとCPU使用率に大きく影響します。バッチングは、複数のデータポイントにわたってオーバーヘッドを償却するための一般的なテクニックです： テレメトリ・エクスポートのバッチ化： テレメトリのエクスポートをバッチ化する：テレメトリを一度にひとつずつ（例えば、すべてのトレーススパンやメトリックを個別のネットワークメッセージとして）送信するのは非効率的です。メッセージが小さいと、ネットワークコールや I/O 操作の固定オーバーヘッドが支配的になります。複数の遠隔測定レコードを一緒にバッチすることで、我々は送信やディスク書き込みをより少ない頻度で呼び出します。これにより、CPU 割り込み/コンテキストスイッチが減り、スループットが向上します。例えば、OpenTelemetryのコレクターとエージェントは、バッチスパンプロセッサーを使用し、短いインターバル（例えば5秒または最大Nスパン）のスパンを集約し、それらを一度に送信します。DoorDashのエンジニアは、バッチスパンプロセッサーを使用することで、テレメトリーパイプラインのスループットが大幅に向上し、CPU使用率が下がることを発見した（OpenTelemetryのスパンプロセッサーを高スループットのために最適化 ... ）。クラウド・テレメトリーでは、即時送信からバッチ送信に切り替えることで、スループットが5～10倍向上するのが一般的です。 調整可能なバッチサイズ（遅延とCPUのトレードオフ）： バッチサイズが大きいと、リソースをより効率的に使用できる（アイテムあたりのオーバーヘッドが少ない）が、各アイテムを配信する際の待ち時間が長くなる（バッチ内で待機するため）。システムには、バッチサイズを調整するためのつまみが用意されていることが多い。例えば、Istio のテレメトリの以前のバージョンには、プロキシからデータを収集するコンポーネント（Mixer）があった。オーバーヘッドを減らすために、開発者はレポート呼び出しのバッチサイズのコントロールを導入した（Istio のテレメトリのオーバーヘッドと MixerV2 の情報 - ポリシーとテレメトリ - Istio について）。バッチサイズを大きくすることで、1メッセージあたりのCPUオーバーヘッドを減らすことができます（呼び出し回数が減ります）。あるチームでは、バッチ処理は助けになるものの、ある点を超えるとリターンが減少すると指摘している（Istio telemetry overhead and MixerV2 info - Policies and Telemetry - Discuss Istio ）。一般的な原則は、可観測性のためのレイテンシ要件に違反することなく、可能な限りバッチ処理することである。多くの最新の可観測性システムは、バッチ処理による大きな効率向上と引き換えに、小さな遅延（せいぜい数秒）を好む。 バッファリングとバックプレッシャー：効率的な遠隔測定パイプラインは、遠隔測定の生成と消費を切り離すために、インメモリバッファ（多くの場合、ロックフリーのキューやリングバッファ）を使用します。インスツルメンテーションはバッファに素早く書き込み、次に進みますが、バックグラウンドのスレッドやエージェントはバッファから読み込み、データを処理/送信します。このバッファリングはスパイクを滑らかにし、遠隔測定バックエンドのスローダウンでアプリケーションがブロックされるのを防ぎます。オーバーヘッドを最小化するために、これらのバッファは多くの場合、共有メモリ内の固定サイズのリングバッファです - 非常に高速な書き込みと読み取りが可能ですが、コンシューマが遅れをとった場合、古いデータを上書きする可能性があります（アプリを停止するのではなく、プレッシャーの下で優雅にデータをドロップします）。この設計は、遠隔測定収集がアプリケーションを停止させないことを保証する。これは、多くの高性能ロガーと計測システムで使用されている。例えば、eBPFのユーザー空間とのやり取りは、カーネルが書き込み、ユーザー空間のリーダーが排出するリングバッファを使用します。この設計は、最小限のコピーとロックで大量のイベントを効率的に転送するために明示的に選択されました（eBPF based instrumentation ）（eBPFベースの計測）。 圧縮とエンコード： 厳密にはCPUの 「オーバーヘッド 」ではないが、データがどのようにエンコードされるかは、ネットワークのオーバーヘッドや、エンコード/デコードのためのCPUに影響を与える可能性がある。テレメトリーシステムは、バイナリプロトコルを使用することが多くなり、大きなデータのバッチは圧縮されます。例えば、OpenTelemetryはバイナリのProtobufフォーマットでメトリクスをエクスポートすることができ、これはJSONのようなテキストフォーマットよりもはるかに小さく、解析が速い。いくつかのシステムは、ネットワーク・ペイロードを5-10倍削減するために、送信前に（例えばgzipやlz4を使って）バッチ化されたテレメトリーを圧縮します（Achieve a 10x Reduction in Telemetry Traffic Using OpenTelemetry ...）。圧縮はCPUを消費するが、バッチ処理であれば、特に帯域幅に制約のあるシナリオや、ストレージコストを下げるために、I/Oオーバーヘッドを削減するために、償却コストに見合う価値がある。 全体として、バッチ処理と最適化されたデータ処理により、遠隔測定データの移動が可能な限り効率的になります。その結果、CPU 使用率が下がり（システムコール、コンテキストスイッチの数が減る）、レイテンシが制御される（通常、数秒以下のオーダーで、ほとんどのモニタリングニーズには許容可能）。メトリックスとトレースをバッチ処理することは一般的なベストプラクティスであり、事実上すべての最新の遠隔測定フレームワークが、このようなことを行っています。 遠隔計測のためのシステムレベルの最適化 計測コードそのものだけでなく、基礎となるシステムとハードウェアにもオーバーヘッドを減らすチャンスがあります： ハードウェア・カウンターの活用： ハードウェア・カウンターの活用：最近のCPUはパフォーマンス・モニタリング・ユニット（PMU）を持っており、実行された命令、キャッシュ・ミス、分岐予測ミスなどのイベントを、ごくわずかなオーバーヘッドでカウントする。ツールはこれらのカウンターを利用することで、コードにインスツルメンテーションを行うことなく、遠隔測定（CPUサイクルやキャッシュ使用量など）を行うことができます。これらのカウンターを定期的に（LinuxのperfやOSのAPIを使って）読み取ることは、すべての命令や関数コールを計測するよりもはるかに安上がりだ。同様に、いくつかのNIC（ネットワークカード）は、フロー統計とエラーカウントを保持しており、ネットワーク・テレメトリーのために読み取ることができる。このようなハードウェアのテレメトリー機能を利用することで、基本的にアプリケーションのコストはゼロで、システムレベルの洞察を得ることができる。 OSのスケジューリングと分離： オーバーヘッドを抑える一つの方法は、テレメトリ作業を専用の CPU コアか、少なくとも別々のスレッドに分離することです。遠隔測定コレクションを（可能であれば）別のコアで実行することで、メインのアプリケーションスレッドはモニタリングタスクとのコンテキストスイッチを避けることができます。これは高性能システムで見られるパターンである。例えば、1つのコアがメトリクスの集約と出荷を担当し、他のコアは邪魔されずにアプリケーションコードを実行できる。全体的なCPUコストは残るかもしれないが、クリティカルなリアルタイム・スレッドが影響を受けないように管理される。裏を返せば、テレメトリの低レイテンシが必要な場合、テレメトリスレッドに高い優先度を与えたり、迅速な処理を保証するためにリアルタイムスケジューリングを行うこともできますが、通常はアプリケーションが優先されます。目標は、干渉を防ぐことである。監視スレッドをうまくダウンさせるか、固定することで、そのオーバーヘッドがアプリのレイテンシ・スパイクとして現れないようにする。 ネットワーク・テレメトリーのためのカーネル・バイパス： ネットワーキングでは、多くのオーバーヘッドがカーネル・ユーザー間のコンテキスト・スイッチング（パケットがカーネルを通過し、解析のためにユーザー空間にコピーされる）から発生する可能性がある。XDP（eXpress Data Path）やDPDKのような技術は、カーネルの一部をバイパスしたり、ドライバー・コンテキストでカスタム・コードを実行することで、オーバーヘッドを少なくして高速にパケットを処理することを可能にする。テレメトリの場合、大量のネットワークトラフィックを検査する必要がある場合（例えば、フローごとの帯域幅を測定したり、異常を検出したりする場合）、XDPやDPDKベースのエージェントを使用することで、標準的なソケットキャプチャを使用するよりもはるかに低いCPUで数百万のパケットを処理することができます。基本的に、これらのテクニックは、合理的な方法でパケットを処理することで、カーネルネットワークスタックの汎用性を効率性と引き換えにします。サンプリング（例えばN個のパケットのうち1個だけを検査する）と組み合わせることで、これはネットワークの強力な低オーバーヘッド・モニタリング手法となる。 最適化された遠隔測定ストレージ： この質問は収集のオーバーヘッドに焦点をあてているが、システムレベルの最適化はテレメトリがどのように保存され、クエリされるかにまで及ぶことは注目に値する。例えば、高インジェストレートの遠隔測定システムは、最近のデータにはインメモリ時系列データベースを使用し、古いデータは（HeteroTSDBアプローチのように）ディスクにロールして、スピードとコストのバランスをとるかもしれない(20240121_dissertation.pdf)(20240121_dissertation.pdf)。効率的なストレージは、多くのデータを収集してもメモリやディスクを圧迫しないことを保証する。これは直接的に計測のオーバーヘッドを削減するわけではないが、遠隔計測パイプラインにおけるバックログやパフォーマンスの問題を防ぐことができる。 動的制御とフィードバック： システムレベルのビューは、遠隔計測の使用と収集の間のループを閉じることを可能にします。バックエンド分析が特定のデータが有用でないことを発見した場合、計測レイヤーにシグナルを送ることができます。逆に、より詳細が必要な場合（例えば、異常が検出された場合）、システムは関連するメトリクスの収集を一時的に増やすことができる。このフィードバック駆動型遠隔測定システムのコンセプトは、活発な研究の方向性である(20240121_dissertation.pdf)(20240121_dissertation.pdf)。これは、ほとんどの時間オーバーヘッドを最小化し（必要なものだけを収集する）、必要なときにデータ収集のコンテキストを意識したブーストを保証するものである。この実装にはシステム全体の調整（計測、ストレージ、分析レイヤーの通信）が必要だが、クラウド環境では最新のオーケストレーションとコントロールプレーンによって容易になる。 要約すると、システムレベルの最適化は、効率的な遠隔測定を実行するための基盤を提供する。カーネル、ハードウェア、スマートなリソース管理を利用することで、テレメトリのオーバーヘッドをシステムの 「ファブリック 」の中にさらに隠すことができる。これらのテクニックの多くは、成熟したモニタリング製品の舞台裏にあります - ユーザーは、これらの最適化のおかげで、モニタリングをオンにしても、期待したほど遅くならないことに気づくだけかもしれません。 テレメトリーのための効率的なネットワーク・モニタリング ネットワーク・テレメトリーは、スケールの大きなネットワーク・モニタリングが非常にデータ集約的であるため、特別な注目に値する。ネットワーク・トラフィックとコネクションのモニタリングは（パフォーマンスとセキュリティのために）極めて重要だが、ナイーブに全てのパケットをキャプチャしたり、全てのコネクションをロギングしたりすると、システムを圧倒する可能性がある。ネットワーク・テレメトリのオーバーヘッドを減らす戦略には以下が含まれる： フロー・サンプリング（NetFlow/sFlow）： 従来のネットワーク・テレメトリーは、パケット単位のロギングではなく、フロー記録を使用することが多い。例えば、Cisco の NetFlow とより最新の sFlow プロトコルは、N 個のパケットのうち 1 個のパケット（または N 個のフローのうち 1 個のフロー）をサンプリングし、フローに関するサマリー統計（ソース、宛先、バイトなど）を記録します。特にsFlowは軽量に設計されている。サンプリングは通常スイッチ/ルーターのハードウェアで行われ、エージェントはサンプリングされたデータを受信するだけである。これにより、トラフィックの統計的な画像を提供しながら、CPU使用率を低く抑えることができる。大規模なデータ・センターでは、オペレータは1:1000または1:10000のパケット・レートでサンプリングすることがありますが、これはすべてのイベントを処理しなくても、トレンドや大ヒットを検出するのに十分です。 カーネル・レベルのソケット・トレース： eBPFのような技術（または他のシステムでは歴史的にSystemTap/DTrace）を使用すると、低オーバーヘッドでカーネルレベルのネットワークイベント（TCP接続、アクセプト、送受信コールのような）をトレースすることができます。複数のTCP/UDPソケット・イベントをカーネル内の1つの論理フローに集約し、ユーザー空間に送信されるメッセージ数を削減した（20240121_dissertation.pdf ）。これにより、ネットワークフロー数が劇的に増加しても、CPUオーバーヘッドは2.2%以下に抑えられた(20240121_dissertation.pdf)。この効率性は、パケットごとやコネクションごとのコンテキスト・スイッチのオーバーヘッドを排除することに起因する。カーネルは、新しいコネクションごとにユーザー空間に通知する代わりに、アクティブなフローのハッシュ・テーブルを維持し、定期的に集約された情報をエクスポートするだけである。bcc (BPF Compiler Collection)やbpftraceのようなツールを使えば、このようなトレースを簡単に実装できる。例えば、BPFのコードを数行書くだけで、プロセスごとにすべてのTCPコネクションをカウントしたり、HTTPリクエストのレイテンシを計測したりすることができる。これは、アプリケーションにプロキシや重いロギングを挿入するよりもはるかに少ないオーバーヘッドでスケールする効率的なネットワークモニタリングをもたらします。 ネットワークハードウェアのテレメトリー： いくつかの最先端のアプローチは、テレメトリーをネットワークデバイス自体に押し込みます。例えば、Inband Network Telemetry (INT)は、ネットワークスイッチがパケットにテレメトリーのメタデータを追加するものです（タイミング、キューの長さなどを記録します）。これは、オーバーヘッドを最適化されたスイッチ内の専用ASICに移し、サーバーを完全に解放する。INTや同様の技術は（主に先進的なデータセンター・ネットワークで）出現しつつあるが、これは遠隔測定にハードウェアを活用する傾向を示している。もう一つの例は、eBPFやP4プログラムを実行できるSmartNICやプログラマブルNICの使用である。SmartNICは、例えば、ホストCPUが関与することなく、フローごとにパケットをカウントしたり、ドロップを検出したりすることができる。ネットワーク・テレメトリーをハードウェアにオフロードすることは、ホストのCPUオーバーヘッドがほぼゼロになり、非常に忠実なモニタリングができる可能性があることを意味するが、それには高度な機器が必要である。 低オーバーヘッドのプロトコルとストリーミング： 従来のネットワーク統計の取得方法（SNMPポーリングのような）は、実はあまり効率的でタイムリーではありません。新しいストリーミング・テレメトリー・アプローチは、デバイスやエージェントからの持続的な接続（多くの場合gRPCやMQTTベース）を維持し、メトリクスを継続的にストリーミングします。これは、リクエスト毎のポーリングのオーバーヘッドを回避し、より低レイテンシのアップデートをもたらします。ソフトウェアシステムでは、ログ／メトリクスにストリーミングアプローチを使用する（例えば、protobufメッセージで単一のTCP接続を介してデータをプッシュする）ことは、多くの接続やHTTPコールを開くよりもCPUおよびネットワーク効率が高い。例えば、FacebookのOsqueryや同様のエージェントは、イベントをストリームするためにアクティブなソケットを維持し、定期的なポーリングよりも効率的であることが証明されている。 ネットワークデータのエッジ集約： 一般的なデータ削減と同様に、ネットワーク・テレメトリーも階層的アグリゲーションから恩恵を受けることができる。各ホスト上のエージェントはそのホスト上の接続の全てのメトリクスを集約し、中央システムが全ての接続の生データを受信するのではなく、1つのサマリーを中央システムに送信するかもしれない。より高いレベルでは、データをさらに要約する中間アグリゲータ（おそらくラックまたはクラスタごとに1つ）を持つことができる。これは、コンテンツ・デリバリー・ネットワークや大規模なモニタリング・セットアップが、スケールアップするためにコレクターのツリーを使用する方法に似ている。各レイヤーは量を減らし、単一のボトルネックリンクやノードが完全な生フィードを処理する必要がないようにする。その結果、データがメインの分析ポイントに到達するまでに、その量は削減され、管理しやすくなり、ネットワークや処理ノードへのストレスが軽減されます。 効率的なネットワーク・モニタリングは、スマートなサンプリング、低レイヤー（カーネル／ハードウェア）の活用、アーキテクチャ設計（分散収集）の組み合わせである。上記のアプローチは、非常に高い帯域幅のネットワーク（マルチギガビット、数百万フロー）であっても、低いオーバーヘッドで監視できることを示している。Cilium Hubble（ネットワークの可観測性のために）や CloudFlare のネットワークパフォーマンス監視のための eBPF の使用（eBPF - Introduction, Tutorials & Community Resources ）のようなツールにおける eBPF のようなテクニックの成功は、ネットワーク遠隔測定がもはや遅い、重い方法に頼る必要がないことを強調している。 ソリューションの比較分析 テレメトリー計測には複数のソリューションが存在し、それぞれにオーバーヘッドの点で長所と短所があります。我々はいくつかのカテゴリーを比較する： アプリ内計測 vs. 外部モニタリング： アプリケーション内ライブラリ（コードに統合された OpenTelemetry SDK のような）は、豊富なコンテキストと柔軟性を提供しますが、ユーザースペースで実行され、アプリケーションプロセスでオーバーヘッドを発生させます。外部モニタリング（eBPF ベースやサイドカー・エージェントの使用など）は、アプリへの影響を少なくして、同様のデータを収集できることがあります。例えば、OpenTelemetry 自動計測エージェントは、トレースのために各リクエストに数ミリ秒のオーバーヘッドを追加するかもしれないが、eBPF ベースのツールは、サブミリ秒のオーバーヘッドでシステムコールを監視することで、同じリクエストをトレースすることができる（OpenTelemetry and eBPF: Everything You Need to Know ）。トレードオフは、アプリ内インスツルメンテーションは、低レベルのツールが知らないかもしれない、より高いレベルのセマンティクス（アプリケーション変数、カスタムスパン）を捕らえることができるということです。アプリケーション固有のデータには OpenTelemetry を使い、システムレベルのテレメトリにはそれを補完する eBPF を使い、それらを組み合わせて全体像を把握するというハイブリッドなアプローチが出現しつつある。 エージェントベースの遠隔測定とエージェントレス： 従来の APM ソリューション（New Relic、Datadog など）は、コードを計測する言語固有のエージェントを使用することが多い。これらはかなり最適化できますが、それでもアプリの一部として実行されます。新しいエージェントレスまたは 「ゼロ計測」アプローチは、プラットフォームやホストの機能を使用することで、そのオーバーヘッドを回避しようとしている。例えば、マネージド・ランタイムからいくつかのデータを自動収集できるGoogle Cloudのオペレーション・スイートや、重いコードを注入することなくデータを収集するためにWindows上のパフォーマンス・カウンターとイベント・トレーシングを使用できるAzureのアプリケーション・インサイトなどがある。エージェントレスアプローチは、CPUオーバーヘッドを低くする傾向があるが、アプリ内エージェントが捕捉する全てを捕捉しないかもしれない。OpenTelemetryはその両方を提供します：エージェントと一緒に使うことも（自動計測）、手動で計測することもできます。実際には、多くの場合、オーバーヘッドを減らすために、最小限の手動計測とインフラストラクチャシグナルへの依存を選択している。 eBPFとDTrace/SystemTapの比較： Linuxでは、eBPFは、安全性と低いオーバーヘッドにより、実運用ではSystemTapにほとんど取って代わられている。DTrace (on Solaris/macOS) と SystemTap (Linux) は、強力なダイナミック・インスツルメンテーションを可能にしますが、多くの場合、より高いコストと複雑さを伴います。eBPF の設計（ベリファイア、ネイティブ・コードへの JIT コンパイル）は、非常に効率的な実行につながります（OpenTelemetry and eBPF: Everything You Need to Know ）（OpenTelemetry and eBPF: Everything You Need to Know ）。SystemTapは対照的に、より高いオーバーヘッドとリスクを持つ可能性のあるカーネルモジュールを挿入します。DTraceは特定のプローブに対しては非常に効率的だが、Linuxでは広く利用できない。そのため、最新のLinux環境では、eBPFベースのソリューション（Cilium、Pixie、Groundcoverなど）が低オーバーヘッドの遠隔測定に適しているが、他のOS環境では、類似の機能（WindowsのETWやMacの軽量プロファイリングツールなど）が同様の役割を果たしている。 メトリクス vs. トレース vs. ログ： 異なるテレメトリーデータタイプは、本質的に異なるオーバーヘッドプロファイルを持っています。メトリクス（数値測定）は一般的に安価である。例えば、カウンターをインクリメントするだけで、通常O(1)であり、非常に高速です。うまく設計されたメトリクス・パイプラインは、集約によるオーバーヘッドを最小限に抑えながら、毎秒数百万のメトリクスを処理できます。ログは高価になる可能性があります：ログは、多くの場合、大量で、文字列を多用します。ログ行を書くには、文字列のフォーマットとI/Oが必要になり、その分遅くなります。規模が大きくなると、冗長なロギングは多くのCPUとI/Oを消費する可能性がある（これが、多くのシステムが本番環境でログレベルを下げている理由である）。トレースはその中間に位置します。大量に記録されますが（全てのリクエストは複数のスパンレコードを生成するかもしれません）、構造化されており、サンプリングすることができます。一つのトレーススパンは、通常、いくつかのフィールド（タイムスタンプ、ID）を持つ小さなオブジェクトである。トレースのオーバーヘッドはサンプリングに依存する。ヘビーサンプリング (例えば1%)では、トレースのオーバーヘッドはわずかであるが、100%(全リクエストをトレース)では、かなりのオーバーヘッドになる。従って、遠隔測定ソリューションは、しばしば次のことを推奨します： 日常的なモニタリングにはメトリクスを使い（安価）、ログは控えめに使い（重要なイベントのみ）、サンプリングでトレースを使う。この組み合わせにより、管理可能なオーバーヘッドで良好なカバレッジが得られる。 商用APMツールとオープン・ソリューションの比較： 多くの商用ツールは、独自の最適化されたエージェント（Dynatraceのバイナリエージェント、New Relicのエージェントなど）を持っており、最小限のオーバーヘッドになるようにチューニングされています。OpenTelemetry のようなオープンソースのソリューションは柔軟性を提供するが、ユーザーが設定やチューニング（適切なサンプリングの設定など）を行う必要がある。オーバーヘッドに関しては、よく知られた APM エージェントは通常、CPU オーバーヘッドを一桁台の低いパーセンテージに抑え、メモリオーバーヘッドを数十 MB に抑えている。例えば、eBPF を使用した OpenTelemetry の継続的プロファイラでは、テストにおいて CPU は ~1%、RAM は 250 MB が上限とされており（open-telemetry/opentelemetry-ebpf-profiler - GitHub ）、これは多くのベンダーが宣伝しているものと同じである。違いは特定のワークロードに現れる。あるソリューションはトレースのための低いCPUオーバーヘッドが得意かもしれないが、別のソリューションはより多くのCPUを使うがメモリはより少ない、といった具合だ。傾向としては、オープンツールも商用ツールも、同様のベストプラクティス（可能な限りeBPFを使用する、作業をオフロードする、データを圧縮するなど）に収束しつつある。 古いアプローチと新しいアプローチ 歴史的に、システム・モニタリングは、頻繁なポーリング（topを呼び出したり、毎秒/procを読んだりするような）と大量のロギングに依存していた。新しいアプローチでは、イベント・ドリブン・テレメトリー、ストリーミング、インテリジェント・フィルタリングを使用する。例えば、全てのプロセスのCPU使用率を毎秒ポーリングする（これは多くのコードを目覚めさせる）代わりに、最近のエージェントはカーネルイベントを購読したり、プロセスが終了したりスケジューラのティックが発生したときに通知を受けるためにBPFを使用したりします。このように、新しいソリューションは一般的に、同じ情報に対してより少ないオーバーヘッドしか発生させません。実際に比較分析すると、次のようになる： TCPメトリクスを収集するためにeBPFを使用する場合、使用するCPUは2%未満であるのに対し、straceやlsofポーリングを使用するレガシー・アプローチでは10%以上のCPUを使用する可能性がある。改善は明らかであり、これらの技術が成熟するにつれて、古い高オーバーヘッドの技術は段階的に使用されなくなると我々は予想している。 ソリューションの比較において、システム（OSまたはカーネル）と深く統合し、スマートなフィルタリングを適用するものは、そのような最適化なしに高いレベルで動作するものを上回る傾向があることは明らかである。とはいえ、使いやすさやデータの完全性も要因のひとつである。目標は、許容できるオーバーヘッドで必要な可視性を提供するソリューションを選択することだ。多くの場合、組み合わせが最適である（例えば、eBPFベースのシステム可測性ツールと、ビジネスロジックのためのアプリケーションレベルのトレースを併用する）。 新たなトレンドと将来の方向性 遠隔測定と可観測性の分野は、オーバーヘッドを減らすことに重点を置いて、急速に進化しています。いくつかの新たなトレンドと研究の方向性は以下の通りです： 統一された遠隔測定パイプライン（可観測性パイプライン）： あらゆる種類のテレメトリ（ログ、メトリクス、トレース）をインジェストし、保存前に設定可能な方法（フィルタリング、サンプリング、ルーティング）で処理する集中型パイプラインへの動きがある。Grafana Mimir/Tempo、Honeycomb Refinery、Chronosphere のパイプラインのようなプロジェクトは、チームがインジェスト時に遠隔測定データに変換を適用することを可能にする。これは、価値の低いデータを早期に削除またはダウングレードすることで、オーバーヘッドを管理できることを意味する。これは可観測性のためのミドルウェアのようなもので、ポリシー（「サービスAからのトレースを10%でサンプリングする 」など）を一律に実施することができる。これらのパイプラインは、しばしばコストとオーバーヘッドの削減を主な目標としている - 例えば Chronosphere は、このようなテクニックによって、テレメトリーデータ量（とそれを処理するインフラ）の大幅な削減を主張している（Achieve a 10x Reduction in Telemetry Traffic Using OpenTelemetry ...）。この傾向は、テレメトリの肥大化を積極的に削減するために、組織がきめ細かいコントロールを望んでいることを示している。 「Use-First」 テレメトリー収集： 伝統的に、チームは可能な限り多くのデータを収集していました（「最初に収集し、後で質問する」）。現在では、「使用優先」（use-first）、つまり、予想される使用方法に基づいて、より選択的にデータを収集する方向にシフトしている（20240121_dissertation.pdf ）。最近の研究で提唱されているこの考え方は、フィードバックループのある遠隔測定システムの設計を示唆している。例えば、特定のメトリクスがダッシュボードやアラートで使用されていない場合、システムはリソースを節約するためにそれらのメトリクス収集を停止することができる。逆に、新たなパフォーマンス上の問題が発生した場合、システムは一時的にその領域のデータを追加収集するかもしれない。機械学習やアナリティクス（どの遠隔測定が有用かを特定する）を使ってこのプロセスを自動化することは、活発な分野である。最終的なゴールは、価値を提供するものだけを収集することでオーバーヘッドを最小化する、自己調整型遠隔測定システムである(20240121_dissertation.pdf)。初期の実装は、異常検知アルゴリズムに基づいてログレベルやメトリックの詳細を調整するAIOpsプラットフォームで見られる。 継続的プロファイリングとeBPF Everywhere： eBPFのような低オーバーヘッドの技術のおかげで、継続的プロファイリング（本番環境での常時CPU/ヒープ・プロファイリング）が登場した。Parca や Pixie、そして OpenTelemetry eBPF プロファイラのようなツールは、全てのプロセスのスタックトレースを高頻度かつ常時サンプリングすることができ、オーバーヘッドを最小限に抑えることができます（多くの場合、CPU は 1-2% 未満です）（open-telemetry/opentelemetry-ebpf-profiler - GitHub ）。以前は、オーバーヘッドのためにこのようなことは不可能で、プロファイリングはアドホックにしか行われなかった。傾向として、プロファイリングはテレメトリの標準的な一部となりつつあり、オーバーヘッドの削減によってメトリクス/トレースを補完している： GPUモニタリング、IPCモニタリングなどであり、Linux以外のシステムでも同様の技術が模索されている（例えば、Windows用のeBPFがプロトタイプ化されている）。我々は、eBPFベースのインスツルメンテーションがOpenTelemetryのようなフレームワークと統合され、開発者がハンドコーディングすることなく、また大きなパフォーマンスヒットを起こすことなく、多くのデータを取得できるようになることを期待している（eBPF based instrumentation - Odigos）（OpenTelemetry and eBPF: Everything You Need to Know）。 エッジとクライアントサイドの遠隔測定： アプリケーションはサーバーだけでなく、エッジ・デバイスやユーザー・クライアント（モバイル・アプリ、ブラウザ、IoTデバイス）にも及ぶため、これらから低いオーバーヘッドでテレメトリを収集することがフロンティアとなる。モバイルやウェブでは、オーバーヘッドがユーザーエクスペリエンス（バッテリー寿命、アプリのスムーズさ）に直接影響するため、遠隔測定は極めて軽量でなければならない。サンプリングや圧縮のような技術は、そこではさらに重要である。我々は、ブラウザがウェブアプリのために、テレメトリ（ナビゲーションのタイミングやリソースのタイミングなど）を低オーバーヘッドで提供するパフォーマンスAPIを実装しているのを見ている。IoT側では、デバイスは超小型のバイナリ遠隔測定を使用し、帯域幅とCPUを節約するために要約のみを送信する。エッジ遠隔測定とクラウド遠隔測定の融合には、全体のオーバーヘッドを低く抑え、データを階層的に集約するように、エンドツーエンドの最適化が必要になる。 機械学習による異常駆動型遠隔測定： もう一つのトレンドは、いつ何を収集するかを決定するためにMLを使用することである。例えば、MLモデルがサービスのメトリクスに異常を検出し、そのサービスのより詳細なトレースやロギングを短期間トリガーするかもしれない。こうすることで、問題がありそうなときだけオーバーヘッドが発生し、リソースの使用を必要性に合わせることができる。これらの 「インテリジェント・テレメトリー 」システムは実験的なものだが、適応型計測の考え方に沿ったものだ。もし成功すれば、定常状態のオーバーヘッドを大幅に削減し（物事が正常であれば、基本的な測定基準以上のオーバーヘッドはゼロに近い）、何か異常が起きたときだけオーバーヘッドを増加させることができる。 標準化と相互運用性： OpenTelemetryのような努力は、遠隔測定がどのように収集され、どのようにエクスポートされるかを統一している。これは直接オーバーヘッドを削減するものではないが、最適化を一箇所（SDK/エージェント）で実装でき、多くのツールに恩恵をもたらすことを意味する。例えば、OpenTelemetry SDK は、全てのバックエンドツールが使用できるバッチエクスポーターを提供するので、そこでの改善（より良いロックフリーのキューやよりスマートなサンプリングアルゴリズムなど）はエコシステム全体に伝搬します。さらに、OpenTelemetryとeBPFの統合（コードを変更することなく自動計測）が進められています（OpenTelemetry and eBPF: Everything You Need to Know）（OpenTelemetry and eBPF: Everything You Need to Know ）。OpenTelemetryとeBPFを組み合わせるというgroundcoverのアプローチはその一例です：eBPFを使ってデータを取り込み、それをOpenTelemetryのフォーマットにフィードします（OpenTelemetry and eBPF: Everything You Need to Know）（OpenTelemetry and eBPF: Everything You Need to Know ）。これは、標準的なテレメトリーデータフォーマットが、ボンネットの下の非常に効率的なキャプチャメカニズムによって満たされるトレンドになる可能性がある。 要するに、遠隔測定ワークロードのスケーリングの未来は、自己最適化され、プラットフォームと深く統合されるようだ。包括的なテーマは効率性であり、無駄を最小限に抑えて適切なデータを適切なタイミングで収集することである。新たなソリューションは、運用チームに忠実度の高い可視性を与え、システムを円滑に稼動させ、計測とパフォーマンスの間の従来の緊張関係を解決することを目指している。 結論 遠隔計測を大規模な分散システムに拡張するには、計測のオーバーヘッドに注意する必要がある。軽量な計測技術（eBPF や効率的なトレースポイントなど）、スマートなデータ削減（ソースでの適応的サンプリング、フィルタリング、集約）、システムレベルの最適化（バッチ処理、カーネルレベルのモニタリング、ハードウェアのサポート）を組み合わせることで、エンジニアは遠隔計測の CPU とメモリの使用量を劇的に削減することができる。これらの方法は、可観測性データを収集する際に、わずかなレイテンシ（多くの場合、マイクロ秒から数ミリ秒）と最小限のリソース競合しか発生させないことを保証し、アプリケーションのパフォーマンスを維持する。我々は、ネットワークフローのカーネル内集約のようなアプローチが、オーバーヘッドをCPUの数パーセント以下に抑えることができることを見てきた(20240121_dissertation.pdf)。また、アダプティブ・サンプリングは、データ量（とコスト）を半分以上に削減することができ、洞察の損失はごくわずかである(The procedure of observability SMS | Download Scientific Diagram)。 既存のソリューションは、統合されたAPMツールからオープンソースのフレームワークまで多岐にわたるが、オーバーヘッド削減のためのこれらのベストプラクティスを共有することが多くなっている。比較的、カーネル機能と非同期処理を活用する最新のソリューションは、古い、より侵入的な方法よりも効率性において明らかに優位に立っている（OpenTelemetry and eBPF: Everything You Need to Know ）。テレメトリのニーズが成長し続けるにつれ、業界はパフォーマンスのオーバーヘッドを最適化のための重要な指標として扱う全体的な可観測性アーキテクチャへと移行しています。ユビキタスeBPFの使用、フィードバック駆動型遠隔測定、統合パイプラインなどの新たなトレンドはすべて、高解像度でありながらコスト効果の高い可観測性を目指しています。目標は、オーバーヘッドに比例してスケールすることなく、量と詳細をスケールする可観測性スタックである。 要約すると、計測のオーバーヘッドを削減することは、遠隔計測収集において、よりハードに働くのではなく、よりスマートに働くことである。全てのレベル（アプリケーション、OS、ネットワーク）で巧みなエンジニアリングを行うことで、観測されるシステムへの影響を最小限に抑えながら、ほぼリアルタイムで詳細な遠隔測定を実現することができる。これによって、組織はワークロードの増大に応じて、「システムを可観測する」ことでシステムの動作が遅くなることを恐れることなく、自信を持ってモニタリングを拡大することができる。この分野での絶え間ない技術革新は、今後さらに効率的でインテリジェントな遠隔測定ソリューションを約束し、堅牢な可観測性が最高のパフォーマンスと両立することを保証します。 出典 (20240121_dissertation.pdf) (The procedure of observability SMS | Download Scientific Diagram) (eBPF based instrumentation) (OpenTelemetry and eBPF: Everything You Need to Know) (Performance | OpenTelemetry) (Performance | OpenTelemetry) (All my favorite tracing tools: eBPF, QEMU, Perfetto, new ones I built and more - Tristan Hume). 私は、テレメトリーワークロードのスケーリングにおける計測オーバヘッドを削減する方法と技術に関する研究レビューを行う。これには、リソース使用量の最小化、データ収集プロセスの最適化、精度を損なうことなく低遅延テレメトリーを確保するための戦略が含まれる。近日中に結果をご報告します。 はじめに 遠隔測定システムは、パフォーマンスと動作をモニターするために、ソフトウェアとハードウェアからメトリクス、ログ、トレースを収集します。これらのシステムが大容量のワークロードを扱うようにスケールするにつれ、計測のオーバーヘッド（テレメトリーの計測とエクスポートにかかる余分な CPU、メモリー、レイテンシーのコスト）が大きくなる可能性があります（Performance | OpenTelemetry ）。例えば、多すぎる関数をトレースしたり、メモリ使用量を肥大化させる高いカーディナリティのメトリクスを使用する場合など、過剰なインスツルメンテーションは、アプリケーションのパフォーマンスを低下させる可能性があります（Performance | OpenTelemetry ）。課題は、重いオーバーヘッドを課すことなく、豊富で正確な遠隔測定データを収集することです。この研究レビューでは、CPU とメモリーへの影響を最小化し、データ収集を最適化し、低レイテンシーの遠隔測定配信を保証する方法を検討します。我々は、効率的で軽量な計測、スマートなデータ削減（サンプリングとアグリゲーション）、システムレベルの最適化、効率的なネットワーク・モニタリングのためのアプローチなどのテクニックを探求します。また、既存のソリューションと新たなトレンドの比較分析も行います。 遠隔測定オーバーヘッドとスケーリングの課題 遠隔測定ワークロードが増大すると（より多くのサービス、より高いイベントレート、より多くのメトリクス）、「すべてを収集する 」という素朴なアプローチは維持できなくなります。計測はアプリケーションのリソースと競合する CPU サイクルとメモリを消費します。極端なケースでは、インスツルメンテーションコードは、計測される実際の作業よりもアプリケーションを遅くする可能性があります（Performance | OpenTelemetry ）。高頻度のデータ収集や非常に詳細なトレースは、インスツルメンテーションがオペレーションをインターセプトするため、レイテンシが発生する可能性があります。さらに、大量の遠隔測定データ（例えば、毎秒数千のメトリクスやトレース・スパン）の転送は、ネットワークやストレージの I/O に負担をかける可能性があります。主な課題は以下の通りです： CPU オーバーヘッド： 記録された各メトリックやキャプチャされたトレース・スパンには CPU 時間がかかります。アプリケーション・コードとインラインで実行されるインスツルメンテーションは、リクエスト処理を長くする可能性があります。例えば、すべての関数呼び出しでトレーススパンを記録することは、同期的に行われた場合、自明でないオーバーヘッドを追加する可能性がある。高負荷の下では、オーバーヘッドは、テレメトリ量に比例して増加し、制御されなければ、コアを飽和させる可能性があります（3_29-JIP.dvi ）。 メモリのオーバーヘッド： テレメトリはデータ（メトリクス・バッファ、トレース・スパン・オブジェクト、ログ・キュー）を蓄積し、メモリを消費します。高いカーディナリティの遠隔測定（例えば、多くのユニークなラベルでタグ付けされたメトリクスや、全てのリクエストの詳細なトレース）は、大きなインメモリデータセットにつながる可能性があります（Performance | OpenTelemetry ）。インスツルメンテーションが、（いくつかのトレースライブラリがそうであるように）多くの短命のオブジェクトを作成する場合、それはまた、ガベージコレクションやメモリアロケータにプレッシャーをかけるかもしれません（Performance | OpenTelemetry）（Performance | OpenTelemetry ）。 レイテンシへの影響： クリティカルなコードパス上のインスツルメンテーションは、エンドユーザーの操作にレイテンシーを追加する可能性があります。例えば、Istio で最初に使用されたサービスメッシュコンポーネントは、リクエスト毎にテレメトリをアウトオブバンドで処理することで、測定可能なテールレイテンシのオーバーヘッドを導入した。小さなリクエスト毎の遅延であっても、規模が大きくなれば加算される可能性がある（Istio のテレメトリーのオーバーヘッドと MixerV2 の情報 - Policies and Telemetry - Discuss Istio ）。テレメトリが低レイテンシであることを保証することは、テレメトリ・データが素早くレポートされること（我々が最新の観測性を持つこと）と、それを収集する行為がプライマリ・ワークロードを大きく減速させないことの両方を意味する。 ネットワークとI/Oのオーバーヘッド： テレメトリーデータはしばしばエクスポート（ネットワークを介してコレクターに送信、またはディスクに保存）する必要がある。大量の高解像度テレメトリーは、かなりのネットワーク帯域幅やディスク I/O を消費します。例えば、トラフィックの多いサービスから全てのトレースをエクスポートすると、ネットワークやテレメトリバックエンドが水浸しになります。クラウド環境では、これもコストになります。従って、効率的なネットワーク使用は、遠隔測定スケーリングにおける懸念事項です。 精度とオーバーヘッドのトレードオフ：オーバーヘッドを直感的に削減すると（例えば、大量にサンプリングしたり、粗くアグリゲートしたりする）、テレメトリーの忠実度が損なわれる可能性があります。課題は、精度を失うことなくオーバーヘッドを最小化することであり、デバッグやパフォーマンス分析に役立つ十分な詳細を維持することである。 このような課題を理解することで、その課題に取り組む戦略を立てることができる。次に我々は、テレメトリを拡張しながら計測のオーバーヘッドを削減するために開発された具体的なテクニックと方法を掘り下げます。 軽量計測テクニック 主要な戦略の1つは、システム・リソースへの影響を最小限に抑える軽量計測手法を使用することです。これには、インスツルメンテーションを低レベル（カーネルまたはハードウェアに近い）に移動したり、オーバーヘッドが低くなるように設計された最適化フレームワークを使用したりすることがよく含まれます。 eBPFとカーネル・レベル・プローブ： eBPFは、Linuxカーネル内でサンドボックス化されたプログラムを実行し、イベント（システムコール、カーネルトレースポイントなど）にフックし、非常に低いオーバーヘッドでデータを収集することを可能にします（eBPFベースのインスツルメンテーション）。eBPF プログラムはカーネル空間で実行されるため、従来のエージェントのような高価なコンテキストスイッチやユーザー空間のオーバーヘッドを回避することができます（OpenTelemetry and eBPF: Everything You Need to Know ）。これにより、非常に効率的なデータ収集が可能になる。例えば、eBPF はカーネルのトレースポイントや kprobe にアタッチしてイベントを記録し、リング・バッファやマップを使ってデータをユーザー空間にバッチ転送することで、オーバーヘッドを大幅に削減することができます。カーネル・モジュールや侵入的なコード変更を必要とする旧来の手法とは異なり、eBPFはアプリケーション・コードやカーネルを変更することなく、低オーバーヘッドのモニタリングを実現している（OpenTelemetry and eBPF: Everything You Need to Know）（OpenTelemetry and eBPF: Everything You Need to Know ）。eBPFベースのモニタリングは、多くの場合、本番環境でのCPUオーバーヘッドを1%以下に抑えることができると報告されている(open-telemetry/opentelemetry-ebpf-profiler - GitHub)。あるエンジニアは、eBPFカーネル・プローブとリング・バッファを経由して、アプリケーションに目立ったCPUオーバーヘッドを与えることなく、全てのネットワーク・パケット（毎秒100万パケット）をトレースすることができた（All my favorite tracing tools: eBPF, QEMU, Perfetto, new ones I built and more - Tristan Hume ）。これは、カーネルレベルのインスツルメンテーションがいかに効率的に高いイベント・レートにスケールできるかを例証している。多くの可測性ツールは現在、eBPFをメトリクスやトレースの収集（例えばHTTPリクエストのレイテンシーやTCPコネクション・イベントのキャプチャ、あるいは継続的なプロファイリングなど）に活用している（OpenTelemetry and eBPF: Everything You Need to Know ）（OpenTelemetry and eBPF: Everything You Need to Know ）。 静的で効率的なトレースポイント： オペレーティング・システムは、低オーバーヘッドに最適化された組み込みの計測ポイントを提供する。例えば、Linuxのftraceやperfイベント、あるいはWindowsのETW（Event Tracing for Windows）は、コード内で静的なトレースポイントを使用します。アプリケーションコードに新しいインスツルメンテーションを追加する代わりに）これらのOSが提供する機能を使うことで、オーバーヘッドを減らすことができる。これらの機能はシステムレベルで動作し、多くの場合バイナリー・トレース・ログと高性能バッファを活用する。リアルタイム・システムやカーネルでは、これらのスタティック・トレースポイントは、イベントあたり数ナノ秒という速さで設計されている（私のお気に入りのトレース・ツールはすべて、eBPF、QEMU、Perfetto、私が構築した新しいものなど - Tristan Hume ）。開発者は、必要なトレースポイント（例えば、スケジューリングイベントやI/Oイベント）だけを有効にして、システムの他の部分への影響を最小限に抑えながらテレメトリを収集することができます。 非同期かつ非侵入的な計測： 軽量な計測とは、メインの実行をブロックしたり遅くしたりしないことも意味します。テレメトリーデータをメモリーのロックフリーのバッファやキューに書き込み、別のスレッドやエージェントに非同期で消費させるなどのテクニックは、干渉を最小限に抑えるのに役立ちます。アプリケーションスレッドは、イベントを記録するために、素早く、ノンブロッキングの書き込み（多くの場合、ほんの数個の CPU 命令）を実行するだけで、より重い処理（データのフォーマット、ネットワーク経由の送信）は、アウトオブバンドで行われる。これにより、クリティカル・パスに追加されるレイテンシが削減される。非侵入型インスツルメンテーション・フレームワークは、ビジネス・ロジックのすべてのファンクションにコードを挿入するのではなく、境界（ネットワーク・ソケット・コールやプロキシ経由など）でイベントをインターセプトする。例えば、Tsubouchiらによる アプリケーション非侵入型ネットワーク・トレース手法は、アプリケーション・コードをインスツルメンテーションするのではなく、サービスの依存関係をトレースするためにOSソケット・レベルでアタッチする(20240121_dissertation.pdf)。この方法では、カーネル内のeBPFプログラムを使用して、2.2%以下のCPUオーバーヘッドと、各ラウンドトリップに追加されるわずか6マイクロ秒のレイテンシで、ネットワークフローをバンドルして記録している(20240121_dissertation.pdf)。アプリケーション・ロジックへの変更を避けることで、高い接続率でもオーバーヘッドを一貫して低く抑えることができた。 最適化された遠隔測定ライブラリ： 計測がインプロセスでなければならない場合（例えば、OpenTelemetry のクライアントのようなアプリケーション・ライブラリ）、最適化されたライブラリを使うことが鍵になります。最近の遠隔測定ライブラリーは、オブジェクト・プーリング（メモリーの再利用）、メトリクスのバッチ処理、非常に効率的な同時実行制御（ロック・フリーまたは最小限のロック）などのテクニックを使用しています。また、CPUとI/Oのコストを削減するために、冗長なテキストの代わりにビットパックされたバイナリプロトコルを使用することもあります。例えば、OpenTelemetry のインスツルメンテーションは、かなり軽量に設計されていますが、それでも注意を推奨しています：自動トレース・インスツルメンテーションのような機能を全てのメソッドに使用すると、スパンが多すぎてオーバーヘッドが発生する可能性があります。ハイパフォーマンス環境（ゲームエンジンやトレーディングシステムなど）のカスタムインハウスソリューションの中には、外部ライブラリを使用せず、マクロやコンパイル時のインスツルメンテーションを使用して、ナノ秒スケールのオーバーヘッドでイベントをロギングするものもある（All my favorite tracing tools: eBPF, QEMU, Perfetto, new ones I built and more - Tristan Hume ）（お気に入りのトレースツール：eBPF, QEMU, Perfetto, new ones I built and more - Tristan Hume ）。よく設計されたインスツルメンテーション・メカニズムは、イベントごとに最小限の作業（多くの場合、タイムスタンプと必要なデータをバッファに書き込むだけ）を行うことに集中し、それ以上のことは行わないということだ。高価な処理（文字列のレンダリングなど）は、後回しにするか回避する。 要約すると、eBPFや効率的なトレース・ライブラリのような軽量な計測手法は、CPUとメモリの使用量を大幅に削減する。よりメタル（カーネルやハードウェア）に近いところで動作し、合理的な方法でデータを処理することで、パフォーマンスの観点から 「バックグラウンドに溶け込む 」遠隔測定収集が可能になる。次に、我々は、より多く収集するのではなく、よりスマートに収集することで、オーバーヘッドをさらに削減するデータ削減技術を見ていきます。 サンプリングとデータ削減戦略 オーバーヘッドを削減する効果的な方法は、単純に少ないデータを収集することである。サンプリング、アグリゲーション、フィルタリングは、遠隔測定量と CPU 使用量を調整する古典的なテクニックです： トレースとメトリックサンプリング： トレースとメトリックサンプリング：全てのイベントやリクエストを記録するのではなく、サンプリングは代表的なサブセットのみをキャプチャする。分散トレーシングでは、適応サンプリング戦略により、最も有用なトレースを保持する一方で、他のトレースを削除し、オーバーヘッドを劇的に削減することができます。リクエストパターンに基づく適応サンプリングは、クリティカルパスの洞察を維持しながら、計測のオーバーヘッドを65%まで削減できることが研究で示されています（The procedure of observability SMS | Download Scientific Diagram）。例えば、トレースシステムはリクエストの X% だけをサンプリングしたり、テールベースのサンプリングを使って、エラーや高いレイテンシを示す全てのトレースを保持し、ルーチンなものはサンプリングしないようにするかもしれない。OpenTelemetry と他のトレースフレームワークは、オーバーヘッド対データ量のトレードオフをコントロールするために、正確に設定可能なサンプリングポリシーを提供します (Performance | OpenTelemetry)。サンプルレートをチューニングすることによって（例えば、10リクエストに1つだけとか、100リクエストに1つだけフルトレースするとか）、組織はトレーサーが CPU やネットワークを圧倒しないようにする（Performance | OpenTelemetry ）。同様に、メトリクス収集はサンプリングすることができる - 例えば、センサーを毎秒 1000 回読み取る代わりに、100 回読み取り、可能であれば外挿する。重要なのは、システムの動作変化を捕捉できるレートを選択することです。プラットフォームによっては、アダプティブ・サンプリング（適応型サンプリング）を採用しているものもある。これは、サンプリング・レートが負荷やデータの変動性に基づいて動的に調整されるもので、通常運用時にはオーバーヘッドを最小限にとどめ、異常が発生した場合はサンプリングを細かくして詳細を捕捉する。この適応的なアプローチにより、両世界のベストバランスが得られる。 集約と前処理： テレメトリーデータをソースで集約することで、多くのユースケースで忠実度の損失を最小限に抑えながら、エクスポートする必要のあるボリュームを大幅に縮小することができる。例えば、アプリケーションは何千もの同じようなイベント（例えば HTTP リクエスト）を経験するかもしれない。インスツルメンテーションは、各イベントをロギングするのではなく、カウンターやサマリー（例えば、1分あたりのリクエスト数やレイテンシーのパーセンタイル）を保持し、定期的に集約された結果のみを出力することができます。これにより、CPU作業（処理するイベントが減る）とメモリ（1つの集約された記録と何千もの生の記録）が削減される。スケーラブル・テレメトリー設計の核となる原則は、コンテキストが豊富なところでデータ削減を適用することである。アプリケーション・コンテキストの知識があれば、冗長なデータを組み合わせたり、フィルタリングしたりすることができる。例えば、MetricSifterアプローチ（Tsubouchiet al.）は、時系列メトリクスを分析し、与えられた障害シナリオに無関係なメトリクスをフィルタリングすることで、関連するメトリクスのみに焦点を当て、メトリクスの数を効果的に削減します（20240121_dissertation.pdf ）。より一般的には、遠隔測定システムはしばしばロールアップ・カウンター、ヒストグラム、スケッチを採用している。スケッチ（レイテンシの分位スケッチのようなもの）は、全ての個々の測定値の代わりに、非常にメモリ効率の良い近似分布を送信することを可能にする。 フィルタリングと選択的計測： すべての指標やスパンが同じように価値があるわけではありません。不要な計測をオフにすることで、オーバーヘッドが削減されます。オペレーターは、冗長なモジュール（例えば、SQL クエリーのトレースや細かいデバッグ・ログ）を、必要でない時に無効にすることができます（パフォーマンス | OpenTelemetry ）。多くの遠隔測定エージェントは、実行時に特定のデータ収集を有効/無効にする設定オプションをサポートしています。例えば、OpenTelemetry Java エージェントは、（JDBC トレースのような）特定のインスツルメンテーションがうるさすぎる場合、それを無効にすることができます（パフォーマンス | OpenTelemetry ）。これは、それらのコンポーネントが実行されるのを防ぎ、CPUを節約します。同様に、重要度によってイベントをフィルタリングすることができる - 例えば、全ての情報ログではなく、警告とエラーだけをログに残す。コンテキストベースのフィルタリングは強力だ：ソースで、コンテキストに基づいて何を記録するかを決定する。多くのマイクロサービスを経由するユーザーリクエストは、エラーフラグが検出されない限り、オーバーヘッドを減らすために1つか2つの主要なサービスでのみトレースされるかもしれない。このような動的なテレメトリーは、システムが異常の詳細を増加させ、ルーチン操作の詳細を低下させることができる。 早期に（エッジで）削減を適用する： 最近の研究によるアーキテクチャのガイドラインは、可能な限り早い段階でデータを削減することである。インスツルメンテーション・レイヤー（アプリやホスト内）で集約やサンプリングを行うことで、我々は詳細なコンテキストを活用し、どのデータを組み合わせたり省略したりできるかについて、情報に基づいた決定を行うことができる（20240121_dissertation.pdf ）。これにより、どうせ後で集計されるだけの大きな生の遠隔測定ストリームを転送するリソースの無駄を省くことができる。例えば、カーネル内のネットワークフローモニタは、ユーザ空間に送信する前に、多くの小さなソケットイベントを1つのサマリーレコードにまとめるかもしれない（例えば、同じサービスへの複数の短いTCPコネクションをバンドルする）(20240121_dissertation.pdf)。このカーネル内フローバンドルアプローチは、ユーザー空間のフローレコードを減らし、実験ではCPU使用率を大幅に削減した(20240121_dissertation.pdf)。このコンセプトは、様々なシステムで採用されている。例えば、ログ行を組み合わせたり、メトリクスを事前に計算したり、不要な詳細を削除したりといった、よりスマートな収集を、可能な限りソースの近くで行う。こうすることで、パイプラインを通じて伝搬されるデータが少なくなり、下流の各コンポーネントの負荷が軽減される。 サンプリングとアグリゲーションを注意深く使用することで、遠隔測定システムは、モニタリングに必要な主要シグナルを保持したまま、リソースのフットプリントを桁違いに縮小することができる（多くの場合、生データの1～10％しか収集しない）。これらの技術は、精度が許容できるように調整されなければならない。例えば、エラー・イベントが決してサンプリングされないようにしたり、集約されたメトリクスが依然として精度要件を満たすようにする。うまくいけば、データ削減は遠隔計測のエンドユーザーにはほとんど見えません（エンジニアは必要な洞察を得ることができます）。 バッチ処理と効率的なデータ処理 テレメトリーデータがどのようにバッファリングされ送信されるかは、オーバーヘッド、特にレイテンシとCPU使用率に大きく影響します。バッチングは、複数のデータポイントにわたってオーバーヘッドを償却するための一般的なテクニックです： テレメトリ・エクスポートのバッチ化： テレメトリのエクスポートをバッチ化する：テレメトリを一度にひとつずつ（例えば、すべてのトレーススパンやメトリックを個別のネットワークメッセージとして）送信するのは非効率的です。メッセージが小さいと、ネットワークコールや I/O 操作の固定オーバーヘッドが支配的になります。複数の遠隔測定レコードを一緒にバッチすることで、我々は送信やディスク書き込みをより少ない頻度で呼び出します。これにより、CPU 割り込み/コンテキストスイッチが減り、スループットが向上します。例えば、OpenTelemetryのコレクターとエージェントは、バッチスパンプロセッサーを使用し、短いインターバル（例えば5秒または最大Nスパン）のスパンを集約し、それらを一度に送信します。DoorDashのエンジニアは、バッチスパンプロセッサーを使用することで、テレメトリーパイプラインのスループットが大幅に向上し、CPU使用率が下がることを発見した（OpenTelemetryのスパンプロセッサーを高スループットのために最適化 ... ）。クラウド・テレメトリーでは、即時送信からバッチ送信に切り替えることで、スループットが5～10倍向上するのが一般的です。 調整可能なバッチサイズ（遅延とCPUのトレードオフ）： バッチサイズが大きいと、リソースをより効率的に使用できる（アイテムあたりのオーバーヘッドが少ない）が、各アイテムを配信する際の待ち時間が長くなる（バッチ内で待機するため）。システムには、バッチサイズを調整するためのつまみが用意されていることが多い。例えば、Istio のテレメトリの以前のバージョンには、プロキシからデータを収集するコンポーネント（Mixer）があった。オーバーヘッドを減らすために、開発者はレポート呼び出しのバッチサイズのコントロールを導入した（Istio のテレメトリのオーバーヘッドと MixerV2 の情報 - ポリシーとテレメトリ - Istio について）。バッチサイズを大きくすることで、1メッセージあたりのCPUオーバーヘッドを減らすことができます（呼び出し回数が減ります）。あるチームでは、バッチ処理は助けになるものの、ある点を超えるとリターンが減少すると指摘している（Istio telemetry overhead and MixerV2 info - Policies and Telemetry - Discuss Istio ）。一般的な原則は、可観測性のためのレイテンシ要件に違反することなく、可能な限りバッチ処理することである。多くの最新の可観測性システムは、バッチ処理による大きな効率向上と引き換えに、小さな遅延（せいぜい数秒）を好む。 バッファリングとバックプレッシャー：効率的な遠隔測定パイプラインは、遠隔測定の生成と消費を切り離すために、インメモリバッファ（多くの場合、ロックフリーのキューやリングバッファ）を使用します。インスツルメンテーションはバッファに素早く書き込み、次に進みますが、バックグラウンドのスレッドやエージェントはバッファから読み込み、データを処理/送信します。このバッファリングはスパイクを滑らかにし、遠隔測定バックエンドのスローダウンでアプリケーションがブロックされるのを防ぎます。オーバーヘッドを最小化するために、これらのバッファは多くの場合、共有メモリ内の固定サイズのリングバッファです - 非常に高速な書き込みと読み取りが可能ですが、コンシューマが遅れをとった場合、古いデータを上書きする可能性があります（アプリを停止するのではなく、プレッシャーの下で優雅にデータをドロップします）。この設計は、遠隔測定収集がアプリケーションを停止させないことを保証する。これは、多くの高性能ロガーと計測システムで使用されている。例えば、eBPFのユーザー空間とのやり取りは、カーネルが書き込み、ユーザー空間のリーダーが排出するリングバッファを使用します。この設計は、最小限のコピーとロックで大量のイベントを効率的に転送するために明示的に選択されました（eBPF based instrumentation ）（eBPFベースの計測）。 圧縮とエンコード： 厳密にはCPUの 「オーバーヘッド 」ではないが、データがどのようにエンコードされるかは、ネットワークのオーバーヘッドや、エンコード/デコードのためのCPUに影響を与える可能性がある。テレメトリーシステムは、バイナリプロトコルを使用することが多くなり、大きなデータのバッチは圧縮されます。例えば、OpenTelemetryはバイナリのProtobufフォーマットでメトリクスをエクスポートすることができ、これはJSONのようなテキストフォーマットよりもはるかに小さく、解析が速い。いくつかのシステムは、ネットワーク・ペイロードを5-10倍削減するために、送信前に（例えばgzipやlz4を使って）バッチ化されたテレメトリーを圧縮します（Achieve a 10x Reduction in Telemetry Traffic Using OpenTelemetry ...）。圧縮はCPUを消費するが、バッチ処理であれば、特に帯域幅に制約のあるシナリオや、ストレージコストを下げるために、I/Oオーバーヘッドを削減するために、償却コストに見合う価値がある。 全体として、バッチ処理と最適化されたデータ処理により、遠隔測定データの移動が可能な限り効率的になります。その結果、CPU 使用率が下がり（システムコール、コンテキストスイッチの数が減る）、レイテンシが制御される（通常、数秒以下のオーダーで、ほとんどのモニタリングニーズには許容可能）。メトリックスとトレースをバッチ処理することは一般的なベストプラクティスであり、事実上すべての最新の遠隔測定フレームワークが、このようなことを行っています。 遠隔計測のためのシステムレベルの最適化 計測コードそのものだけでなく、基礎となるシステムとハードウェアにもオーバーヘッドを減らすチャンスがあります： ハードウェア・カウンターの活用： ハードウェア・カウンターの活用：最近のCPUはパフォーマンス・モニタリング・ユニット（PMU）を持っており、実行された命令、キャッシュ・ミス、分岐予測ミスなどのイベントを、ごくわずかなオーバーヘッドでカウントする。ツールはこれらのカウンターを利用することで、コードにインスツルメンテーションを行うことなく、遠隔測定（CPUサイクルやキャッシュ使用量など）を行うことができます。これらのカウンターを定期的に（LinuxのperfやOSのAPIを使って）読み取ることは、すべての命令や関数コールを計測するよりもはるかに安上がりだ。同様に、いくつかのNIC（ネットワークカード）は、フロー統計とエラーカウントを保持しており、ネットワーク・テレメトリーのために読み取ることができる。このようなハードウェアのテレメトリー機能を利用することで、基本的にアプリケーションのコストはゼロで、システムレベルの洞察を得ることができる。 OSのスケジューリングと分離： オーバーヘッドを抑える一つの方法は、テレメトリ作業を専用の CPU コアか、少なくとも別々のスレッドに分離することです。遠隔測定コレクションを（可能であれば）別のコアで実行することで、メインのアプリケーションスレッドはモニタリングタスクとのコンテキストスイッチを避けることができます。これは高性能システムで見られるパターンである。例えば、1つのコアがメトリクスの集約と出荷を担当し、他のコアは邪魔されずにアプリケーションコードを実行できる。全体的なCPUコストは残るかもしれないが、クリティカルなリアルタイム・スレッドが影響を受けないように管理される。裏を返せば、テレメトリの低レイテンシが必要な場合、テレメトリスレッドに高い優先度を与えたり、迅速な処理を保証するためにリアルタイムスケジューリングを行うこともできますが、通常はアプリケーションが優先されます。目標は、干渉を防ぐことである。監視スレッドをうまくダウンさせるか、固定することで、そのオーバーヘッドがアプリのレイテンシ・スパイクとして現れないようにする。 ネットワーク・テレメトリーのためのカーネル・バイパス： ネットワーキングでは、多くのオーバーヘッドがカーネル・ユーザー間のコンテキスト・スイッチング（パケットがカーネルを通過し、解析のためにユーザー空間にコピーされる）から発生する可能性がある。XDP（eXpress Data Path）やDPDKのような技術は、カーネルの一部をバイパスしたり、ドライバー・コンテキストでカスタム・コードを実行することで、オーバーヘッドを少なくして高速にパケットを処理することを可能にする。テレメトリの場合、大量のネットワークトラフィックを検査する必要がある場合（例えば、フローごとの帯域幅を測定したり、異常を検出したりする場合）、XDPやDPDKベースのエージェントを使用することで、標準的なソケットキャプチャを使用するよりもはるかに低いCPUで数百万のパケットを処理することができます。基本的に、これらのテクニックは、合理的な方法でパケットを処理することで、カーネルネットワークスタックの汎用性を効率性と引き換えにします。サンプリング（例えばN個のパケットのうち1個だけを検査する）と組み合わせることで、これはネットワークの強力な低オーバーヘッド・モニタリング手法となる。 最適化された遠隔測定ストレージ： この質問は収集のオーバーヘッドに焦点をあてているが、システムレベルの最適化はテレメトリがどのように保存され、クエリされるかにまで及ぶことは注目に値する。例えば、高インジェストレートの遠隔測定システムは、最近のデータにはインメモリ時系列データベースを使用し、古いデータは（HeteroTSDBアプローチのように）ディスクにロールして、スピードとコストのバランスをとるかもしれない(20240121_dissertation.pdf)(20240121_dissertation.pdf)。効率的なストレージは、多くのデータを収集してもメモリやディスクを圧迫しないことを保証する。これは直接的に計測のオーバーヘッドを削減するわけではないが、遠隔計測パイプラインにおけるバックログやパフォーマンスの問題を防ぐことができる。 動的制御とフィードバック： システムレベルのビューは、遠隔計測の使用と収集の間のループを閉じることを可能にします。バックエンド分析が特定のデータが有用でないことを発見した場合、計測レイヤーにシグナルを送ることができます。逆に、より詳細が必要な場合（例えば、異常が検出された場合）、システムは関連するメトリクスの収集を一時的に増やすことができる。このフィードバック駆動型遠隔測定システムのコンセプトは、活発な研究の方向性である(20240121_dissertation.pdf)(20240121_dissertation.pdf)。これは、ほとんどの時間オーバーヘッドを最小化し（必要なものだけを収集する）、必要なときにデータ収集のコンテキストを意識したブーストを保証するものである。この実装にはシステム全体の調整（計測、ストレージ、分析レイヤーの通信）が必要だが、クラウド環境では最新のオーケストレーションとコントロールプレーンによって容易になる。 要約すると、システムレベルの最適化は、効率的な遠隔測定を実行するための基盤を提供する。カーネル、ハードウェア、スマートなリソース管理を利用することで、テレメトリのオーバーヘッドをシステムの 「ファブリック 」の中にさらに隠すことができる。これらのテクニックの多くは、成熟したモニタリング製品の舞台裏にあります - ユーザーは、これらの最適化のおかげで、モニタリングをオンにしても、期待したほど遅くならないことに気づくだけかもしれません。 テレメトリーのための効率的なネットワーク・モニタリング ネットワーク・テレメトリーは、スケールの大きなネットワーク・モニタリングが非常にデータ集約的であるため、特別な注目に値する。ネットワーク・トラフィックとコネクションのモニタリングは（パフォーマンスとセキュリティのために）極めて重要だが、ナイーブに全てのパケットをキャプチャしたり、全てのコネクションをロギングしたりすると、システムを圧倒する可能性がある。ネットワーク・テレメトリのオーバーヘッドを減らす戦略には以下が含まれる： フロー・サンプリング（NetFlow/sFlow）： 従来のネットワーク・テレメトリーは、パケット単位のロギングではなく、フロー記録を使用することが多い。例えば、Cisco の NetFlow とより最新の sFlow プロトコルは、N 個のパケットのうち 1 個のパケット（または N 個のフローのうち 1 個のフロー）をサンプリングし、フローに関するサマリー統計（ソース、宛先、バイトなど）を記録します。特にsFlowは軽量に設計されている。サンプリングは通常スイッチ/ルーターのハードウェアで行われ、エージェントはサンプリングされたデータを受信するだけである。これにより、トラフィックの統計的な画像を提供しながら、CPU使用率を低く抑えることができる。大規模なデータ・センターでは、オペレータは1:1000または1:10000のパケット・レートでサンプリングすることがありますが、これはすべてのイベントを処理しなくても、トレンドや大ヒットを検出するのに十分です。 カーネル・レベルのソケット・トレース： eBPFのような技術（または他のシステムでは歴史的にSystemTap/DTrace）を使用すると、低オーバーヘッドでカーネルレベルのネットワークイベント（TCP接続、アクセプト、送受信コールのような）をトレースすることができます。複数のTCP/UDPソケット・イベントをカーネル内の1つの論理フローに集約し、ユーザー空間に送信されるメッセージ数を削減した（20240121_dissertation.pdf ）。これにより、ネットワークフロー数が劇的に増加しても、CPUオーバーヘッドは2.2%以下に抑えられた(20240121_dissertation.pdf)。この効率性は、パケットごとやコネクションごとのコンテキスト・スイッチのオーバーヘッドを排除することに起因する。カーネルは、新しいコネクションごとにユーザー空間に通知する代わりに、アクティブなフローのハッシュ・テーブルを維持し、定期的に集約された情報をエクスポートするだけである。bcc (BPF Compiler Collection)やbpftraceのようなツールを使えば、このようなトレースを簡単に実装できる。例えば、BPFのコードを数行書くだけで、プロセスごとにすべてのTCPコネクションをカウントしたり、HTTPリクエストのレイテンシを計測したりすることができる。これは、アプリケーションにプロキシや重いロギングを挿入するよりもはるかに少ないオーバーヘッドでスケールする効率的なネットワークモニタリングをもたらします。 ネットワークハードウェアのテレメトリー： いくつかの最先端のアプローチは、テレメトリーをネットワークデバイス自体に押し込みます。例えば、Inband Network Telemetry (INT)は、ネットワークスイッチがパケットにテレメトリーのメタデータを追加するものです（タイミング、キューの長さなどを記録します）。これは、オーバーヘッドを最適化されたスイッチ内の専用ASICに移し、サーバーを完全に解放する。INTや同様の技術は（主に先進的なデータセンター・ネットワークで）出現しつつあるが、これは遠隔測定にハードウェアを活用する傾向を示している。もう一つの例は、eBPFやP4プログラムを実行できるSmartNICやプログラマブルNICの使用である。SmartNICは、例えば、ホストCPUが関与することなく、フローごとにパケットをカウントしたり、ドロップを検出したりすることができる。ネットワーク・テレメトリーをハードウェアにオフロードすることは、ホストのCPUオーバーヘッドがほぼゼロになり、非常に忠実なモニタリングができる可能性があることを意味するが、それには高度な機器が必要である。 低オーバーヘッドのプロトコルとストリーミング： 従来のネットワーク統計の取得方法（SNMPポーリングのような）は、実はあまり効率的でタイムリーではありません。新しいストリーミング・テレメトリー・アプローチは、デバイスやエージェントからの持続的な接続（多くの場合gRPCやMQTTベース）を維持し、メトリクスを継続的にストリーミングします。これは、リクエスト毎のポーリングのオーバーヘッドを回避し、より低レイテンシのアップデートをもたらします。ソフトウェアシステムでは、ログ／メトリクスにストリーミングアプローチを使用する（例えば、protobufメッセージで単一のTCP接続を介してデータをプッシュする）ことは、多くの接続やHTTPコールを開くよりもCPUおよびネットワーク効率が高い。例えば、FacebookのOsqueryや同様のエージェントは、イベントをストリームするためにアクティブなソケットを維持し、定期的なポーリングよりも効率的であることが証明されている。 ネットワークデータのエッジ集約： 一般的なデータ削減と同様に、ネットワーク・テレメトリーも階層的アグリゲーションから恩恵を受けることができる。各ホスト上のエージェントはそのホスト上の接続の全てのメトリクスを集約し、中央システムが全ての接続の生データを受信するのではなく、1つのサマリーを中央システムに送信するかもしれない。より高いレベルでは、データをさらに要約する中間アグリゲータ（おそらくラックまたはクラスタごとに1つ）を持つことができる。これは、コンテンツ・デリバリー・ネットワークや大規模なモニタリング・セットアップが、スケールアップするためにコレクターのツリーを使用する方法に似ている。各レイヤーは量を減らし、単一のボトルネックリンクやノードが完全な生フィードを処理する必要がないようにする。その結果、データがメインの分析ポイントに到達するまでに、その量は削減され、管理しやすくなり、ネットワークや処理ノードへのストレスが軽減されます。 効率的なネットワーク・モニタリングは、スマートなサンプリング、低レイヤー（カーネル／ハードウェア）の活用、アーキテクチャ設計（分散収集）の組み合わせである。上記のアプローチは、非常に高い帯域幅のネットワーク（マルチギガビット、数百万フロー）であっても、低いオーバーヘッドで監視できることを示している。Cilium Hubble（ネットワークの可観測性のために）や CloudFlare のネットワークパフォーマンス監視のための eBPF の使用（eBPF - Introduction, Tutorials & Community Resources ）のようなツールにおける eBPF のようなテクニックの成功は、ネットワーク遠隔測定がもはや遅い、重い方法に頼る必要がないことを強調している。 ソリューションの比較分析 テレメトリー計測には複数のソリューションが存在し、それぞれにオーバーヘッドの点で長所と短所があります。我々はいくつかのカテゴリーを比較する： アプリ内計測 vs. 外部モニタリング： アプリケーション内ライブラリ（コードに統合された OpenTelemetry SDK のような）は、豊富なコンテキストと柔軟性を提供しますが、ユーザースペースで実行され、アプリケーションプロセスでオーバーヘッドを発生させます。外部モニタリング（eBPF ベースやサイドカー・エージェントの使用など）は、アプリへの影響を少なくして、同様のデータを収集できることがあります。例えば、OpenTelemetry 自動計測エージェントは、トレースのために各リクエストに数ミリ秒のオーバーヘッドを追加するかもしれないが、eBPF ベースのツールは、サブミリ秒のオーバーヘッドでシステムコールを監視することで、同じリクエストをトレースすることができる（OpenTelemetry and eBPF: Everything You Need to Know ）。トレードオフは、アプリ内インスツルメンテーションは、低レベルのツールが知らないかもしれない、より高いレベルのセマンティクス（アプリケーション変数、カスタムスパン）を捕らえることができるということです。アプリケーション固有のデータには OpenTelemetry を使い、システムレベルのテレメトリにはそれを補完する eBPF を使い、それらを組み合わせて全体像を把握するというハイブリッドなアプローチが出現しつつある。 エージェントベースの遠隔測定とエージェントレス： 従来の APM ソリューション（New Relic、Datadog など）は、コードを計測する言語固有のエージェントを使用することが多い。これらはかなり最適化できますが、それでもアプリの一部として実行されます。新しいエージェントレスまたは 「ゼロ計測」アプローチは、プラットフォームやホストの機能を使用することで、そのオーバーヘッドを回避しようとしている。例えば、マネージド・ランタイムからいくつかのデータを自動収集できるGoogle Cloudのオペレーション・スイートや、重いコードを注入することなくデータを収集するためにWindows上のパフォーマンス・カウンターとイベント・トレーシングを使用できるAzureのアプリケーション・インサイトなどがある。エージェントレスアプローチは、CPUオーバーヘッドを低くする傾向があるが、アプリ内エージェントが捕捉する全てを捕捉しないかもしれない。OpenTelemetryはその両方を提供します：エージェントと一緒に使うことも（自動計測）、手動で計測することもできます。実際には、多くの場合、オーバーヘッドを減らすために、最小限の手動計測とインフラストラクチャシグナルへの依存を選択している。 eBPFとDTrace/SystemTapの比較： Linuxでは、eBPFは、安全性と低いオーバーヘッドにより、実運用ではSystemTapにほとんど取って代わられている。DTrace (on Solaris/macOS) と SystemTap (Linux) は、強力なダイナミック・インスツルメンテーションを可能にしますが、多くの場合、より高いコストと複雑さを伴います。eBPF の設計（ベリファイア、ネイティブ・コードへの JIT コンパイル）は、非常に効率的な実行につながります（OpenTelemetry and eBPF: Everything You Need to Know ）（OpenTelemetry and eBPF: Everything You Need to Know ）。SystemTapは対照的に、より高いオーバーヘッドとリスクを持つ可能性のあるカーネルモジュールを挿入します。DTraceは特定のプローブに対しては非常に効率的だが、Linuxでは広く利用できない。そのため、最新のLinux環境では、eBPFベースのソリューション（Cilium、Pixie、Groundcoverなど）が低オーバーヘッドの遠隔測定に適しているが、他のOS環境では、類似の機能（WindowsのETWやMacの軽量プロファイリングツールなど）が同様の役割を果たしている。 メトリクス vs. トレース vs. ログ： 異なるテレメトリーデータタイプは、本質的に異なるオーバーヘッドプロファイルを持っています。メトリクス（数値測定）は一般的に安価である。例えば、カウンターをインクリメントするだけで、通常O(1)であり、非常に高速です。うまく設計されたメトリクス・パイプラインは、集約によるオーバーヘッドを最小限に抑えながら、毎秒数百万のメトリクスを処理できます。ログは高価になる可能性があります：ログは、多くの場合、大量で、文字列を多用します。ログ行を書くには、文字列のフォーマットとI/Oが必要になり、その分遅くなります。規模が大きくなると、冗長なロギングは多くのCPUとI/Oを消費する可能性がある（これが、多くのシステムが本番環境でログレベルを下げている理由である）。トレースはその中間に位置します。大量に記録されますが（全てのリクエストは複数のスパンレコードを生成するかもしれません）、構造化されており、サンプリングすることができます。一つのトレーススパンは、通常、いくつかのフィールド（タイムスタンプ、ID）を持つ小さなオブジェクトである。トレースのオーバーヘッドはサンプリングに依存する。ヘビーサンプリング (例えば1%)では、トレースのオーバーヘッドはわずかであるが、100%(全リクエストをトレース)では、かなりのオーバーヘッドになる。従って、遠隔測定ソリューションは、しばしば次のことを推奨します： 日常的なモニタリングにはメトリクスを使い（安価）、ログは控えめに使い（重要なイベントのみ）、サンプリングでトレースを使う。この組み合わせにより、管理可能なオーバーヘッドで良好なカバレッジが得られる。 商用APMツールとオープン・ソリューションの比較： 多くの商用ツールは、独自の最適化されたエージェント（Dynatraceのバイナリエージェント、New Relicのエージェントなど）を持っており、最小限のオーバーヘッドになるようにチューニングされています。OpenTelemetry のようなオープンソースのソリューションは柔軟性を提供するが、ユーザーが設定やチューニング（適切なサンプリングの設定など）を行う必要がある。オーバーヘッドに関しては、よく知られた APM エージェントは通常、CPU オーバーヘッドを一桁台の低いパーセンテージに抑え、メモリオーバーヘッドを数十 MB に抑えている。例えば、eBPF を使用した OpenTelemetry の継続的プロファイラでは、テストにおいて CPU は ~1%、RAM は 250 MB が上限とされており（open-telemetry/opentelemetry-ebpf-profiler - GitHub ）、これは多くのベンダーが宣伝しているものと同じである。違いは特定のワークロードに現れる。あるソリューションはトレースのための低いCPUオーバーヘッドが得意かもしれないが、別のソリューションはより多くのCPUを使うがメモリはより少ない、といった具合だ。傾向としては、オープンツールも商用ツールも、同様のベストプラクティス（可能な限りeBPFを使用する、作業をオフロードする、データを圧縮するなど）に収束しつつある。 古いアプローチと新しいアプローチ 歴史的に、システム・モニタリングは、頻繁なポーリング（topを呼び出したり、毎秒/procを読んだりするような）と大量のロギングに依存していた。新しいアプローチでは、イベント・ドリブン・テレメトリー、ストリーミング、インテリジェント・フィルタリングを使用する。例えば、全てのプロセスのCPU使用率を毎秒ポーリングする（これは多くのコードを目覚めさせる）代わりに、最近のエージェントはカーネルイベントを購読したり、プロセスが終了したりスケジューラのティックが発生したときに通知を受けるためにBPFを使用したりします。このように、新しいソリューションは一般的に、同じ情報に対してより少ないオーバーヘッドしか発生させません。実際に比較分析すると、次のようになる： TCPメトリクスを収集するためにeBPFを使用する場合、使用するCPUは2%未満であるのに対し、straceやlsofポーリングを使用するレガシー・アプローチでは10%以上のCPUを使用する可能性がある。改善は明らかであり、これらの技術が成熟するにつれて、古い高オーバーヘッドの技術は段階的に使用されなくなると我々は予想している。 ソリューションの比較において、システム（OSまたはカーネル）と深く統合し、スマートなフィルタリングを適用するものは、そのような最適化なしに高いレベルで動作するものを上回る傾向があることは明らかである。とはいえ、使いやすさやデータの完全性も要因のひとつである。目標は、許容できるオーバーヘッドで必要な可視性を提供するソリューションを選択することだ。多くの場合、組み合わせが最適である（例えば、eBPFベースのシステム可測性ツールと、ビジネスロジックのためのアプリケーションレベルのトレースを併用する）。 新たなトレンドと将来の方向性 遠隔測定と可観測性の分野は、オーバーヘッドを減らすことに重点を置いて、急速に進化しています。いくつかの新たなトレンドと研究の方向性は以下の通りです： 統一された遠隔測定パイプライン（可観測性パイプライン）： あらゆる種類のテレメトリ（ログ、メトリクス、トレース）をインジェストし、保存前に設定可能な方法（フィルタリング、サンプリング、ルーティング）で処理する集中型パイプラインへの動きがある。Grafana Mimir/Tempo、Honeycomb Refinery、Chronosphere のパイプラインのようなプロジェクトは、チームがインジェスト時に遠隔測定データに変換を適用することを可能にする。これは、価値の低いデータを早期に削除またはダウングレードすることで、オーバーヘッドを管理できることを意味する。これは可観測性のためのミドルウェアのようなもので、ポリシー（「サービスAからのトレースを10%でサンプリングする 」など）を一律に実施することができる。これらのパイプラインは、しばしばコストとオーバーヘッドの削減を主な目標としている - 例えば Chronosphere は、このようなテクニックによって、テレメトリーデータ量（とそれを処理するインフラ）の大幅な削減を主張している（Achieve a 10x Reduction in Telemetry Traffic Using OpenTelemetry ...）。この傾向は、テレメトリの肥大化を積極的に削減するために、組織がきめ細かいコントロールを望んでいることを示している。 「Use-First」 テレメトリー収集： 伝統的に、チームは可能な限り多くのデータを収集していました（「最初に収集し、後で質問する」）。現在では、「使用優先」（use-first）、つまり、予想される使用方法に基づいて、より選択的にデータを収集する方向にシフトしている（20240121_dissertation.pdf ）。最近の研究で提唱されているこの考え方は、フィードバックループのある遠隔測定システムの設計を示唆している。例えば、特定のメトリクスがダッシュボードやアラートで使用されていない場合、システムはリソースを節約するためにそれらのメトリクス収集を停止することができる。逆に、新たなパフォーマンス上の問題が発生した場合、システムは一時的にその領域のデータを追加収集するかもしれない。機械学習やアナリティクス（どの遠隔測定が有用かを特定する）を使ってこのプロセスを自動化することは、活発な分野である。最終的なゴールは、価値を提供するものだけを収集することでオーバーヘッドを最小化する、自己調整型遠隔測定システムである(20240121_dissertation.pdf)。初期の実装は、異常検知アルゴリズムに基づいてログレベルやメトリックの詳細を調整するAIOpsプラットフォームで見られる。 継続的プロファイリングとeBPF Everywhere： eBPFのような低オーバーヘッドの技術のおかげで、継続的プロファイリング（本番環境での常時CPU/ヒープ・プロファイリング）が登場した。Parca や Pixie、そして OpenTelemetry eBPF プロファイラのようなツールは、全てのプロセスのスタックトレースを高頻度かつ常時サンプリングすることができ、オーバーヘッドを最小限に抑えることができます（多くの場合、CPU は 1-2% 未満です）（open-telemetry/opentelemetry-ebpf-profiler - GitHub ）。以前は、オーバーヘッドのためにこのようなことは不可能で、プロファイリングはアドホックにしか行われなかった。傾向として、プロファイリングはテレメトリの標準的な一部となりつつあり、オーバーヘッドの削減によってメトリクス/トレースを補完している： GPUモニタリング、IPCモニタリングなどであり、Linux以外のシステムでも同様の技術が模索されている（例えば、Windows用のeBPFがプロトタイプ化されている）。我々は、eBPFベースのインスツルメンテーションがOpenTelemetryのようなフレームワークと統合され、開発者がハンドコーディングすることなく、また大きなパフォーマンスヒットを起こすことなく、多くのデータを取得できるようになることを期待している（eBPF based instrumentation - Odigos）（OpenTelemetry and eBPF: Everything You Need to Know）。 エッジとクライアントサイドの遠隔測定： アプリケーションはサーバーだけでなく、エッジ・デバイスやユーザー・クライアント（モバイル・アプリ、ブラウザ、IoTデバイス）にも及ぶため、これらから低いオーバーヘッドでテレメトリを収集することがフロンティアとなる。モバイルやウェブでは、オーバーヘッドがユーザーエクスペリエンス（バッテリー寿命、アプリのスムーズさ）に直接影響するため、遠隔測定は極めて軽量でなければならない。サンプリングや圧縮のような技術は、そこではさらに重要である。我々は、ブラウザがウェブアプリのために、テレメトリ（ナビゲーションのタイミングやリソースのタイミングなど）を低オーバーヘッドで提供するパフォーマンスAPIを実装しているのを見ている。IoT側では、デバイスは超小型のバイナリ遠隔測定を使用し、帯域幅とCPUを節約するために要約のみを送信する。エッジ遠隔測定とクラウド遠隔測定の融合には、全体のオーバーヘッドを低く抑え、データを階層的に集約するように、エンドツーエンドの最適化が必要になる。 機械学習による異常駆動型遠隔測定： もう一つのトレンドは、いつ何を収集するかを決定するためにMLを使用することである。例えば、MLモデルがサービスのメトリクスに異常を検出し、そのサービスのより詳細なトレースやロギングを短期間トリガーするかもしれない。こうすることで、問題がありそうなときだけオーバーヘッドが発生し、リソースの使用を必要性に合わせることができる。これらの 「インテリジェント・テレメトリー 」システムは実験的なものだが、適応型計測の考え方に沿ったものだ。もし成功すれば、定常状態のオーバーヘッドを大幅に削減し（物事が正常であれば、基本的な測定基準以上のオーバーヘッドはゼロに近い）、何か異常が起きたときだけオーバーヘッドを増加させることができる。 標準化と相互運用性： OpenTelemetryのような努力は、遠隔測定がどのように収集され、どのようにエクスポートされるかを統一している。これは直接オーバーヘッドを削減するものではないが、最適化を一箇所（SDK/エージェント）で実装でき、多くのツールに恩恵をもたらすことを意味する。例えば、OpenTelemetry SDK は、全てのバックエンドツールが使用できるバッチエクスポーターを提供するので、そこでの改善（より良いロックフリーのキューやよりスマートなサンプリングアルゴリズムなど）はエコシステム全体に伝搬します。さらに、OpenTelemetryとeBPFの統合（コードを変更することなく自動計測）が進められています（OpenTelemetry and eBPF: Everything You Need to Know）（OpenTelemetry and eBPF: Everything You Need to Know ）。OpenTelemetryとeBPFを組み合わせるというgroundcoverのアプローチはその一例です：eBPFを使ってデータを取り込み、それをOpenTelemetryのフォーマットにフィードします（OpenTelemetry and eBPF: Everything You Need to Know）（OpenTelemetry and eBPF: Everything You Need to Know ）。これは、標準的なテレメトリーデータフォーマットが、ボンネットの下の非常に効率的なキャプチャメカニズムによって満たされるトレンドになる可能性がある。 要するに、遠隔測定ワークロードのスケーリングの未来は、自己最適化され、プラットフォームと深く統合されるようだ。包括的なテーマは効率性であり、無駄を最小限に抑えて適切なデータを適切なタイミングで収集することである。新たなソリューションは、運用チームに忠実度の高い可視性を与え、システムを円滑に稼動させ、計測とパフォーマンスの間の従来の緊張関係を解決することを目指している。 結論 遠隔計測を大規模な分散システムに拡張するには、計測のオーバーヘッドに注意する必要がある。軽量な計測技術（eBPF や効率的なトレースポイントなど）、スマートなデータ削減（ソースでの適応的サンプリング、フィルタリング、集約）、システムレベルの最適化（バッチ処理、カーネルレベルのモニタリング、ハードウェアのサポート）を組み合わせることで、エンジニアは遠隔計測の CPU とメモリの使用量を劇的に削減することができる。これらの方法は、可観測性データを収集する際に、わずかなレイテンシ（多くの場合、マイクロ秒から数ミリ秒）と最小限のリソース競合しか発生させないことを保証し、アプリケーションのパフォーマンスを維持する。我々は、ネットワークフローのカーネル内集約のようなアプローチが、オーバーヘッドをCPUの数パーセント以下に抑えることができることを見てきた(20240121_dissertation.pdf)。また、アダプティブ・サンプリングは、データ量（とコスト）を半分以上に削減することができ、洞察の損失はごくわずかである(The procedure of observability SMS | Download Scientific Diagram)。 既存のソリューションは、統合されたAPMツールからオープンソースのフレームワークまで多岐にわたるが、オーバーヘッド削減のためのこれらのベストプラクティスを共有することが多くなっている。比較的、カーネル機能と非同期処理を活用する最新のソリューションは、古い、より侵入的な方法よりも効率性において明らかに優位に立っている（OpenTelemetry and eBPF: Everything You Need to Know ）。テレメトリのニーズが成長し続けるにつれ、業界はパフォーマンスのオーバーヘッドを最適化のための重要な指標として扱う全体的な可観測性アーキテクチャへと移行しています。ユビキタスeBPFの使用、フィードバック駆動型遠隔測定、統合パイプラインなどの新たなトレンドはすべて、高解像度でありながらコスト効果の高い可観測性を目指しています。目標は、オーバーヘッドに比例してスケールすることなく、量と詳細をスケールする可観測性スタックである。 要約すると、計測のオーバーヘッドを削減することは、遠隔計測収集において、よりハードに働くのではなく、よりスマートに働くことである。全てのレベル（アプリケーション、OS、ネットワーク）で巧みなエンジニアリングを行うことで、観測されるシステムへの影響を最小限に抑えながら、ほぼリアルタイムで詳細な遠隔測定を実現することができる。これによって、組織はワークロードの増大に応じて、「システムを可観測する」ことでシステムの動作が遅くなることを恐れることなく、自信を持ってモニタリングを拡大することができる。この分野での絶え間ない技術革新は、今後さらに効率的でインテリジェントな遠隔測定ソリューションを約束し、堅牢な可観測性が最高のパフォーマンスと両立することを保証します。 出典 (20240121_dissertation.pdf) (The procedure of observability SMS | Download Scientific Diagram) (eBPF based instrumentation) (OpenTelemetry and eBPF: Everything You Need to Know) (Performance | OpenTelemetry) (Performance | OpenTelemetry) (All my favorite tracing tools: eBPF, QEMU, Perfetto, new ones I built and more - Tristan Hume). 私は、テレメトリーワークロードのスケーリングにおける計測オーバヘッドを削減する方法と技術に関する研究レビューを行う。これには、リソース使用量の最小化、データ収集プロセスの最適化、精度を損なうことなく低遅延テレメトリーを確保するための戦略が含まれる。近日中に結果をご報告します。 はじめに 遠隔測定システムは、パフォーマンスと動作をモニターするために、ソフトウェアとハードウェアからメトリクス、ログ、トレースを収集します。これらのシステムが大容量のワークロードを扱うようにスケールするにつれ、計測のオーバーヘッド（テレメトリーの計測とエクスポートにかかる余分な CPU、メモリー、レイテンシーのコスト）が大きくなる可能性があります（Performance | OpenTelemetry ）。例えば、多すぎる関数をトレースしたり、メモリ使用量を肥大化させる高いカーディナリティのメトリクスを使用する場合など、過剰なインスツルメンテーションは、アプリケーションのパフォーマンスを低下させる可能性があります（Performance | OpenTelemetry ）。課題は、重いオーバーヘッドを課すことなく、豊富で正確な遠隔測定データを収集することです。この研究レビューでは、CPU とメモリーへの影響を最小化し、データ収集を最適化し、低レイテンシーの遠隔測定配信を保証する方法を検討します。我々は、効率的で軽量な計測、スマートなデータ削減（サンプリングとアグリゲーション）、システムレベルの最適化、効率的なネットワーク・モニタリングのためのアプローチなどのテクニックを探求します。また、既存のソリューションと新たなトレンドの比較分析も行います。 遠隔測定オーバーヘッドとスケーリングの課題 遠隔測定ワークロードが増大すると（より多くのサービス、より高いイベントレート、より多くのメトリクス）、「すべてを収集する 」という素朴なアプローチは維持できなくなります。計測はアプリケーションのリソースと競合する CPU サイクルとメモリを消費します。極端なケースでは、インスツルメンテーションコードは、計測される実際の作業よりもアプリケーションを遅くする可能性があります（Performance | OpenTelemetry ）。高頻度のデータ収集や非常に詳細なトレースは、インスツルメンテーションがオペレーションをインターセプトするため、レイテンシが発生する可能性があります。さらに、大量の遠隔測定データ（例えば、毎秒数千のメトリクスやトレース・スパン）の転送は、ネットワークやストレージの I/O に負担をかける可能性があります。主な課題は以下の通りです： CPU オーバーヘッド： 記録された各メトリックやキャプチャされたトレース・スパンには CPU 時間がかかります。アプリケーション・コードとインラインで実行されるインスツルメンテーションは、リクエスト処理を長くする可能性があります。例えば、すべての関数呼び出しでトレーススパンを記録することは、同期的に行われた場合、自明でないオーバーヘッドを追加する可能性がある。高負荷の下では、オーバーヘッドは、テレメトリ量に比例して増加し、制御されなければ、コアを飽和させる可能性があります（3_29-JIP.dvi ）。 メモリのオーバーヘッド： テレメトリはデータ（メトリクス・バッファ、トレース・スパン・オブジェクト、ログ・キュー）を蓄積し、メモリを消費します。高いカーディナリティの遠隔測定（例えば、多くのユニークなラベルでタグ付けされたメトリクスや、全てのリクエストの詳細なトレース）は、大きなインメモリデータセットにつながる可能性があります（Performance | OpenTelemetry ）。インスツルメンテーションが、（いくつかのトレースライブラリがそうであるように）多くの短命のオブジェクトを作成する場合、それはまた、ガベージコレクションやメモリアロケータにプレッシャーをかけるかもしれません（Performance | OpenTelemetry）（Performance | OpenTelemetry ）。 レイテンシへの影響： クリティカルなコードパス上のインスツルメンテーションは、エンドユーザーの操作にレイテンシーを追加する可能性があります。例えば、Istio で最初に使用されたサービスメッシュコンポーネントは、リクエスト毎にテレメトリをアウトオブバンドで処理することで、測定可能なテールレイテンシのオーバーヘッドを導入した。小さなリクエスト毎の遅延であっても、規模が大きくなれば加算される可能性がある（Istio のテレメトリーのオーバーヘッドと MixerV2 の情報 - Policies and Telemetry - Discuss Istio ）。テレメトリが低レイテンシであることを保証することは、テレメトリ・データが素早くレポートされること（我々が最新の観測性を持つこと）と、それを収集する行為がプライマリ・ワークロードを大きく減速させないことの両方を意味する。 ネットワークとI/Oのオーバーヘッド： テレメトリーデータはしばしばエクスポート（ネットワークを介してコレクターに送信、またはディスクに保存）する必要がある。大量の高解像度テレメトリーは、かなりのネットワーク帯域幅やディスク I/O を消費します。例えば、トラフィックの多いサービスから全てのトレースをエクスポートすると、ネットワークやテレメトリバックエンドが水浸しになります。クラウド環境では、これもコストになります。従って、効率的なネットワーク使用は、遠隔測定スケーリングにおける懸念事項です。 精度とオーバーヘッドのトレードオフ：オーバーヘッドを直感的に削減すると（例えば、大量にサンプリングしたり、粗くアグリゲートしたりする）、テレメトリーの忠実度が損なわれる可能性があります。課題は、精度を失うことなくオーバーヘッドを最小化することであり、デバッグやパフォーマンス分析に役立つ十分な詳細を維持することである。 このような課題を理解することで、その課題に取り組む戦略を立てることができる。次に我々は、テレメトリを拡張しながら計測のオーバーヘッドを削減するために開発された具体的なテクニックと方法を掘り下げます。 軽量計測テクニック 主要な戦略の1つは、システム・リソースへの影響を最小限に抑える軽量計測手法を使用することです。これには、インスツルメンテーションを低レベル（カーネルまたはハードウェアに近い）に移動したり、オーバーヘッドが低くなるように設計された最適化フレームワークを使用したりすることがよく含まれます。 eBPFとカーネル・レベル・プローブ： eBPFは、Linuxカーネル内でサンドボックス化されたプログラムを実行し、イベント（システムコール、カーネルトレースポイントなど）にフックし、非常に低いオーバーヘッドでデータを収集することを可能にします（eBPFベースのインスツルメンテーション）。eBPF プログラムはカーネル空間で実行されるため、従来のエージェントのような高価なコンテキストスイッチやユーザー空間のオーバーヘッドを回避することができます（OpenTelemetry and eBPF: Everything You Need to Know ）。これにより、非常に効率的なデータ収集が可能になる。例えば、eBPF はカーネルのトレースポイントや kprobe にアタッチしてイベントを記録し、リング・バッファやマップを使ってデータをユーザー空間にバッチ転送することで、オーバーヘッドを大幅に削減することができます。カーネル・モジュールや侵入的なコード変更を必要とする旧来の手法とは異なり、eBPFはアプリケーション・コードやカーネルを変更することなく、低オーバーヘッドのモニタリングを実現している（OpenTelemetry and eBPF: Everything You Need to Know）（OpenTelemetry and eBPF: Everything You Need to Know ）。eBPFベースのモニタリングは、多くの場合、本番環境でのCPUオーバーヘッドを1%以下に抑えることができると報告されている(open-telemetry/opentelemetry-ebpf-profiler - GitHub)。あるエンジニアは、eBPFカーネル・プローブとリング・バッファを経由して、アプリケーションに目立ったCPUオーバーヘッドを与えることなく、全てのネットワーク・パケット（毎秒100万パケット）をトレースすることができた（All my favorite tracing tools: eBPF, QEMU, Perfetto, new ones I built and more - Tristan Hume ）。これは、カーネルレベルのインスツルメンテーションがいかに効率的に高いイベント・レートにスケールできるかを例証している。多くの可測性ツールは現在、eBPFをメトリクスやトレースの収集（例えばHTTPリクエストのレイテンシーやTCPコネクション・イベントのキャプチャ、あるいは継続的なプロファイリングなど）に活用している（OpenTelemetry and eBPF: Everything You Need to Know ）（OpenTelemetry and eBPF: Everything You Need to Know ）。 静的で効率的なトレースポイント： オペレーティング・システムは、低オーバーヘッドに最適化された組み込みの計測ポイントを提供する。例えば、Linuxのftraceやperfイベント、あるいはWindowsのETW（Event Tracing for Windows）は、コード内で静的なトレースポイントを使用します。アプリケーションコードに新しいインスツルメンテーションを追加する代わりに）これらのOSが提供する機能を使うことで、オーバーヘッドを減らすことができる。これらの機能はシステムレベルで動作し、多くの場合バイナリー・トレース・ログと高性能バッファを活用する。リアルタイム・システムやカーネルでは、これらのスタティック・トレースポイントは、イベントあたり数ナノ秒という速さで設計されている（私のお気に入りのトレース・ツールはすべて、eBPF、QEMU、Perfetto、私が構築した新しいものなど - Tristan Hume ）。開発者は、必要なトレースポイント（例えば、スケジューリングイベントやI/Oイベント）だけを有効にして、システムの他の部分への影響を最小限に抑えながらテレメトリを収集することができます。 非同期かつ非侵入的な計測： 軽量な計測とは、メインの実行をブロックしたり遅くしたりしないことも意味します。テレメトリーデータをメモリーのロックフリーのバッファやキューに書き込み、別のスレッドやエージェントに非同期で消費させるなどのテクニックは、干渉を最小限に抑えるのに役立ちます。アプリケーションスレッドは、イベントを記録するために、素早く、ノンブロッキングの書き込み（多くの場合、ほんの数個の CPU 命令）を実行するだけで、より重い処理（データのフォーマット、ネットワーク経由の送信）は、アウトオブバンドで行われる。これにより、クリティカル・パスに追加されるレイテンシが削減される。非侵入型インスツルメンテーション・フレームワークは、ビジネス・ロジックのすべてのファンクションにコードを挿入するのではなく、境界（ネットワーク・ソケット・コールやプロキシ経由など）でイベントをインターセプトする。例えば、Tsubouchiらによる アプリケーション非侵入型ネットワーク・トレース手法は、アプリケーション・コードをインスツルメンテーションするのではなく、サービスの依存関係をトレースするためにOSソケット・レベルでアタッチする(20240121_dissertation.pdf)。この方法では、カーネル内のeBPFプログラムを使用して、2.2%以下のCPUオーバーヘッドと、各ラウンドトリップに追加されるわずか6マイクロ秒のレイテンシで、ネットワークフローをバンドルして記録している(20240121_dissertation.pdf)。アプリケーション・ロジックへの変更を避けることで、高い接続率でもオーバーヘッドを一貫して低く抑えることができた。 最適化された遠隔測定ライブラリ： 計測がインプロセスでなければならない場合（例えば、OpenTelemetry のクライアントのようなアプリケーション・ライブラリ）、最適化されたライブラリを使うことが鍵になります。最近の遠隔測定ライブラリーは、オブジェクト・プーリング（メモリーの再利用）、メトリクスのバッチ処理、非常に効率的な同時実行制御（ロック・フリーまたは最小限のロック）などのテクニックを使用しています。また、CPUとI/Oのコストを削減するために、冗長なテキストの代わりにビットパックされたバイナリプロトコルを使用することもあります。例えば、OpenTelemetry のインスツルメンテーションは、かなり軽量に設計されていますが、それでも注意を推奨しています：自動トレース・インスツルメンテーションのような機能を全てのメソッドに使用すると、スパンが多すぎてオーバーヘッドが発生する可能性があります。ハイパフォーマンス環境（ゲームエンジンやトレーディングシステムなど）のカスタムインハウスソリューションの中には、外部ライブラリを使用せず、マクロやコンパイル時のインスツルメンテーションを使用して、ナノ秒スケールのオーバーヘッドでイベントをロギングするものもある（All my favorite tracing tools: eBPF, QEMU, Perfetto, new ones I built and more - Tristan Hume ）（お気に入りのトレースツール：eBPF, QEMU, Perfetto, new ones I built and more - Tristan Hume ）。よく設計されたインスツルメンテーション・メカニズムは、イベントごとに最小限の作業（多くの場合、タイムスタンプと必要なデータをバッファに書き込むだけ）を行うことに集中し、それ以上のことは行わないということだ。高価な処理（文字列のレンダリングなど）は、後回しにするか回避する。 要約すると、eBPFや効率的なトレース・ライブラリのような軽量な計測手法は、CPUとメモリの使用量を大幅に削減する。よりメタル（カーネルやハードウェア）に近いところで動作し、合理的な方法でデータを処理することで、パフォーマンスの観点から 「バックグラウンドに溶け込む 」遠隔測定収集が可能になる。次に、我々は、より多く収集するのではなく、よりスマートに収集することで、オーバーヘッドをさらに削減するデータ削減技術を見ていきます。 サンプリングとデータ削減戦略 オーバーヘッドを削減する効果的な方法は、単純に少ないデータを収集することである。サンプリング、アグリゲーション、フィルタリングは、遠隔測定量と CPU 使用量を調整する古典的なテクニックです： トレースとメトリックサンプリング： トレースとメトリックサンプリング：全てのイベントやリクエストを記録するのではなく、サンプリングは代表的なサブセットのみをキャプチャする。分散トレーシングでは、適応サンプリング戦略により、最も有用なトレースを保持する一方で、他のトレースを削除し、オーバーヘッドを劇的に削減することができます。リクエストパターンに基づく適応サンプリングは、クリティカルパスの洞察を維持しながら、計測のオーバーヘッドを65%まで削減できることが研究で示されています（The procedure of observability SMS | Download Scientific Diagram）。例えば、トレースシステムはリクエストの X% だけをサンプリングしたり、テールベースのサンプリングを使って、エラーや高いレイテンシを示す全てのトレースを保持し、ルーチンなものはサンプリングしないようにするかもしれない。OpenTelemetry と他のトレースフレームワークは、オーバーヘッド対データ量のトレードオフをコントロールするために、正確に設定可能なサンプリングポリシーを提供します (Performance | OpenTelemetry)。サンプルレートをチューニングすることによって（例えば、10リクエストに1つだけとか、100リクエストに1つだけフルトレースするとか）、組織はトレーサーが CPU やネットワークを圧倒しないようにする（Performance | OpenTelemetry ）。同様に、メトリクス収集はサンプリングすることができる - 例えば、センサーを毎秒 1000 回読み取る代わりに、100 回読み取り、可能であれば外挿する。重要なのは、システムの動作変化を捕捉できるレートを選択することです。プラットフォームによっては、アダプティブ・サンプリング（適応型サンプリング）を採用しているものもある。これは、サンプリング・レートが負荷やデータの変動性に基づいて動的に調整されるもので、通常運用時にはオーバーヘッドを最小限にとどめ、異常が発生した場合はサンプリングを細かくして詳細を捕捉する。この適応的なアプローチにより、両世界のベストバランスが得られる。 集約と前処理： テレメトリーデータをソースで集約することで、多くのユースケースで忠実度の損失を最小限に抑えながら、エクスポートする必要のあるボリュームを大幅に縮小することができる。例えば、アプリケーションは何千もの同じようなイベント（例えば HTTP リクエスト）を経験するかもしれない。インスツルメンテーションは、各イベントをロギングするのではなく、カウンターやサマリー（例えば、1分あたりのリクエスト数やレイテンシーのパーセンタイル）を保持し、定期的に集約された結果のみを出力することができます。これにより、CPU作業（処理するイベントが減る）とメモリ（1つの集約された記録と何千もの生の記録）が削減される。スケーラブル・テレメトリー設計の核となる原則は、コンテキストが豊富なところでデータ削減を適用することである。アプリケーション・コンテキストの知識があれば、冗長なデータを組み合わせたり、フィルタリングしたりすることができる。例えば、MetricSifterアプローチ（Tsubouchiet al.）は、時系列メトリクスを分析し、与えられた障害シナリオに無関係なメトリクスをフィルタリングすることで、関連するメトリクスのみに焦点を当て、メトリクスの数を効果的に削減します（20240121_dissertation.pdf ）。より一般的には、遠隔測定システムはしばしばロールアップ・カウンター、ヒストグラム、スケッチを採用している。スケッチ（レイテンシの分位スケッチのようなもの）は、全ての個々の測定値の代わりに、非常にメモリ効率の良い近似分布を送信することを可能にする。 フィルタリングと選択的計測： すべての指標やスパンが同じように価値があるわけではありません。不要な計測をオフにすることで、オーバーヘッドが削減されます。オペレーターは、冗長なモジュール（例えば、SQL クエリーのトレースや細かいデバッグ・ログ）を、必要でない時に無効にすることができます（パフォーマンス | OpenTelemetry ）。多くの遠隔測定エージェントは、実行時に特定のデータ収集を有効/無効にする設定オプションをサポートしています。例えば、OpenTelemetry Java エージェントは、（JDBC トレースのような）特定のインスツルメンテーションがうるさすぎる場合、それを無効にすることができます（パフォーマンス | OpenTelemetry ）。これは、それらのコンポーネントが実行されるのを防ぎ、CPUを節約します。同様に、重要度によってイベントをフィルタリングすることができる - 例えば、全ての情報ログではなく、警告とエラーだけをログに残す。コンテキストベースのフィルタリングは強力だ：ソースで、コンテキストに基づいて何を記録するかを決定する。多くのマイクロサービスを経由するユーザーリクエストは、エラーフラグが検出されない限り、オーバーヘッドを減らすために1つか2つの主要なサービスでのみトレースされるかもしれない。このような動的なテレメトリーは、システムが異常の詳細を増加させ、ルーチン操作の詳細を低下させることができる。 早期に（エッジで）削減を適用する： 最近の研究によるアーキテクチャのガイドラインは、可能な限り早い段階でデータを削減することである。インスツルメンテーション・レイヤー（アプリやホスト内）で集約やサンプリングを行うことで、我々は詳細なコンテキストを活用し、どのデータを組み合わせたり省略したりできるかについて、情報に基づいた決定を行うことができる（20240121_dissertation.pdf ）。これにより、どうせ後で集計されるだけの大きな生の遠隔測定ストリームを転送するリソースの無駄を省くことができる。例えば、カーネル内のネットワークフローモニタは、ユーザ空間に送信する前に、多くの小さなソケットイベントを1つのサマリーレコードにまとめるかもしれない（例えば、同じサービスへの複数の短いTCPコネクションをバンドルする）(20240121_dissertation.pdf)。このカーネル内フローバンドルアプローチは、ユーザー空間のフローレコードを減らし、実験ではCPU使用率を大幅に削減した(20240121_dissertation.pdf)。このコンセプトは、様々なシステムで採用されている。例えば、ログ行を組み合わせたり、メトリクスを事前に計算したり、不要な詳細を削除したりといった、よりスマートな収集を、可能な限りソースの近くで行う。こうすることで、パイプラインを通じて伝搬されるデータが少なくなり、下流の各コンポーネントの負荷が軽減される。 サンプリングとアグリゲーションを注意深く使用することで、遠隔測定システムは、モニタリングに必要な主要シグナルを保持したまま、リソースのフットプリントを桁違いに縮小することができる（多くの場合、生データの1～10％しか収集しない）。これらの技術は、精度が許容できるように調整されなければならない。例えば、エラー・イベントが決してサンプリングされないようにしたり、集約されたメトリクスが依然として精度要件を満たすようにする。うまくいけば、データ削減は遠隔計測のエンドユーザーにはほとんど見えません（エンジニアは必要な洞察を得ることができます）。 バッチ処理と効率的なデータ処理 テレメトリーデータがどのようにバッファリングされ送信されるかは、オーバーヘッド、特にレイテンシとCPU使用率に大きく影響します。バッチングは、複数のデータポイントにわたってオーバーヘッドを償却するための一般的なテクニックです： テレメトリ・エクスポートのバッチ化： テレメトリのエクスポートをバッチ化する：テレメトリを一度にひとつずつ（例えば、すべてのトレーススパンやメトリックを個別のネットワークメッセージとして）送信するのは非効率的です。メッセージが小さいと、ネットワークコールや I/O 操作の固定オーバーヘッドが支配的になります。複数の遠隔測定レコードを一緒にバッチすることで、我々は送信やディスク書き込みをより少ない頻度で呼び出します。これにより、CPU 割り込み/コンテキストスイッチが減り、スループットが向上します。例えば、OpenTelemetryのコレクターとエージェントは、バッチスパンプロセッサーを使用し、短いインターバル（例えば5秒または最大Nスパン）のスパンを集約し、それらを一度に送信します。DoorDashのエンジニアは、バッチスパンプロセッサーを使用することで、テレメトリーパイプラインのスループットが大幅に向上し、CPU使用率が下がることを発見した（OpenTelemetryのスパンプロセッサーを高スループットのために最適化 ... ）。クラウド・テレメトリーでは、即時送信からバッチ送信に切り替えることで、スループットが5～10倍向上するのが一般的です。 調整可能なバッチサイズ（遅延とCPUのトレードオフ）： バッチサイズが大きいと、リソースをより効率的に使用できる（アイテムあたりのオーバーヘッドが少ない）が、各アイテムを配信する際の待ち時間が長くなる（バッチ内で待機するため）。システムには、バッチサイズを調整するためのつまみが用意されていることが多い。例えば、Istio のテレメトリの以前のバージョンには、プロキシからデータを収集するコンポーネント（Mixer）があった。オーバーヘッドを減らすために、開発者はレポート呼び出しのバッチサイズのコントロールを導入した（Istio のテレメトリのオーバーヘッドと MixerV2 の情報 - ポリシーとテレメトリ - Istio について）。バッチサイズを大きくすることで、1メッセージあたりのCPUオーバーヘッドを減らすことができます（呼び出し回数が減ります）。あるチームでは、バッチ処理は助けになるものの、ある点を超えるとリターンが減少すると指摘している（Istio telemetry overhead and MixerV2 info - Policies and Telemetry - Discuss Istio ）。一般的な原則は、可観測性のためのレイテンシ要件に違反することなく、可能な限りバッチ処理することである。多くの最新の可観測性システムは、バッチ処理による大きな効率向上と引き換えに、小さな遅延（せいぜい数秒）を好む。 バッファリングとバックプレッシャー：効率的な遠隔測定パイプラインは、遠隔測定の生成と消費を切り離すために、インメモリバッファ（多くの場合、ロックフリーのキューやリングバッファ）を使用します。インスツルメンテーションはバッファに素早く書き込み、次に進みますが、バックグラウンドのスレッドやエージェントはバッファから読み込み、データを処理/送信します。このバッファリングはスパイクを滑らかにし、遠隔測定バックエンドのスローダウンでアプリケーションがブロックされるのを防ぎます。オーバーヘッドを最小化するために、これらのバッファは多くの場合、共有メモリ内の固定サイズのリングバッファです - 非常に高速な書き込みと読み取りが可能ですが、コンシューマが遅れをとった場合、古いデータを上書きする可能性があります（アプリを停止するのではなく、プレッシャーの下で優雅にデータをドロップします）。この設計は、遠隔測定収集がアプリケーションを停止させないことを保証する。これは、多くの高性能ロガーと計測システムで使用されている。例えば、eBPFのユーザー空間とのやり取りは、カーネルが書き込み、ユーザー空間のリーダーが排出するリングバッファを使用します。この設計は、最小限のコピーとロックで大量のイベントを効率的に転送するために明示的に選択されました（eBPF based instrumentation ）（eBPFベースの計測）。 圧縮とエンコード： 厳密にはCPUの 「オーバーヘッド 」ではないが、データがどのようにエンコードされるかは、ネットワークのオーバーヘッドや、エンコード/デコードのためのCPUに影響を与える可能性がある。テレメトリーシステムは、バイナリプロトコルを使用することが多くなり、大きなデータのバッチは圧縮されます。例えば、OpenTelemetryはバイナリのProtobufフォーマットでメトリクスをエクスポートすることができ、これはJSONのようなテキストフォーマットよりもはるかに小さく、解析が速い。いくつかのシステムは、ネットワーク・ペイロードを5-10倍削減するために、送信前に（例えばgzipやlz4を使って）バッチ化されたテレメトリーを圧縮します（Achieve a 10x Reduction in Telemetry Traffic Using OpenTelemetry ...）。圧縮はCPUを消費するが、バッチ処理であれば、特に帯域幅に制約のあるシナリオや、ストレージコストを下げるために、I/Oオーバーヘッドを削減するために、償却コストに見合う価値がある。 全体として、バッチ処理と最適化されたデータ処理により、遠隔測定データの移動が可能な限り効率的になります。その結果、CPU 使用率が下がり（システムコール、コンテキストスイッチの数が減る）、レイテンシが制御される（通常、数秒以下のオーダーで、ほとんどのモニタリングニーズには許容可能）。メトリックスとトレースをバッチ処理することは一般的なベストプラクティスであり、事実上すべての最新の遠隔測定フレームワークが、このようなことを行っています。 遠隔計測のためのシステムレベルの最適化 計測コードそのものだけでなく、基礎となるシステムとハードウェアにもオーバーヘッドを減らすチャンスがあります： ハードウェア・カウンターの活用： ハードウェア・カウンターの活用：最近のCPUはパフォーマンス・モニタリング・ユニット（PMU）を持っており、実行された命令、キャッシュ・ミス、分岐予測ミスなどのイベントを、ごくわずかなオーバーヘッドでカウントする。ツールはこれらのカウンターを利用することで、コードにインスツルメンテーションを行うことなく、遠隔測定（CPUサイクルやキャッシュ使用量など）を行うことができます。これらのカウンターを定期的に（LinuxのperfやOSのAPIを使って）読み取ることは、すべての命令や関数コールを計測するよりもはるかに安上がりだ。同様に、いくつかのNIC（ネットワークカード）は、フロー統計とエラーカウントを保持しており、ネットワーク・テレメトリーのために読み取ることができる。このようなハードウェアのテレメトリー機能を利用することで、基本的にアプリケーションのコストはゼロで、システムレベルの洞察を得ることができる。 OSのスケジューリングと分離： オーバーヘッドを抑える一つの方法は、テレメトリ作業を専用の CPU コアか、少なくとも別々のスレッドに分離することです。遠隔測定コレクションを（可能であれば）別のコアで実行することで、メインのアプリケーションスレッドはモニタリングタスクとのコンテキストスイッチを避けることができます。これは高性能システムで見られるパターンである。例えば、1つのコアがメトリクスの集約と出荷を担当し、他のコアは邪魔されずにアプリケーションコードを実行できる。全体的なCPUコストは残るかもしれないが、クリティカルなリアルタイム・スレッドが影響を受けないように管理される。裏を返せば、テレメトリの低レイテンシが必要な場合、テレメトリスレッドに高い優先度を与えたり、迅速な処理を保証するためにリアルタイムスケジューリングを行うこともできますが、通常はアプリケーションが優先されます。目標は、干渉を防ぐことである。監視スレッドをうまくダウンさせるか、固定することで、そのオーバーヘッドがアプリのレイテンシ・スパイクとして現れないようにする。 ネットワーク・テレメトリーのためのカーネル・バイパス： ネットワーキングでは、多くのオーバーヘッドがカーネル・ユーザー間のコンテキスト・スイッチング（パケットがカーネルを通過し、解析のためにユーザー空間にコピーされる）から発生する可能性がある。XDP（eXpress Data Path）やDPDKのような技術は、カーネルの一部をバイパスしたり、ドライバー・コンテキストでカスタム・コードを実行することで、オーバーヘッドを少なくして高速にパケットを処理することを可能にする。テレメトリの場合、大量のネットワークトラフィックを検査する必要がある場合（例えば、フローごとの帯域幅を測定したり、異常を検出したりする場合）、XDPやDPDKベースのエージェントを使用することで、標準的なソケットキャプチャを使用するよりもはるかに低いCPUで数百万のパケットを処理することができます。基本的に、これらのテクニックは、合理的な方法でパケットを処理することで、カーネルネットワークスタックの汎用性を効率性と引き換えにします。サンプリング（例えばN個のパケットのうち1個だけを検査する）と組み合わせることで、これはネットワークの強力な低オーバーヘッド・モニタリング手法となる。 最適化された遠隔測定ストレージ： この質問は収集のオーバーヘッドに焦点をあてているが、システムレベルの最適化はテレメトリがどのように保存され、クエリされるかにまで及ぶことは注目に値する。例えば、高インジェストレートの遠隔測定システムは、最近のデータにはインメモリ時系列データベースを使用し、古いデータは（HeteroTSDBアプローチのように）ディスクにロールして、スピードとコストのバランスをとるかもしれない(20240121_dissertation.pdf)(20240121_dissertation.pdf)。効率的なストレージは、多くのデータを収集してもメモリやディスクを圧迫しないことを保証する。これは直接的に計測のオーバーヘッドを削減するわけではないが、遠隔計測パイプラインにおけるバックログやパフォーマンスの問題を防ぐことができる。 動的制御とフィードバック： システムレベルのビューは、遠隔計測の使用と収集の間のループを閉じることを可能にします。バックエンド分析が特定のデータが有用でないことを発見した場合、計測レイヤーにシグナルを送ることができます。逆に、より詳細が必要な場合（例えば、異常が検出された場合）、システムは関連するメトリクスの収集を一時的に増やすことができる。このフィードバック駆動型遠隔測定システムのコンセプトは、活発な研究の方向性である(20240121_dissertation.pdf)(20240121_dissertation.pdf)。これは、ほとんどの時間オーバーヘッドを最小化し（必要なものだけを収集する）、必要なときにデータ収集のコンテキストを意識したブーストを保証するものである。この実装にはシステム全体の調整（計測、ストレージ、分析レイヤーの通信）が必要だが、クラウド環境では最新のオーケストレーションとコントロールプレーンによって容易になる。 要約すると、システムレベルの最適化は、効率的な遠隔測定を実行するための基盤を提供する。カーネル、ハードウェア、スマートなリソース管理を利用することで、テレメトリのオーバーヘッドをシステムの 「ファブリック 」の中にさらに隠すことができる。これらのテクニックの多くは、成熟したモニタリング製品の舞台裏にあります - ユーザーは、これらの最適化のおかげで、モニタリングをオンにしても、期待したほど遅くならないことに気づくだけかもしれません。 テレメトリーのための効率的なネットワーク・モニタリング ネットワーク・テレメトリーは、スケールの大きなネットワーク・モニタリングが非常にデータ集約的であるため、特別な注目に値する。ネットワーク・トラフィックとコネクションのモニタリングは（パフォーマンスとセキュリティのために）極めて重要だが、ナイーブに全てのパケットをキャプチャしたり、全てのコネクションをロギングしたりすると、システムを圧倒する可能性がある。ネットワーク・テレメトリのオーバーヘッドを減らす戦略には以下が含まれる： フロー・サンプリング（NetFlow/sFlow）： 従来のネットワーク・テレメトリーは、パケット単位のロギングではなく、フロー記録を使用することが多い。例えば、Cisco の NetFlow とより最新の sFlow プロトコルは、N 個のパケットのうち 1 個のパケット（または N 個のフローのうち 1 個のフロー）をサンプリングし、フローに関するサマリー統計（ソース、宛先、バイトなど）を記録します。特にsFlowは軽量に設計されている。サンプリングは通常スイッチ/ルーターのハードウェアで行われ、エージェントはサンプリングされたデータを受信するだけである。これにより、トラフィックの統計的な画像を提供しながら、CPU使用率を低く抑えることができる。大規模なデータ・センターでは、オペレータは1:1000または1:10000のパケット・レートでサンプリングすることがありますが、これはすべてのイベントを処理しなくても、トレンドや大ヒットを検出するのに十分です。 カーネル・レベルのソケット・トレース： eBPFのような技術（または他のシステムでは歴史的にSystemTap/DTrace）を使用すると、低オーバーヘッドでカーネルレベルのネットワークイベント（TCP接続、アクセプト、送受信コールのような）をトレースすることができます。複数のTCP/UDPソケット・イベントをカーネル内の1つの論理フローに集約し、ユーザー空間に送信されるメッセージ数を削減した（20240121_dissertation.pdf ）。これにより、ネットワークフロー数が劇的に増加しても、CPUオーバーヘッドは2.2%以下に抑えられた(20240121_dissertation.pdf)。この効率性は、パケットごとやコネクションごとのコンテキスト・スイッチのオーバーヘッドを排除することに起因する。カーネルは、新しいコネクションごとにユーザー空間に通知する代わりに、アクティブなフローのハッシュ・テーブルを維持し、定期的に集約された情報をエクスポートするだけである。bcc (BPF Compiler Collection)やbpftraceのようなツールを使えば、このようなトレースを簡単に実装できる。例えば、BPFのコードを数行書くだけで、プロセスごとにすべてのTCPコネクションをカウントしたり、HTTPリクエストのレイテンシを計測したりすることができる。これは、アプリケーションにプロキシや重いロギングを挿入するよりもはるかに少ないオーバーヘッドでスケールする効率的なネットワークモニタリングをもたらします。 ネットワークハードウェアのテレメトリー： いくつかの最先端のアプローチは、テレメトリーをネットワークデバイス自体に押し込みます。例えば、Inband Network Telemetry (INT)は、ネットワークスイッチがパケットにテレメトリーのメタデータを追加するものです（タイミング、キューの長さなどを記録します）。これは、オーバーヘッドを最適化されたスイッチ内の専用ASICに移し、サーバーを完全に解放する。INTや同様の技術は（主に先進的なデータセンター・ネットワークで）出現しつつあるが、これは遠隔測定にハードウェアを活用する傾向を示している。もう一つの例は、eBPFやP4プログラムを実行できるSmartNICやプログラマブルNICの使用である。SmartNICは、例えば、ホストCPUが関与することなく、フローごとにパケットをカウントしたり、ドロップを検出したりすることができる。ネットワーク・テレメトリーをハードウェアにオフロードすることは、ホストのCPUオーバーヘッドがほぼゼロになり、非常に忠実なモニタリングができる可能性があることを意味するが、それには高度な機器が必要である。 低オーバーヘッドのプロトコルとストリーミング： 従来のネットワーク統計の取得方法（SNMPポーリングのような）は、実はあまり効率的でタイムリーではありません。新しいストリーミング・テレメトリー・アプローチは、デバイスやエージェントからの持続的な接続（多くの場合gRPCやMQTTベース）を維持し、メトリクスを継続的にストリーミングします。これは、リクエスト毎のポーリングのオーバーヘッドを回避し、より低レイテンシのアップデートをもたらします。ソフトウェアシステムでは、ログ／メトリクスにストリーミングアプローチを使用する（例えば、protobufメッセージで単一のTCP接続を介してデータをプッシュする）ことは、多くの接続やHTTPコールを開くよりもCPUおよびネットワーク効率が高い。例えば、FacebookのOsqueryや同様のエージェントは、イベントをストリームするためにアクティブなソケットを維持し、定期的なポーリングよりも効率的であることが証明されている。 ネットワークデータのエッジ集約： 一般的なデータ削減と同様に、ネットワーク・テレメトリーも階層的アグリゲーションから恩恵を受けることができる。各ホスト上のエージェントはそのホスト上の接続の全てのメトリクスを集約し、中央システムが全ての接続の生データを受信するのではなく、1つのサマリーを中央システムに送信するかもしれない。より高いレベルでは、データをさらに要約する中間アグリゲータ（おそらくラックまたはクラスタごとに1つ）を持つことができる。これは、コンテンツ・デリバリー・ネットワークや大規模なモニタリング・セットアップが、スケールアップするためにコレクターのツリーを使用する方法に似ている。各レイヤーは量を減らし、単一のボトルネックリンクやノードが完全な生フィードを処理する必要がないようにする。その結果、データがメインの分析ポイントに到達するまでに、その量は削減され、管理しやすくなり、ネットワークや処理ノードへのストレスが軽減されます。 効率的なネットワーク・モニタリングは、スマートなサンプリング、低レイヤー（カーネル／ハードウェア）の活用、アーキテクチャ設計（分散収集）の組み合わせである。上記のアプローチは、非常に高い帯域幅のネットワーク（マルチギガビット、数百万フロー）であっても、低いオーバーヘッドで監視できることを示している。Cilium Hubble（ネットワークの可観測性のために）や CloudFlare のネットワークパフォーマンス監視のための eBPF の使用（eBPF - Introduction, Tutorials & Community Resources ）のようなツールにおける eBPF のようなテクニックの成功は、ネットワーク遠隔測定がもはや遅い、重い方法に頼る必要がないことを強調している。 ソリューションの比較分析 テレメトリー計測には複数のソリューションが存在し、それぞれにオーバーヘッドの点で長所と短所があります。我々はいくつかのカテゴリーを比較する： アプリ内計測 vs. 外部モニタリング： アプリケーション内ライブラリ（コードに統合された OpenTelemetry SDK のような）は、豊富なコンテキストと柔軟性を提供しますが、ユーザースペースで実行され、アプリケーションプロセスでオーバーヘッドを発生させます。外部モニタリング（eBPF ベースやサイドカー・エージェントの使用など）は、アプリへの影響を少なくして、同様のデータを収集できることがあります。例えば、OpenTelemetry 自動計測エージェントは、トレースのために各リクエストに数ミリ秒のオーバーヘッドを追加するかもしれないが、eBPF ベースのツールは、サブミリ秒のオーバーヘッドでシステムコールを監視することで、同じリクエストをトレースすることができる（OpenTelemetry and eBPF: Everything You Need to Know ）。トレードオフは、アプリ内インスツルメンテーションは、低レベルのツールが知らないかもしれない、より高いレベルのセマンティクス（アプリケーション変数、カスタムスパン）を捕らえることができるということです。アプリケーション固有のデータには OpenTelemetry を使い、システムレベルのテレメトリにはそれを補完する eBPF を使い、それらを組み合わせて全体像を把握するというハイブリッドなアプローチが出現しつつある。 エージェントベースの遠隔測定とエージェントレス： 従来の APM ソリューション（New Relic、Datadog など）は、コードを計測する言語固有のエージェントを使用することが多い。これらはかなり最適化できますが、それでもアプリの一部として実行されます。新しいエージェントレスまたは 「ゼロ計測」アプローチは、プラットフォームやホストの機能を使用することで、そのオーバーヘッドを回避しようとしている。例えば、マネージド・ランタイムからいくつかのデータを自動収集できるGoogle Cloudのオペレーション・スイートや、重いコードを注入することなくデータを収集するためにWindows上のパフォーマンス・カウンターとイベント・トレーシングを使用できるAzureのアプリケーション・インサイトなどがある。エージェントレスアプローチは、CPUオーバーヘッドを低くする傾向があるが、アプリ内エージェントが捕捉する全てを捕捉しないかもしれない。OpenTelemetryはその両方を提供します：エージェントと一緒に使うことも（自動計測）、手動で計測することもできます。実際には、多くの場合、オーバーヘッドを減らすために、最小限の手動計測とインフラストラクチャシグナルへの依存を選択している。 eBPFとDTrace/SystemTapの比較： Linuxでは、eBPFは、安全性と低いオーバーヘッドにより、実運用ではSystemTapにほとんど取って代わられている。DTrace (on Solaris/macOS) と SystemTap (Linux) は、強力なダイナミック・インスツルメンテーションを可能にしますが、多くの場合、より高いコストと複雑さを伴います。eBPF の設計（ベリファイア、ネイティブ・コードへの JIT コンパイル）は、非常に効率的な実行につながります（OpenTelemetry and eBPF: Everything You Need to Know ）（OpenTelemetry and eBPF: Everything You Need to Know ）。SystemTapは対照的に、より高いオーバーヘッドとリスクを持つ可能性のあるカーネルモジュールを挿入します。DTraceは特定のプローブに対しては非常に効率的だが、Linuxでは広く利用できない。そのため、最新のLinux環境では、eBPFベースのソリューション（Cilium、Pixie、Groundcoverなど）が低オーバーヘッドの遠隔測定に適しているが、他のOS環境では、類似の機能（WindowsのETWやMacの軽量プロファイリングツールなど）が同様の役割を果たしている。 メトリクス vs. トレース vs. ログ： 異なるテレメトリーデータタイプは、本質的に異なるオーバーヘッドプロファイルを持っています。メトリクス（数値測定）は一般的に安価である。例えば、カウンターをインクリメントするだけで、通常O(1)であり、非常に高速です。うまく設計されたメトリクス・パイプラインは、集約によるオーバーヘッドを最小限に抑えながら、毎秒数百万のメトリクスを処理できます。ログは高価になる可能性があります：ログは、多くの場合、大量で、文字列を多用します。ログ行を書くには、文字列のフォーマットとI/Oが必要になり、その分遅くなります。規模が大きくなると、冗長なロギングは多くのCPUとI/Oを消費する可能性がある（これが、多くのシステムが本番環境でログレベルを下げている理由である）。トレースはその中間に位置します。大量に記録されますが（全てのリクエストは複数のスパンレコードを生成するかもしれません）、構造化されており、サンプリングすることができます。一つのトレーススパンは、通常、いくつかのフィールド（タイムスタンプ、ID）を持つ小さなオブジェクトである。トレースのオーバーヘッドはサンプリングに依存する。ヘビーサンプリング (例えば1%)では、トレースのオーバーヘッドはわずかであるが、100%(全リクエストをトレース)では、かなりのオーバーヘッドになる。従って、遠隔測定ソリューションは、しばしば次のことを推奨します： 日常的なモニタリングにはメトリクスを使い（安価）、ログは控えめに使い（重要なイベントのみ）、サンプリングでトレースを使う。この組み合わせにより、管理可能なオーバーヘッドで良好なカバレッジが得られる。 商用APMツールとオープン・ソリューションの比較： 多くの商用ツールは、独自の最適化されたエージェント（Dynatraceのバイナリエージェント、New Relicのエージェントなど）を持っており、最小限のオーバーヘッドになるようにチューニングされています。OpenTelemetry のようなオープンソースのソリューションは柔軟性を提供するが、ユーザーが設定やチューニング（適切なサンプリングの設定など）を行う必要がある。オーバーヘッドに関しては、よく知られた APM エージェントは通常、CPU オーバーヘッドを一桁台の低いパーセンテージに抑え、メモリオーバーヘッドを数十 MB に抑えている。例えば、eBPF を使用した OpenTelemetry の継続的プロファイラでは、テストにおいて CPU は ~1%、RAM は 250 MB が上限とされており（open-telemetry/opentelemetry-ebpf-profiler - GitHub ）、これは多くのベンダーが宣伝しているものと同じである。違いは特定のワークロードに現れる。あるソリューションはトレースのための低いCPUオーバーヘッドが得意かもしれないが、別のソリューションはより多くのCPUを使うがメモリはより少ない、といった具合だ。傾向としては、オープンツールも商用ツールも、同様のベストプラクティス（可能な限りeBPFを使用する、作業をオフロードする、データを圧縮するなど）に収束しつつある。 古いアプローチと新しいアプローチ 歴史的に、システム・モニタリングは、頻繁なポーリング（topを呼び出したり、毎秒/procを読んだりするような）と大量のロギングに依存していた。新しいアプローチでは、イベント・ドリブン・テレメトリー、ストリーミング、インテリジェント・フィルタリングを使用する。例えば、全てのプロセスのCPU使用率を毎秒ポーリングする（これは多くのコードを目覚めさせる）代わりに、最近のエージェントはカーネルイベントを購読したり、プロセスが終了したりスケジューラのティックが発生したときに通知を受けるためにBPFを使用したりします。このように、新しいソリューションは一般的に、同じ情報に対してより少ないオーバーヘッドしか発生させません。実際に比較分析すると、次のようになる： TCPメトリクスを収集するためにeBPFを使用する場合、使用するCPUは2%未満であるのに対し、straceやlsofポーリングを使用するレガシー・アプローチでは10%以上のCPUを使用する可能性がある。改善は明らかであり、これらの技術が成熟するにつれて、古い高オーバーヘッドの技術は段階的に使用されなくなると我々は予想している。 ソリューションの比較において、システム（OSまたはカーネル）と深く統合し、スマートなフィルタリングを適用するものは、そのような最適化なしに高いレベルで動作するものを上回る傾向があることは明らかである。とはいえ、使いやすさやデータの完全性も要因のひとつである。目標は、許容できるオーバーヘッドで必要な可視性を提供するソリューションを選択することだ。多くの場合、組み合わせが最適である（例えば、eBPFベースのシステム可測性ツールと、ビジネスロジックのためのアプリケーションレベルのトレースを併用する）。 新たなトレンドと将来の方向性 遠隔測定と可観測性の分野は、オーバーヘッドを減らすことに重点を置いて、急速に進化しています。いくつかの新たなトレンドと研究の方向性は以下の通りです： 統一された遠隔測定パイプライン（可観測性パイプライン）： あらゆる種類のテレメトリ（ログ、メトリクス、トレース）をインジェストし、保存前に設定可能な方法（フィルタリング、サンプリング、ルーティング）で処理する集中型パイプラインへの動きがある。Grafana Mimir/Tempo、Honeycomb Refinery、Chronosphere のパイプラインのようなプロジェクトは、チームがインジェスト時に遠隔測定データに変換を適用することを可能にする。これは、価値の低いデータを早期に削除またはダウングレードすることで、オーバーヘッドを管理できることを意味する。これは可観測性のためのミドルウェアのようなもので、ポリシー（「サービスAからのトレースを10%でサンプリングする 」など）を一律に実施することができる。これらのパイプラインは、しばしばコストとオーバーヘッドの削減を主な目標としている - 例えば Chronosphere は、このようなテクニックによって、テレメトリーデータ量（とそれを処理するインフラ）の大幅な削減を主張している（Achieve a 10x Reduction in Telemetry Traffic Using OpenTelemetry ...）。この傾向は、テレメトリの肥大化を積極的に削減するために、組織がきめ細かいコントロールを望んでいることを示している。 「Use-First」 テレメトリー収集： 伝統的に、チームは可能な限り多くのデータを収集していました（「最初に収集し、後で質問する」）。現在では、「使用優先」（use-first）、つまり、予想される使用方法に基づいて、より選択的にデータを収集する方向にシフトしている（20240121_dissertation.pdf ）。最近の研究で提唱されているこの考え方は、フィードバックループのある遠隔測定システムの設計を示唆している。例えば、特定のメトリクスがダッシュボードやアラートで使用されていない場合、システムはリソースを節約するためにそれらのメトリクス収集を停止することができる。逆に、新たなパフォーマンス上の問題が発生した場合、システムは一時的にその領域のデータを追加収集するかもしれない。機械学習やアナリティクス（どの遠隔測定が有用かを特定する）を使ってこのプロセスを自動化することは、活発な分野である。最終的なゴールは、価値を提供するものだけを収集することでオーバーヘッドを最小化する、自己調整型遠隔測定システムである(20240121_dissertation.pdf)。初期の実装は、異常検知アルゴリズムに基づいてログレベルやメトリックの詳細を調整するAIOpsプラットフォームで見られる。 継続的プロファイリングとeBPF Everywhere： eBPFのような低オーバーヘッドの技術のおかげで、継続的プロファイリング（本番環境での常時CPU/ヒープ・プロファイリング）が登場した。Parca や Pixie、そして OpenTelemetry eBPF プロファイラのようなツールは、全てのプロセスのスタックトレースを高頻度かつ常時サンプリングすることができ、オーバーヘッドを最小限に抑えることができます（多くの場合、CPU は 1-2% 未満です）（open-telemetry/opentelemetry-ebpf-profiler - GitHub ）。以前は、オーバーヘッドのためにこのようなことは不可能で、プロファイリングはアドホックにしか行われなかった。傾向として、プロファイリングはテレメトリの標準的な一部となりつつあり、オーバーヘッドの削減によってメトリクス/トレースを補完している： GPUモニタリング、IPCモニタリングなどであり、Linux以外のシステムでも同様の技術が模索されている（例えば、Windows用のeBPFがプロトタイプ化されている）。我々は、eBPFベースのインスツルメンテーションがOpenTelemetryのようなフレームワークと統合され、開発者がハンドコーディングすることなく、また大きなパフォーマンスヒットを起こすことなく、多くのデータを取得できるようになることを期待している（eBPF based instrumentation - Odigos）（OpenTelemetry and eBPF: Everything You Need to Know）。 エッジとクライアントサイドの遠隔測定： アプリケーションはサーバーだけでなく、エッジ・デバイスやユーザー・クライアント（モバイル・アプリ、ブラウザ、IoTデバイス）にも及ぶため、これらから低いオーバーヘッドでテレメトリを収集することがフロンティアとなる。モバイルやウェブでは、オーバーヘッドがユーザーエクスペリエンス（バッテリー寿命、アプリのスムーズさ）に直接影響するため、遠隔測定は極めて軽量でなければならない。サンプリングや圧縮のような技術は、そこではさらに重要である。我々は、ブラウザがウェブアプリのために、テレメトリ（ナビゲーションのタイミングやリソースのタイミングなど）を低オーバーヘッドで提供するパフォーマンスAPIを実装しているのを見ている。IoT側では、デバイスは超小型のバイナリ遠隔測定を使用し、帯域幅とCPUを節約するために要約のみを送信する。エッジ遠隔測定とクラウド遠隔測定の融合には、全体のオーバーヘッドを低く抑え、データを階層的に集約するように、エンドツーエンドの最適化が必要になる。 機械学習による異常駆動型遠隔測定： もう一つのトレンドは、いつ何を収集するかを決定するためにMLを使用することである。例えば、MLモデルがサービスのメトリクスに異常を検出し、そのサービスのより詳細なトレースやロギングを短期間トリガーするかもしれない。こうすることで、問題がありそうなときだけオーバーヘッドが発生し、リソースの使用を必要性に合わせることができる。これらの 「インテリジェント・テレメトリー 」システムは実験的なものだが、適応型計測の考え方に沿ったものだ。もし成功すれば、定常状態のオーバーヘッドを大幅に削減し（物事が正常であれば、基本的な測定基準以上のオーバーヘッドはゼロに近い）、何か異常が起きたときだけオーバーヘッドを増加させることができる。 標準化と相互運用性： OpenTelemetryのような努力は、遠隔測定がどのように収集され、どのようにエクスポートされるかを統一している。これは直接オーバーヘッドを削減するものではないが、最適化を一箇所（SDK/エージェント）で実装でき、多くのツールに恩恵をもたらすことを意味する。例えば、OpenTelemetry SDK は、全てのバックエンドツールが使用できるバッチエクスポーターを提供するので、そこでの改善（より良いロックフリーのキューやよりスマートなサンプリングアルゴリズムなど）はエコシステム全体に伝搬します。さらに、OpenTelemetryとeBPFの統合（コードを変更することなく自動計測）が進められています（OpenTelemetry and eBPF: Everything You Need to Know）（OpenTelemetry and eBPF: Everything You Need to Know ）。OpenTelemetryとeBPFを組み合わせるというgroundcoverのアプローチはその一例です：eBPFを使ってデータを取り込み、それをOpenTelemetryのフォーマットにフィードします（OpenTelemetry and eBPF: Everything You Need to Know）（OpenTelemetry and eBPF: Everything You Need to Know ）。これは、標準的なテレメトリーデータフォーマットが、ボンネットの下の非常に効率的なキャプチャメカニズムによって満たされるトレンドになる可能性がある。 要するに、遠隔測定ワークロードのスケーリングの未来は、自己最適化され、プラットフォームと深く統合されるようだ。包括的なテーマは効率性であり、無駄を最小限に抑えて適切なデータを適切なタイミングで収集することである。新たなソリューションは、運用チームに忠実度の高い可視性を与え、システムを円滑に稼動させ、計測とパフォーマンスの間の従来の緊張関係を解決することを目指している。 結論 遠隔計測を大規模な分散システムに拡張するには、計測のオーバーヘッドに注意する必要がある。軽量な計測技術（eBPF や効率的なトレースポイントなど）、スマートなデータ削減（ソースでの適応的サンプリング、フィルタリング、集約）、システムレベルの最適化（バッチ処理、カーネルレベルのモニタリング、ハードウェアのサポート）を組み合わせることで、エンジニアは遠隔計測の CPU とメモリの使用量を劇的に削減することができる。これらの方法は、可観測性データを収集する際に、わずかなレイテンシ（多くの場合、マイクロ秒から数ミリ秒）と最小限のリソース競合しか発生させないことを保証し、アプリケーションのパフォーマンスを維持する。我々は、ネットワークフローのカーネル内集約のようなアプローチが、オーバーヘッドをCPUの数パーセント以下に抑えることができることを見てきた(20240121_dissertation.pdf)。また、アダプティブ・サンプリングは、データ量（とコスト）を半分以上に削減することができ、洞察の損失はごくわずかである(The procedure of observability SMS | Download Scientific Diagram)。 既存のソリューションは、統合されたAPMツールからオープンソースのフレームワークまで多岐にわたるが、オーバーヘッド削減のためのこれらのベストプラクティスを共有することが多くなっている。比較的、カーネル機能と非同期処理を活用する最新のソリューションは、古い、より侵入的な方法よりも効率性において明らかに優位に立っている（OpenTelemetry and eBPF: Everything You Need to Know ）。テレメトリのニーズが成長し続けるにつれ、業界はパフォーマンスのオーバーヘッドを最適化のための重要な指標として扱う全体的な可観測性アーキテクチャへと移行しています。ユビキタスeBPFの使用、フィードバック駆動型遠隔測定、統合パイプラインなどの新たなトレンドはすべて、高解像度でありながらコスト効果の高い可観測性を目指しています。目標は、オーバーヘッドに比例してスケールすることなく、量と詳細をスケールする可観測性スタックである。 要約すると、計測のオーバーヘッドを削減することは、遠隔計測収集において、よりハードに働くのではなく、よりスマートに働くことである。全てのレベル（アプリケーション、OS、ネットワーク）で巧みなエンジニアリングを行うことで、観測されるシステムへの影響を最小限に抑えながら、ほぼリアルタイムで詳細な遠隔測定を実現することができる。これによって、組織はワークロードの増大に応じて、「システムを可観測する」ことでシステムの動作が遅くなることを恐れることなく、自信を持ってモニタリングを拡大することができる。この分野での絶え間ない技術革新は、今後さらに効率的でインテリジェントな遠隔測定ソリューションを約束し、堅牢な可観測性が最高のパフォーマンスと両立することを保証します。 出典 (20240121_dissertation.pdf) (The procedure of observability SMS | Download Scientific Diagram) (eBPF based instrumentation) (OpenTelemetry and eBPF: Everything You Need to Know) (Performance | OpenTelemetry) (Performance | OpenTelemetry) (All my favorite tracing tools: eBPF, QEMU, Perfetto, new ones I built and more - Tristan Hume).