【ITニュース解説】Custom OpenTelemetry Collectors: Build, Run, and Manage at Scale

現代のソフトウェア開発において、システムが正常に動作しているか、何か問題が発生していないかを把握することは非常に重要です。この目的のために、システムから「テレメトリーデータ」、具体的にはメトリクス（性能指標）、ログ（イベント記録）、トレース（処理追跡）といった情報を収集し、分析します。OpenTelemetryは、このテレメトリーデータを標準的な方法で収集・送信するためのオープンソースプロジェクトである。

OpenTelemetry Collectorは、このテレメトリーデータを収集し、変換し、最終的な保存先（監視ツールやデータベースなど）へ転送する役割を担うエージェントである。これは、システムが出力する様々な形式のデータを統一し、効率的に処理するための中継点のようなものである。

通常、OpenTelemetry Collectorは非常に多くのコンポーネント（データの受信機、処理器、送信機、拡張機能）を搭載した「Contrub」版として提供される。開発者がシステム監視を始める際には非常に便利だが、実際の運用環境では、その全ての機能が必要となることは稀である。不要なコンポーネントが含まれることで、コレクタのバイナリファイルサイズが大きくなり、メモリ消費量が増加し、さらにセキュリティ上の攻撃対象領域が拡大するという問題が発生する可能性がある。

このような背景から、運用環境では、必要なコンポーネリーのみを含んだ「カスタムOpenTelemetry Collector」を構築するニーズが高まっている。カスタムコレクタを構築することで、バイナリサイズを最小限に抑え、リソース消費を削減し、セキュリティリスクを低減できる。特に、Kubernetesのようなコンテナ環境やエッジデバイスでは、軽量なコレクタが求められる。

しかし、従来のカスタムコレクタ構築は、主にGo言語での開発スキルを必要とした。これは、多くのシステムエンジニア、特にGo言語の経験が少ない初心者にとっては高いハードルであり、既存のドキュメントやツールもGo開発者向けに設計されていることが多かった。

この課題を解決するために登場したのが、Bindplaneが提供するオープンソースツール「OpenTelemetry Distribution Builder (ODB)」である。ODBは、Go言語のコードを書くことなく、カスタムコレクタを構築できるように設計されている。ODBは、どのようなコンポーネントをCollectorに含めるかを定義するmanifest.yamlという設定ファイルを受け取り、それに基づいて、様々なオペレーティングシステム（Linux, Windows, macOS）とアーキテクチャ（AMD64, ARM64）に対応したバイナリやパッケージ（.tar.gz, .zip, .deb, .rpm）を自動で生成する。これにより、手動での依存関係解決やGo言語でのコーディングは不要になる。また、OpAMP (OpenTelemetry Agent Management Protocol) のサポートが組み込まれており、後述のリモート管理を容易にする。

カスタムコレクタの構築プロセスは、GitHub Actionsと連携することでさらに自動化できる。まず、GitHubリポジトリを作成し、そこにmanifest.yamlファイルを配置する。このmanifest.yamlには、使用したいレシーバー、プロセッサー、エクスポーター、拡張機能、コネクターなどを、そのGoモジュールとバージョンで指定する。例えば、OpAMP拡張機能を含めることで、Bindplaneからのコレクタの発見と管理が可能になる。

次に、GitHub Actionsのワークフローファイル（multi.yamlなど）を作成し、OpenTelemetry Distribution Builder GitHub Actionを使用するように設定する。このワークフローは、リポジトリにタグがプッシュされたり、手動でトリガーされたりすると自動的に実行される。ワークフローでは、事前に定義された複数のプラットフォーム（Linux/amd64, Windows/amd64など）向けにカスタムコレクタのビルドが行われ、それぞれのプラットフォームに対応したパッケージが生成される。これらのパッケージは、GitHub Actionsの成果物として保存されるだけでなく、GitHubのリリースにも自動的に添付される。これにより、一度設定すれば、manifest.yamlを更新して新しいバージョンをリリースするだけで、自動的にカスタムコレクタがビルドされ、配布できるようになる。

ビルドされたカスタムコレクタは、GitHubのリリースページからダウンロードして実行できる。例えば、Linux環境であれば、tar.gzファイルをダウンロードして展開し、実行バイナリとともに出力されるcollector_config.yamlを編集して、コレクタを起動する。このcollector_config.yamlにOpAMPの設定を追加することで、Bindplaneとコレクタが接続され、Bindplaneの管理画面にコレクタが表示されるようになる。

さらに、Bindplaneの強力なリモート管理機能を活用するには、もう少し設定が必要になる。まず、Bindplane CLIをインストールし、APIキーを設定して、Bindplaneリソースにアクセスできるようにする。次に、Bindplaneに「Agent Type」を作成する。Agent Typeは、特定のOpenTelemetry Collectorのディストリビューションを表すもので、カスタムコレクタの場合、そのリポジトリURLやサポートするプラットフォーム・アーキテクチャなどを定義するYAMLファイルを作成し、Bindplane CLIを使って適用する。このAgent Typeのメタデータ名とmanifest.yamlのdist.name、そしてリリースバージョンを一致させることが重要である。

Agent Typeが作成され、バージョンが同期されると、BindplaneのUIから自身のカスタムコレクタをインストールできるようになる。Bindplaneは、カスタムコレクタの定義に基づいて、特定の環境にコレクタをデプロイするためのコマンドを生成する。このコマンドを実行すると、カスタムコレクタがシステムサービスとしてインストールされ、OpAMPを通じてBindplaneと完全に連携するようになる。

これにより、BindplaneのUIからカスタムコレクタの構成をリモートで作成、管理、適用できるようになる。Bindplaneは、カスタムコレクタがmanifest.yamlで含めたコンポーネント（レシーバー、エクスポーターなど）の能力を認識するため、設定作成時には、そのコレクタが実際にサポートするコンポーネントのみがUIに表示される。これは、設定ミスを防ぎ、管理の利便性を大幅に向上させる。

このようにして構築されたワークフローにより、manifest.yamlを更新し、新しいバージョンをリリースするだけで、カスタムコレクタが自動的にビルド、パッケージ化され、Bindplaneを通じてデプロイおよびアップグレードできるようになる。この「BYOC（Bring Your Own Collector）」ワークフローは、完全に自動化され、バージョン管理され、開発者が完全に制御できるものとなる。

このアプローチの利点は、OpAMPによるBindplaneとのシームレスな連携、Go言語の知識不要な宣言的なmanifest.yamlによる定義、GitHubネイティブのCI/CDによる自動化、マルチプラットフォーム対応、そしてBindplane UIがコレクタの能力を認識することで提供される優れたユーザーエクスペリエンスにある。

将来的には、既存のコレクタ設定ファイルから自動的にmanifest.yamlを生成する機能など、さらなる抽象化が期待されている。この技術は、もはや上級ユーザーだけのものではなく、ODBとGitHub Actions、そしてBindplaneを組み合わせることで、システムエンジニアの誰もが、Goコンパイラに触れることなく、必要な機能を備えたカスタムコレクタを構築し、大規模に管理できる、クリーンで高速かつ本番環境に対応したソリューションを提供している。