OpenTelemetry Collector Contribとは｜coreとの違いとocbで作る自作distro

OpenTelemetry Collectorを入れる段になって最初に迷うのが、配布物としてotelcolとotelcol-contribのどちらを取るかという選択です。2026年8月時点の最新版はv0.158.0（2026-08-04公開）で、両者は同じ版番号で同時にリリースされますが、収録されるコンポーネントの数は27本と242本まで開きます。この記事では公式マニフェストの実測値をもとにした収録範囲の違い、receiverやprocessorに付く安定度ステータスの読み方と採用可否の線引き、ocb（OpenTelemetry Collector Builder）で必要な部品だけを束ねた自作distroの作り方、そしてイメージ肥大とCVE追随がcontribを運用負担に変える境目を扱います。Collectorそのものの役割やOTLPの仕組みは対象外です。

まとめ：contribで始めてocbへ移す判断とその分岐点

結論から書きます。まずotelcol-contribで始めてください。coreディストリは「軽くて安全な選択肢」に見えますが、そこに収録されている27本のうち17本はcontribリポジトリ由来のコンポーネントです。coreを選んでもcontribリポジトリのコードからは逃げられません。

そのうえで、パイプライン構成が固まって半年ほど変更が入らなくなったら、ocbで自作distroへ移す検討に入ります。判断の分岐点はイメージサイズではなく、脆弱性スキャンの棚卸しコストです。使っていない200本超のコンポーネントに紐づく依存関係まで検出対象に入るため、スキャン結果の仕分けが月次の固定作業として積み上がります。

逆に、自作distroへ移すと2週間ごとのアップストリーム更新に自前で追随する義務が発生します。ビルドを回す担当が固定できない体制では、contribのまま運用したほうが総コストは低く収まります。

otelcol-contribとcoreディストリの収録範囲と実体の差

contribは「拡張版のCollector」ではなく、コミュニティが持ち込んだコンポーネントを収める別リポジトリの名前です。そこからビルドされる配布物がotelcol-contribになります。Collector本体の役割やシグナルの区分についてはOpenTelemetry（OTel）の3つのシグナルとOTLP・Collectorの位置づけを先に押さえておくと、以下の収録数の話が構成の判断に結びつきます。

v0.158.0のマニフェスト実測で比べる両ディストリの収録数

公式のリリースリポジトリには、ディストリごとに収録コンポーネントを列挙したmanifest.yamlが置かれています。v0.158.0のタグで実測すると、otelcolはreceiver 7本・processor 7本・exporter 9本・extension 3本・connector 1本の計27本。otelcol-contribはreceiver 108本・processor 32本・exporter 49本・extension 40本・connector 13本の計242本でした。差はおよそ9倍です。

設定ファイルの書式は両者で同じです。ディストリを入れ替えてもパイプラインの定義を書き直す必要はなく、使えるコンポーネントの集合だけが変わります。移行時に壊れるのは「contribにしか無い部品を参照している行」だけなので、切り替え検証はその1点に絞れます。

coreディストリの部品の約6割がcontribリポジトリ由来

ここが誤解されやすい部分です。coreディストリのマニフェストを開くと、27本のうち17本のgomodがcontribリポジトリを指しています。receiverではhostmetrics・jaeger・kafka・prometheus・zipkinの5本、processorではattributes・resource・span・probabilistic_sampler・filterの5本、exporterではfile・kafka・prometheus・prometheusremotewrite・zipkinの5本、extensionではhealth_check・pprofの2本です。純粋にコアリポジトリだけで構成されているのは、OTLPの入出力とbatch・memory_limiterなど10本にすぎません。

つまり「コミュニティ製コードを避けたいからcore」という選び方は成立しません。core相当の最小構成を本気で狙うなら、後述のocbで自分の依存だけを列挙する以外に手はないという結論になります。

otelcol-k8sとotelcol-otlpを含む公式5種の守備範囲

公式が配布するディストリは5種類あります。otelcol、otelcol-contrib、Kubernetes向けのotelcol-k8s、OTLPの転送に特化したotelcol-otlp、そしてeBPFプロファイリング用のビルドです。otelcol-k8sはreceiver 15本・processor 22本・extension 16本という構成で、k8sattributesやkubeletstatsといったクラスタ運用の定番だけを拾っています。otelcol-otlpに至ってはreceiver 1本・exporter 2本で、OTLPを受けてOTLPで出すだけの中継用です。

Kubernetes上に置く前提なら、contribを入れる前にotelcol-k8sが要件を満たすか確認する価値がある選択です。配置の型そのものについてはOperator導入とCollectorの二層設計で整理した構成が判断材料になります。ベンダー製のディストリ（AWS ADOT、Datadog DDOT、Splunk、New Relic NRDOTなど13種）も公式ページに列挙されていますが、OpenTelemetryプロジェクトは第三者ディストリの検証も推奨も行わないと明記しています。

receiverとprocessorの安定度ステータスの読み方と採用可否

contribに242本あっても、そのすべてが本番で使える成熟度にあるわけではありません。各コンポーネントのREADMEには安定度ステータスがシグナル別に表示されます。同じreceiverでもtracesはbeta、metricsはalphaという書かれ方をするため、「そのコンポーネントを使うか」ではなく「そのコンポーネントのそのシグナルを使うか」で読む必要があります。

開発中からstableまでの6段階が示す本番投入の可否の線引き

定義されている段階は6つです。Development、Alpha、Beta、Stable、Deprecated、Unmaintained。実務上の線引きはBetaに引きます。Betaは設定オプションが安定したとみなされる段階で、破壊的変更が起きにくいことが前提になっているためです。

Alphaは「設定が最小限の予告で変わりうる」段階です。オーナーは破壊的変更の1〜2マイナーバージョン前に告知するとされていますが、リリース間隔が2週間なので、告知から実際の変更まで1か月しか猶予がない計算になります。

unmaintained判定から3か月で公式ディストリを外れる条件

見落とされがちなのがUnmaintainedです。コードオーナーが割り当てられていない、あるいは割り当てられていても6週間応答がない場合、コンポーネントはこの状態に落とされます。そして3か月が経過すると、引き取り手が現れない限り公式ディストリから削除されます。

削除は設定ファイルの起動失敗という形で表面化します。バージョンを上げた瞬間にCollectorが立ち上がらなくなる事故は、たいていこの経路です。採用時にコードオーナーが誰か（ベンダー所属の個人1名なのか、複数組織なのか）まで見ておくと、この種の突然死を事前に避けられます。

安定度alphaの部品を本番の業務要件へ採用してよい判断の条件

alphaでも採用してよい場面はあります。判断条件は2つです。第一に、そのコンポーネントが落ちてもアプリケーション本体の可用性に波及しない位置にあること。第二に、代替経路が用意できること。

たとえばtailsamplingprocessorのようにテールベースのサンプリング判断を担う部品は、収集の一部を落としても業務は止まりません。サンプリングの設計そのものはヘッドベースとテールベースの選び分けとサンプリング率の決め方で扱った通りで、安定度より先に方式選択が効きます。逆に、filelogreceiverで監査ログを収集して保管要件に充てるような、記録の欠落が業務上の不備になる経路には持ち込まない、というのがここでの結論です。ログ収集経路の設計判断は直接送信とfilelog receiverの選び分けを参照してください。

ocbで必要なコンポーネントだけを束ねた自作distroの作り方

ocbは、列挙したコンポーネントだけを組み込んだCollectorのバイナリを生成するツールです。「contribは大きすぎるがcoreでは足りない」という多数派の状況に対する公式の回答がこれにあたります。

builder-config.yamlに書く区分とバージョンの揃え方

設定ファイルはdistセクションと、コンポーネント種別ごとのgomod列挙で構成されます。distにはバイナリ名・説明・出力先ディレクトリを書き、その下にreceivers、processors、exporters、extensions、connectors、providersを並べる構成です。providersは設定値の読み込み元（環境変数、ファイル、HTTP、YAML文字列）を担うモジュールで、これを書き忘れると設定ファイルすら読めないバイナリができあがります。

バージョンの扱いには癖があります。コンポーネント側のモジュールはv0.158.0のようなゼロメジャー版で進みますが、providerなど安定版に到達したモジュールはv1.64.0という別系列の番号を持ちます。公式のディストリマニフェストをそのまま雛形にして、必要な行だけ削るやり方が確実です。ゼロから書き起こすと版の組み合わせでビルドが通らなくなります。

Dockerイメージ版ocbで再現性のあるビルドを回す実行手順

導入方法は3つ提示されており、公式リリースのDockerイメージと公式リリースバイナリが推奨、go installは非推奨です。CIで回すならDockerイメージ版が扱いやすくなります。

1. ビルド定義をbuilder-config.yamlとして用意し、出力先をdistセクションに書く
2. コンテナ内の既定位置である build 配下へ設定ファイルをマウントする
3. 出力先ディレクトリもホスト側からマウントする（コマンドライン引数では指定できない）
4. ocb --config=builder-config.yaml の形で必ず設定ファイルを明示する
5. 生成されたバイナリを自前のベースイメージへ載せてコンテナ化する

4つ目を飛ばすと既定の設定が使われ、意図と違うバイナリが出てきます。イメージ版ocbでは--configがエントリポイントではなく追加の引数として扱われる仕様のためです。なお既定のldflagsは-s -wでデバッグシンボルが除去されます。Delveで追いたい場合は--ldflagsを空で上書きします。

自作distroへ移行した後に増えるバージョン追随の年間作業量

ここを見積もらずに移ると失敗します。アップストリームのリリースは2週間おき、年間でおよそ26回です。自作distroでは、そのたびにマニフェスト内の全gomod行の版を揃えてビルドし直し、動作確認してレジストリへ入れる工程が発生します。contribの公式イメージを使っていれば、タグを差し替えるだけで済んでいた作業です。

毎回追随する必要はなく、四半期ごとにまとめて上げる形でも成立する運用です。ただしその場合は3か月分の変更履歴を一度に読むことになり、破壊的変更の検出が難しくなります。ビルドと検証を担う人が固定されていない組織では、この工程が最初に形骸化する傾向です。システム保守運用・内製化支援のように、追随の手順化と当番の設計まで含めて外部と組む形も選択肢になります。

イメージ肥大とCVE追随でcontribが運用負担に変わる境目

contribを避ける理由として真っ先に挙がるのがイメージサイズですが、実務で効いてくるのは別のところです。ここでは判断を言い切ります。

配布イメージ108MBと36MBの差が効く配置と効かない配置の判別

2026年8月時点のDocker Hubが返すv0.158.0のlinux/amd64イメージは、otelcol-contribが約108MB、otelcolが約36MB、otelcol-k8sが約48MBです（いずれも圧縮後）。差は約72MB、倍率にして3倍です。

この差が効くのは、ノード数が多くDaemonSetで各ノードに配る構成と、起動時間が課金に直結するサーバーレス実行環境、それから帯域が細い拠点への配布です。100ノードのクラスタなら初回pullで7GB前後の転送差になります。一方、数台のゲートウェイCollectorを常駐させるだけの構成では、72MBの差はディスクにもpull時間にも実質的な影響を与えません。台数が2桁に届かないなら、サイズを理由にcontribを外す判断は根拠が薄いと考えてください。

使わないコンポーネントの脆弱性報告まで追いかける運用負荷の実態

本当の負担はこちらです。242本のコンポーネントは、それぞれが独自の依存ライブラリを引き込みます。各社のクラウドSDK、データベースドライバ、メッセージング用クライアントが一式入るため、イメージスキャナは使っていない部品に紐づくCVEまで検出します。

• スキャナが出す指摘のうち、実際にパイプラインで参照している部品に由来するものを毎回仕分ける
• 参照していない部品由来の指摘に「未使用のため影響なし」の判断根拠を残す
• セキュリティ部門や監査への説明資料を、指摘が出るたびに更新する

この3つは自動化しにくく、人の判断が毎回必要な作業です。脆弱性ゼロを掲げる社内基準がある組織では、ここが恒常的な摩擦になります。自作distroへ移す実質的な動機は、イメージを小さくすることではなく、この仕分け作業を構造的に消すことにあります。

contribのまま運用を続けてよい規模と自作distroへ移す条件

判断を条件付きで示します。contribのままでよいのは、Collectorの稼働台数が10台未満、脆弱性スキャンの結果に対して「未使用コンポーネント由来」で押し通せる社内合意がある、かつパイプライン構成をまだ触っている段階の3つが揃う場合です。この状態でocbを持ち出すのは過剰投資になります。構成が変わるたびにビルド定義とバイナリを作り直す手間が、得られる効果を上回るためです。

自作distroへ移すべきなのは、次のいずれかに当てはまるときです。第一に、脆弱性スキャンの結果に例外を作れない規約下で運用している場合。第二に、DaemonSetで数十ノード以上に配っており、pull時間とノードのディスク消費が測定可能なコストになっている場合。第三に、ベンダー固有のexporterを1〜2本しか使っておらず、残る240本を抱える理由が説明できない場合です。

逆に見送るべき場面もはっきりしています。Collectorを導入して3か月以内、あるいは監視対象のサービスが今も増え続けている段階では、自作distroに移さないでください。必要な部品が後から判明するたびにビルドし直す羽目になり、その待ち時間が計装作業そのものを止めます。まずcontribで必要な部品を確定させ、構成が動かなくなってから固める順序を守ってください。

よくある質問

contribディストリの選定とビルドについて、実装の現場で質問が集中する5点をまとめます。

coreとcontribで設定ファイルの書き方は変わりますか？

変わりません。設定の書式は両ディストリで同一で、違うのは使えるコンポーネントの集合だけです。そのため、contribからcoreへ寄せる検証は「contribにしか無い部品を参照している行があるか」の確認に絞れます。ただしcoreディストリの収録は27本しかないため、filelogreceiverやk8sattributesprocessor、OTTLを使うtransformprocessorといった実務で頻出する部品は入っていません。多くの構成はcoreへ移した時点で起動に失敗します。

安定度がalphaのコンポーネントは本番で使えませんか？

条件付きで使えます。公式の定義でもalphaは「非クリティカルなワークロードでの限定的な利用」を想定した段階とされています。判断基準は、その部品が停止してもアプリケーション本体の可用性に影響しないこと、そして記録の欠落が業務上の不備にならないことの2点です。監査ログの保管や課金計算の根拠になるデータの経路には持ち込まない、という線引きで運用してください。

otelcol-contribのイメージはどれくらいの大きさですか？

2026年8月時点でDocker Hubが返すv0.158.0のlinux/amd64イメージは、圧縮後で約108MBです。同じ版のotelcolが約36MB、otelcol-k8sが約48MBなので、contribはcoreのおよそ3倍にあたります。ノード単位で配るDaemonSet構成では効いてきますが、ゲートウェイ用に数台常駐させるだけの構成では判断材料になりません。

ocbで自作したdistroは公式のサポート対象になりますか？

公式ディストリと同じ扱いにはなりません。ocbはビルドを生成するツールで、生成物の動作保証はビルドした側が負います。各コンポーネント自体はアップストリームのコードなのでissueは受け付けられますが、組み合わせに起因する不具合は自分で切り分ける前提です。運用としては、公式ディストリのマニフェストを雛形に使い、削る方向でだけ差分を作ると切り分けが容易になります。

contribに入っている部品が突然なくなることはありますか？

あります。コードオーナーが不在、または6週間応答がない場合、コンポーネントはunmaintained扱いになり、3か月が経過すると引き取り手が現れない限り公式ディストリから削除されます。deprecated指定の場合も、削除まで最低2マイナーリリースの猶予しか設けられていません。バージョンを上げた瞬間にCollectorが起動しなくなる事故はこの経路で起きるので、採用時にコードオーナーの構成まで確認しておくと防げます。

関連記事

• OpenTelemetry（OTel）とは：3つのシグナル・OTLP・Collectorという、この記事の前提になる規格側の解説です。
• OpenTelemetryのKubernetes構成：Operator導入とCollectorの二層設計を扱っており、otelcol-k8sを選ぶ場合の配置判断につながります。
• OpenTelemetryのログ実装：contrib固有のfilelog receiverを使うか直接送信にするかの選び分けを実装粒度で整理しています。
• トレースサンプリングとは：tail samplingを採用する前提となる方式選択とサンプリング率の決め方を扱います。
• OpenTelemetryのメトリクス実装：計器の選定とカーディナリティ設計という、processorの構成を決める前段の判断材料です。