2023年1月の OpenTelemetry エンドユーザーディスカッションまとめ
Blog posts are not updated after publication. This post is more than a year old, so its content may be outdated, and some links may be invalid. Cross-verify any information before relying on it.
Henrik Rexed（Dynatrace）、 Michael Hausenblas（AWS）、 Pranay Prateek（SigNoz）、 Rynn Mancuso（Honeycomb）、 Reese Lee（New Relic）の協力のもと作成。
OpenTelemetry（OTel）コミュニティのユーザーは毎月集まり、実際の現場で OpenTelemetry をどのように使っているかについて話し合っています。 セッションは南北アメリカ（AMER）、ヨーロッパ・中東・アフリカ（EMEA）、アジア太平洋（APAC）のユーザーを対象に開催されています。 ディスカッションは Lean Coffee 形式で行われ、参加者はこのような Agile Coffee ボードにトピックを投稿し、出席者全員が話したいテーマに投票します。
OpenTelemetry コミュニティの他のユーザーと交流し、OpenTelemetry が実際にどのように使われているかについて実践的な経験を学び、共有するための素晴らしい機会です。 各ミーティングには OTel ガバナンス委員会メンバーやメンテナーが参加し、質問への回答、ユーザーからのフィードバックの聴取、議論されるトピックへの追加の文脈や洞察の提供を行っています。
これは、月例の OTel エンドユーザーディスカッションをまとめるブログ記事シリーズの第 1 回で、2023年1月のセッションから始まります。
話し合ったこと
今月は 3 つのセッションを通じて、いくつかの共通テーマが見られました。
- OpenTelemetry の導入と普及
- コネクター（Collector）
- Service Graph Processor（Collector）
- シグナルの相関（例: メトリクス/トレースの相関、ログ/トレースの相関）
これらのトピックについて詳しく見ていきましょう！
ディスカッションのハイライト
以下は今月のディスカッションのまとめです。
OpenTelemetry Collector
1 - OpenTelemetry Transformation Language（OTTL）
Q: エクスポーターは OTTL（OpenTelemetry データを変換するための言語）をサポートする予定はありますか？ ユースケース: データを変換する必要があるが、プロセッサーで行いたくない。
A: 関心の分離の観点から、OTTL がエクスポーターに追加される可能性は低いですが、コネクター（パイプラインを結合するためのエクスポーター/レシーバーのペアとして機能する新しい Collector コンポーネント）またはルーティングプロセッサーのユースケースになる可能性があります。 ルーティングプロセッサーは HTTP リクエストまたは属性からデータを読み取り、指定されたエクスポーターにルーティングします。
2 - Service Graph Processor
Q: OpenTelemetry を使ってサービスグラフを生成し、メトリクスを生成し、データを可視化ツールに送信するにはどうすればよいですか？
A: Service Graph Processor がサービスグラフを生成します。 このプロセッサーはまだアルファ版であり、依存関係マッピングに関する Service Graph の既知の問題がいくつかあります。 1 つのスパンには全体のコンテキストが含まれておらず、全体像を把握するには、スパンを集中管理されたサービスに送信する必要があります。
3 - パイプラインでのデータの分岐
Q: Collector を使って異なるデータセットを異なるバックエンドに送信したい場合、最適な方法は何ですか？
A: コネクター（パイプラインを結合するためのエクスポーター/レシーバーのペアとして機能する新しい Collector コンポーネント）を使うことで解決できます。 コネクターは近日リリース予定です。 詳細については、コネクターの PR をご覧ください。
もう 1 つの方法は、ルーティングプロセッサーを使うことです。 ルーティングプロセッサーは HTTP リクエストまたは属性からデータを読み取り、指定されたエクスポーターにルーティングします。 この方法は新しいネットワーク接続を作成するため、非効率になる可能性があります。
4 - テレメトリーデータの時刻ずれの管理
Q: サーバー間でクロックが同期していない場合、一部のデータポイントが将来の時刻として記録されることがあります。 これを軽減するために OTel Collector に何か実装できますか？
A: クロックスキューは常に発生するものです。 特にマイクロサービスアーキテクチャでは、クロックを同期させる方法はありません。 テレメトリーを生成するシステムのオーナーの方が、クロックの特性をよく理解しています。 Collector はこの問題に対処するのに適していません。
5 - 高度な Collector のデプロイと設定
Q: Pod を水平スケーリングするタイミングと、個々の Collector の設定を変更するタイミングはいつですか？ Collector を追加する場合と Collector の設定を変更する場合の判断基準は？
A: Collector のデプロイと設定にはいくつかの考慮点があります。
- Collector にステートレスなコンポーネントしかない場合、メトリクスに基づいてスケール（レプリカの追加）できます。
- 処理の種類に応じてパイプラインをシャーディングすることをお勧めします。 たとえば、メトリクス用、ログ用、トレース用のパイプラインをそれぞれ作成するのがよいでしょう。 これらのパイプラインのワークロードはそれぞれ異なるためです。
- 処理されるデータの種類に応じて Collector を分割することもできます。 個人を特定できる情報（PII）を含むデータが多い名前空間がある場合、その名前空間専用の Collector を設置し、属性プロセッサーを使用するとよいでしょう。
OpenTelemetry の導入と普及
Q: 組織で OpenTelemetry を採用することを決めたものの、次に何をすればよいでしょうか？ 開発者を圧倒することなく、OpenTelemetry の導入を促進し、開発者に OpenTelemetry の利用に対する意欲を持たせる最良の方法は何ですか？
A: コミュニティからの提案をいくつか紹介します。
- OpenTelemetry のチャンピオンになってくれる人を見つける
- OpenTelemetry に不慣れな開発者を、より詳しい開発者とペアにする
- OpenTelemetry の真の価値は、いくつかのサービスを計装して、それらがどのように連携しているかを確認するまで見えてこない
- 開発者はコードの計装を始める心構えができている必要がある。 既存のコードに計装を追加することを意味する場合もあることに留意する
- 「ビッグバン」アプローチは OpenTelemetry を導入する最良の方法ではない可能性がある。 組織にとって圧倒的になりかねないため、1 つか 2 つのコンポーネントから始めるとよい
OpenTelemetry 言語 API と SDK
1 - 新しい言語の計装
Q: Dart や Lua など、さまざまな言語の OTel 実装に関する情報はどのように見つけられますか？
A: CNCF Slack は検索を始めるのに最適な場所です。 言語ごとのチャンネルがあり、otel-<language_name> という命名規則に従っています。 お使いの言語のチャンネルが見つからない場合は、OpenTelemetry CNCF Slack チャンネルや GitHub でディスカッションを始めてください。 Perl 向け OTel のこのイシューのような例もあります。 詳細についてはこちらのページもご確認ください。
2 - Python の計装
Q: Python の自動計装はどの程度成熟していますか？ また、OpenTelemetry Python を使っている方々の経験はどのようなものですか？
A: Python の自動計装はベータ版ですが、本番環境で OTel Python を使用している企業があるため、本番環境で問題が発生する可能性は低いでしょう。 SIG として、OTel Python は破壊的変更の出荷を最小限に抑えるよう努めていますが、すべてのものと同様に、破壊的変更がないという保証はありません。 Python の計装が安定版としてマークされる確定した時期はありません。
その他の項目
1 - OpenTelemetry エグゼンプラー
Q: エグゼンプラーについて、また実際にどのように使われているかについて、どこで詳しく学べますか？
A: エグゼンプラーは、OpenTelemetry のメトリクスをトレースに相関させるために使用されます。 エグゼンプラーは現在開発の初期段階にあり、まだ多くの作業が必要です。 エグゼンプラーの状況について詳しくは、CNCF Slack の #otel-metrics チャンネルをご確認ください。 Michael Hausenblas の最近の講演もぜひご覧ください。
2 - トレースとログの相関
Q: トレースとログをより簡単に相関させる方法はありますか？
A: 相関の実装には時間がかかり、進行中の作業です。 相関の作業は一部の言語（例: Java、Go）では他よりも成熟しています。 最善のアプローチは、お使いの状況に該当する言語固有のリポジトリでこの問題を提起することです。 回避策として、ログレベルでトレースを開始する方法があり、すべてのログに関連するトレースが紐付けられます。
3 - プロファイリング
Q: OpenTelemetry におけるプロファイリングの状況はどうなっていますか？
A: プロファイリングに関する OTel の提案は承認され、活発に作業と議論が行われています。 現在は SDK の作業を開始する前に、プロトコルの策定に注力しています。 GitHub のプロファイリングリポジトリや、GitHub のプロファイリングビジョンのプルリクエストをご確認ください。
4 - コンテキスト伝搬
Q: ブラウザーはコンテキスト伝搬を自動的に追跡できないため、手動で行う必要があります。 現在の回避策には多くのオーバーヘッドが伴っています。 これはどのように対処できますか？
A: この問題に対処するには、JavaScript SIG に参加してそこで問題を提起することです。 これを内部的に解決する API に取り組んでいる方がいれば、OTel コミュニティにコントリビュートしていただけると素晴らしいです。
ミーティングノートと録画
上記のトピックをさらに詳しく知るには、以下をご確認ください。
今後はすべてのエンドユーザーディスカッションミーティングを録画する予定です。
参加しませんか
OpenTelemetry を組織でどのように活用しているかのストーリーを共有したい方は、ぜひお聞かせください！ 共有方法:
- CNCF Community Slack の #otel-endusers チャンネルに参加する
- 毎月開催のエンドユーザーディスカッショングループに参加する
- OTel in Practice セッションに参加する
- OpenTelemetry ブログでストーリーを共有する
OpenTelemetry を Mastodon や Twitter でフォローし、#OpenTelemetry ハッシュタグを使ってストーリーを共有してください！