OpenTelemetry Collector サーベイから得られたインサイト

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.

OpenTelemetry(OTel)Collector は、現代のソフトウェアアプリケーションの監視とオブザーバビリティにおける基盤ツールとなっています。 最近、End User SIG は OTel Collector に関するユーザーからのフィードバックを収集するためにサーベイを実施しました。 受け取った186件の回答が統計的に有意であるとは限りませんが、良いスタートであり、貴重なインサイトを提供してくれています。 これらのインサイトには、ユーザーのデプロイの実践や実装上の課題に関する詳細が含まれており、OTel Collector の今後の方向性を推進するうえで役立ちます。

主なポイント

  • 企業は一般的に、中規模から大規模な Collector のデプロイを行っています。
    • 5台超の Collector: 125/186
    • 10台超の Collector: 100/186
  • Collector のカスタムバイナリやディストリビューションのビルドは予想以上に普及しており(61/186)、そのほとんどが OTel Collector Builder を使用しています(49/61)。
  • 大多数が Kubernetes 上に Collector をデプロイしています(150/186)。
  • 新しいコンポーネント(14)よりも、安定性(59)、セルフオブザーバビリティ(53)、設定管理(59)に対する要望が高くなっています。

詳細なインサイト

デプロイ規模と環境

調査結果から、OTel Collector が大規模に利用されていることがわかりました。 回答者の53.8%(100/186)が10台超の Collector をデプロイしており、13.4%(25/186)が5台から10台、22%(41/186)が2台から5台を運用しています。

組織内で何台の OTel Collector を実行しているかを示すグラフ

Kubernetes が Collector のデプロイプラットフォームとして最も多く(80.6%)、次いで仮想マシン(33.3%)、ベアメタル(10.8%)が続きます。

OTel Collector のデプロイ先を示すグラフ

ユースケース

OTel Collector は主にゲートウェイとして使用されており(64.5%)、さまざまなソースからテレメトリーデータを集約する際の中心的な役割を果たしています。 DaemonSet(51.6%)やサイドカー(23.7%)も人気のあるデプロイモデルであり、OTel Collector がさまざまな運用環境で柔軟に活用されていることを示しています。

OTel Collector のユースケースを示すグラフ

カスタマイズと設定

予想以上に多くのユーザーが独自のディストリビューションをビルドしており(61/186)、コミュニティにとって構成可能な Collector の提供が重要であることを示しています。 独自の Collector ディストリビューションをビルドしているユーザーのほとんどが OTel Collector Builder(OCB) を使用しています(49/61)。 OCB を活用している49人の回答者のほとんどは使い方を理解できており、使いにくいと回答したのは2人だけでした。

OTel Collector Builder の使いやすさを示すグラフ

監視とオブザーバビリティ

Collector の監視については、回答者の大多数が Collector のメトリクスとログに依存しており(81.7%)、Collector をまったく監視していないユーザーはわずかでした(16.6%)。 データをさらに詳しく分析すると、5台超の Collector を運用している125人の回答者のうち、Collector を監視していないのは15人のみであり、10台超の Collector を運用している100人の回答者のうち監視していないのは9人のみでした。 このことから、Collector のデプロイが一定の成熟度に達すると、ユーザーは Collector の監視を真剣に行うようになることがうかがえます。

OTel Collector の監視方法を示すグラフ

OTel コンポーネントの利用状況

OTel Collector の柔軟性は、さまざまな環境で使用されているエクスポーター、レシーバー、プロセッサー、コネクター、エクステンションの豊富さによって明確に示されています。 これは、Collector が幅広いツールやシステムと統合できる能力を持っていることを示しています。

サーベイ結果によると、上位のコンポーネントは以下のとおりです。

エクスポーター

  1. otlpexporter
  2. prometheusremotewriteexporter
  3. prometheusexporter
  4. lokiexporter
  5. debugexporter

レシーバー

  1. otlpreceiver
  2. prometheusreceiver
  3. filelogreceiver
  4. hostmetricsreceiver
  5. k8sclusterreceiver

プロセッサー

  1. batchprocessor
  2. attributesprocessor
  3. filterprocessor
  4. memorylimiterprocessor
  5. k8sattributesprocessor

コネクター

  1. spanmetricsconnector
  2. servicegraphconnector
  3. routingconnector
  4. countconnector
  5. datadogconnector

エクステンション

  1. healthcheckextension
  2. basicauthextension
  3. pprofextension
  4. bearertokenauthextension
  5. oauth2clientauthextension

使用されている具体的なエクスポーター、レシーバー、プロセッサー、コネクター、エクステンションの詳細については、生データをご覧ください。 このデータは、コミュニティ内で人気のある選択肢と、OTel Collector のカスタマイズ性を示すニッチな設定の両方を明確に把握できます。

改善すべき領域

回答者は、新しいコンポーネント(8%未満)よりも、安定性(30.6%)、設定管理と解決(30.1%)、セルフオブザーバビリティ(28%)の改善を望んでいることを明確にしました。

OTel Collector の改善に関する関心領域を示すグラフ

OTel Collector サーベイの結果は、Collector のデプロイと活用の現状のスナップショットを提供します。 OTel Collector が広く採用されカスタマイズ性も高い一方で、よりユーザーフレンドリーで堅牢にする余地もあることがわかります。

今後の連絡先

サーベイにご参加いただいたすべての方に感謝します! 皆さまのフィードバックは、OpenTelemetry の今後の開発を導き、進化するニーズに引き続き応えられるようにするために欠かせません。

今後のサーベイは以下のチャネルで告知します。 #otel-sig-end-user Slack チャネル — こちらからお気軽にお問い合わせください! エンドユーザーリソースページ