ソフトウェアのオブザーバビリティの世界に長年携わってきた方でも、あまり馴染みのない方でも、インストゥルメンテーションのオープンスタンダードとして業界で広く認められている OpenTelemetry については耳にしたことがあるのではないでしょうか。いずれにしても、OpenTelemetry コレクターを理解することは OpenTelemetry をフル活用し、アプリケーションやシステムデータを最大限に活用するために必要なことです。
コレクターとはいったいどのようなものなのでしょうか。その正体は、テレメトリーを収集および修正し、それを New Relic を含む 1つ以上のバックエンドに送信する実行可能ファイルです。最新のクラウドネイティブ環境から得られたオブザーバビリティデータを処理することができ、高度な設定が可能で拡張性も備えています。テレメトリ処理の超能力の範囲を考えると、それについて学ぶことがたくさんあります。
本ブログでは、コレクターのアーキテクチャー、デプロイメント方法、構成、監視方法などの主要な基礎について説明します。この多目的なツールを使い始める際に参照ください。
アーキテクチャーと設定
コレクターはモジュール設計となっており、トレース、ログ、メトリクス用のカスタマイズ可能なデータパイプラインを備えています。この機能には少なくとも、アプリデータを受信するデータパイプラインコンポーネントと解析を行うバックエンドシステムに送信するコンポーネントが必要です。「必要最低限」なコレクターコンポーネントはこの 2つだけです。より多機能なコレクターを構築する場合は、データ拡張、フィルタリング、バッチ処理などを行うコンポーネントを追加することができます。
データにアクセスする パイプラインコンポーネントは 4つあります：
- レシーバー：アプリやシステムからデータを取り込む
- プロセッサ：何らかの方法でデータを修正する
- エクスポーター：指定されたバックエンドにデータを送信する
- コネクター：パイプライン間でデータを送信できるようにする
コレクターのヘルスチェックやサービスディスカバリーなど、データに直接アクセスしないタスクを処理する拡張コンポーネントもあります。
コレクターのアーキテクチャーおよびそのアーキテクチャーにおけるデータの流れを理解するため、サンプルのコレクター設定を見てみましょう。まず、使用するコンポーネントを設定します。以下の例では、各データパイプラインに少なくとも 1つのコンポーネントといくつかの拡張機能を設定しています。
receivers:
otlp:
protocols:
grpc:
http:
exporters:
otlp:
endpoint: https://otlp.nr-data.net:4317
headers:
api-key: YOUR_LICENSE_KEY
processors:
batch:
connectors:
spanmetrics:
extensions:
health_check:
pprof:
zpages:次にserviceセクションにコンポーネントを明示的に設定し、有効にする必要があります。この設定を行わないとコンポーネントは使用されません。以下のサンプル設定では、トレース、メトリクス、ログの各データタイプに対してデータパイプラインを設定しています（拡張コンポーネントはextensionsで有効になっていることにご注意ください）。
service:
extensions: [health_check, pprof, zpages]
pipelines:
traces:
receivers: [otlp]
processors: [batch]
exporters: [otlp, spanmetrics]
metrics:
receivers: [otlp, spanmetrics]
processors: [batch]
exporters: [otlp]
logs:
receivers: [otlp]
processors: [batch]
exporters: [otlp]それでは、traces パイプラインを使用して、データパイプラインがどのように機能するかを見ていきましょう。まず、otlp レシーバーがアプリからトレースデータを取り込みます。そのデータはプロセッサパイプラインに送られ、batchプロセッサで圧縮されてから、パイプラインの最後の部分であるエクスポーターに送られます。バッチ処理されたトレースは otlp エクスポーターによって New Relic アカウントに送信され、さらに spanmetrics コネクターによってメトリクスパイプラインに送信されます。
コレクターは、さまざまなソースから、さまざまなプロトコルで、異なる形式のデータを受信することができます。同様に、サポートされている形式でデータをエクスポートすることができます。New Relic は OpenTelemetry データをネイティブにサポートしているため、otlp エクスポーターを使用するだけでトレース、メトリクス、ログを New Relic アカウントに送信することができます。
複数のバックエンドにデータを送信したい場合は、複数の otlp エクスポーターを定義します。必要であれば、その他のエクスポーターを合わせて定義することも可能です。たとえば、デバッグが目的の場合は、debugexporter を使用してテレメトリーデータをコンソールに出力することができます。
プロセッサはオプションですが、OpenTelemetry コミュニティが利用を推奨するプロセッサがいくつかあります：
- memorylimiterprocessor：コレクターでのメモリ不足の発生を防ぎます
- batchprocessor：データを圧縮し、データ送信に必要となる通信量を減らします
このほか、指定された基準に基づいてトレースをサンプリングする tailsamplingprocessor や、法的要件、プライバシー要件、セキュリティ要件に準拠する redactionprocessor など、機能強化やデータ修正に使用することができるプロセッサが 30種類以上あります。
note: パイプライン内のプロセッサの順序には注意が必要です。たとえば、サンプリングされたトレースのみをバッチ処理したい場合には、サンプリングまたは初期フィルタリングを実行するプロセッサの後に batchprocessor を定義するなど、順番を意識する必要があります。
プロセッサの順番のベストプラクティスは以下の通りです：
- memorylimiterprocessor
- サンプリングおよび初期フィルタリングプロセッサ
- コンテキストからのソース送信に依存するプロセッサ
- batchprocessor
- その他のプロセッサ
複数のコンポーネントを設定しており、それらが有効化されていることを確認したい場合は、設定を検証する (Validate) ことができます。
検証方法には、otelcol validate --config=customconfig.yamlを実行する方法や OTelBin を使用する方法もあります。
次のスクリーンショットは前出の設定サンプルを検証した例です（同時に、パイプラインを流れるデータを簡単に可視化した図となっています）。
デプロイメントオプション
コンポーネント設定の次のトピックはデプロイメントです。コレクターは Docker、Kubernetes、Linux、macOS、Windows などのさまざまな OS やアーキテクチャーに導入することができます。最も単純なデプロイメントはコレクターが 1つだけのインスタンスですが、ビジネスニーズやテレメトリーの用途に合わせて多数の デプロイメントパターン があります。
一般的にコレクターは次のようなデプロイできます：
- ゲートウェイ：(複数の) サービスはデータを一元化されたコレクターに送信。その後、バックエンド（New Relic アカウントなど）に送信する
- エージェント：サービスと同じホスト上で実行され、そのホストに関するインフラストラクチャのテレメトリーを収集する。収集したデータをバックエンドに直接またはゲートウェイコレクターに送信する
ディストリビューション
コレクターには、core と contrib という2つの公式ディストリビューション (Distros) があります。core ディストリビューションは、データの収集、処理、送信に必要な基本コンポーネントのみを含む最小構成の安定版です。軽量かつ効率的な設計であり、標準的なユースケースや環境に適しています。
もう一方の contrib ディストリビューションは core ディストリビューションに数十個のコンポーネントを追加し拡張したもので、より広範な機能を提供します。より多くの機能とインテグレーションが含まれていますが、各コンポーネントの成熟度はさまざまであるため、本番環境で使用する予定の場合は注意が必要です。
両方の長所を享受したい場合、または別のものが必要な場合は、独自のコレクターディストリビューションを構築することもできます。カスタムのパイプラインコンポーネントやエクステンションをビルドしたい場合は、独自のコレクターインスタンスを準備することで、好みの Golang IDE でコンポーネントのリリースやデバッグができるようになります。これを行う場合、OpenTelemetry Collector Builder (ocb) を使用することになります。これはプロセスを単純化するためにコミュニティによって構築されたもので、カスタムコンポーネントをインクルードしたり、コアやcontribコンポーネントを使うことができます。
コレクターの監視
データの処理はコレクターに依存するため、必然的にコレクターのヘルスチェックやパフォーマンスを監視したいという要望が出てきます。これは、リソースの制約や潜在的なセキュリティ脆弱性といった問題の特定にも役立ちます。監視すべき主なメトリクスには次のようなものがあります。
- CPU使用率やメモリ使用量などのリソース使用に関するメトリクス
- 処理のレイテンシ、損失データ、バッチサイズ、処理速度などのパフォーマンスに関するメトリクス
- 稼働時間、可用性、エラー率などの運用に関するメトリクス
監視にはコレクター独自の内部テレメトリーを使用することができます。コレクターでテレメトリーを表示する方法は基本的に 2つです。その 1つがPrometheus インターフェースで表示される基本メトリクス (これらの内部メトリクスの生成やエクスポーズ方法は設定することが可能です) で、もう 1つが標準エラー出力に出力されるログ (これらも設定可能) です。内部テレメトリーによるコレクター監視のベストプラクティスの詳細については、こちらのドキュメントをご参照ください。
次のステップ
コレクターを実際に体験してみたい方は、OpenTelemetryデモアプリのNew Relicフォークから始めることをお勧めします。こちらには、さまざまなパイプラインコンポーネントをお試しいただけるように、簡単にカスタマイズできるデフォルトのコレクター設定が含まれています。フォークの詳細、およびHelmを使用してKubernetesにデプロイする方法については、「New RelicでOpenTelemetryコミュニティデモアプリを実行する」をご覧ください。
高度なサポート、またはコレクターのSpecial Interest Group（SIG）へのお問い合わせをご希望の場合は、CNCFのSlackインスタンスの#otel-collectorチャネルのご利用をお勧めします。また、毎週開催のSIGミーティング（太平洋標準時の水曜日9:00、5:00、17:00で交互に開催）にもご参加いただけます。New RelicプラットフォームのOpenTelemetryデータについてご不明な点がありましたら、#otel-newrelicからNew RelicのOpenTelemetryエンジニアにお問い合わせいただけます。
未解決の問題に取り組んでコレクターの開発に貢献したい方は、まずGitHubリポジトリの「good first issue」リストを熟読することをお勧めします。
コレクターの詳細については、以下のリソースをご覧ください。
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
