所属は明らかにしていますが、個人登壇という立場で「Deep Dive Distributed Tracing」というセッションをしてきました。発表内容もW3C Trace ContextやOpenTelemetryなどを中心にしつつ、できるだけ特定のツールの考え方ではなく共通で考えられているものをもとに整理しています。アーカイブ視聴が可能なようです。
リアルタイムでzoomから発表したため、Q&Aができませんでした。コメントを基に2つほど回答したいと思います。追加で質問がある、という場合はTwitter までコメントお願いします。
分散トレースはUI、LoadBalancer、API Gateway、DBといったインフラ要素まで串刺しで見られないと不十分ではないか？
ボトルネックを分析する上で不十分なケースはあるでしょう。UI（Browser）上の処理は分散トレースを計測可能なことが多いですが、それ以外のLoadBalancerなどは現状難しいようです。アプリ内のトレースを分析することによって、まずアプリに原因があるかどうかの手がかりが得られます。また、アプリとアプリの間に原因がある場合、その間にある要素に手がかりがある可能性が高いので、その要素のトレメトリーデータ（メトリクスやログなど）を分析するという次のアクションに進むことができます。 また、それぞれの要素で少し異なるので補足します。
UI: UI側の理も最近では分散トレースの計測が可能になっています。例えばBrowserであれば、OpenTelemetryだとこのドキュメントです。また、Mobile やデスクトップクライアントアプリの場合も可能です。UIから直接バックエンドアプリを呼び出すのではなく、間に次に出てくるLoadBalancerやAPI Gatewayといった中間要素を挟むケースが増えてきており、どこにボトルネックがあるか分析しやすくするためにも分散トレースとして計測しておく価値が増えてきていると感じます。
- LoadBalancer、API Gateway: 分散トレースに参加させることが難しいものが多いため、前後のスパンから遅延があるかどうか見つけるというのが現状の分析手段になるかと思います。これらの要素はメトリクスやログをテレメトリーデータとして取得できることが多いため、分散トレースとこれらのデータを突き合わせて分析することになりそうです。そのため、例えば特定のHTTPヘッダーを記録に使っている場合は、そのヘッダーをトレース・スパンにもタグとして記録しておくことが重要になります。
DB: DBでの処理結果は、できるかぎりDB呼び出ししたスパンがDB呼び出しライブラリ経由で取得し、記録しておくことが重要です。例えばOpenTelemetryでどんなデータを記録すべきと考えているかは仕様のドキュメントにかかれています。
OpenTelemetryではサンプリングアルゴリズムはどれが選択できるのか？
OpenTelemetryではSamplerを設定することでアルゴリズムの選択が可能です。組み込みで用意されているものはこちらのドキュメントに記載されていますが、カスタマイズしたものを追加することも可能です。
