OpenTelemetryとは？仕組み・Collectorの導入手順とPrometheusとの違い【2026年10月】

OpenTelemetry（オープンテレメトリ、略称OTel）とは、トレース・メトリクス・ログといったテレメトリデータを、特定の監視製品に縛られない共通の方法で計装・収集・転送するためのオープンソースの仕様と実装の集まりです。CNCF（Cloud Native Computing Foundation）のプロジェクトで、データを保存・可視化するバックエンドそのものではありません。この記事では、シグナルと言語ごとの成熟度、OTLPのポート、Collectorの構成を整理し、LinuxへのCollector v0.164.0の導入手順と、Prometheus 3系へOTLPで書き込んだ実測結果（macOS上のotelcol-contrib 0.164.0とPrometheus 3.15.1）を示します。Linux上でのパッケージ導入とjournaldの収集は実機で動かしておらず、公式の手順とREADMEに基づきます（2026年10月28日時点）。

まとめ｜OpenTelemetryの要点と導入の順序

• OpenTelemetryとは：計装と転送の標準。保存・ダッシュボード・アラートは持たず、PrometheusやJaeger、監視SaaSに任せる。
• シグナル：トレース・メトリクス・ログはAPIとOTLPが安定版。ただし言語SDKのログはPythonとJavaScriptが開発段階（Development）、GoがRC。プロファイルはアルファ。
• OTLP：gRPCは4317番、HTTPは4318番が既定。Collectorの受信口は既定でlocalhostにしか開かない。
• Collector：receiver→processor→exporterの3段で、送信先は設定だけで差し替えられる。最新はv0.164.0（2026年10月26日公開）で、型名はotlp_httpのようなスネークケースへ移行中。
• Prometheusとの違い：Prometheusはメトリクスを保存・照会する監視システム、OTelは計装と転送の標準。Prometheus 3系はOTLPを受けられるので組み合わせて使う。

導入は、1台のLinuxホストでCollectorを動かしてホストのメトリクスを送る、次にアプリへ自動計装を入れてトレースを足す、最後に送信先をCollectorの設定で一本化する、の順をすすめます。アプリに手を入れる前にインフラ側から始められます。

OpenTelemetryとは：計装と転送を標準化するCNCFプロジェクト

OpenTracing・OpenCensusの統合とCNCF卒業の経緯

OpenTelemetryは、分散トレーシングのAPIを定めていたOpenTracingと、Google発の計装ライブラリOpenCensusが2019年に統合して生まれました。既存のOpenTracing計装をshimで載せ替える手順はOpenTracingとOpenTelemetryの違いとshim移行の手順で扱っています。

CNCFのプロジェクトページによると、2026年5月11日に最上位の成熟度であるGraduatedへ移行し、KubernetesやPrometheusと同じ段階になりました。読み方は「オープンテレメトリ」、略称のOTelは「オーテル」と読むのが一般的です。

保存・可視化・アラートを持たない設計とバックエンドの役割

公式の「What is OpenTelemetry?」は、OpenTelemetryを「observability backend」ではないと明記し、保存と可視化は他のツールに任せる立場を取っています。OTelを入れただけではダッシュボードもアラートも手に入らないため、計装と転送の層（OTel）と、保存・分析する層（Prometheus、Grafana Tempo、Datadogなど）を別々に選びます。この分業により、OTelによるアプリの計装を維持したまま送信先を変更しやすくなります。ただし、認証・属性変換・ダッシュボード・アラートは移行先に合わせた調整が必要です。監視とオブザーバビリティの言葉の違いから整理したい場合はオブザーバビリティ（可観測性）とは？監視・APM・テレメトリとの違いと使い分けが入口になります。

3つのシグナルと言語SDKごとの成熟度

トレース・メトリクス・ログの役割と相関

テレメトリデータとは、システムの状態や挙動を外から観測するために出力されるデータの総称です。OpenTelemetryは次の3つを主要なシグナルとして扱います。

OTelではログにtrace_id・span_idを付け、メトリクスにはexemplarを記録することでトレースと関連付けられます。対応したバックエンドで設定しておけば、メトリクスの異常から該当時間帯のトレースへ、遅いスパンからそのリクエストのログへと移れます。

言語SDKの安定度：PythonとJavaScriptのログはDevelopment

仕様のステータスでは3シグナルともAPI（ログはBridge API）とOTLPが安定版です（メトリクスのSDK仕様だけは一部が未確定のmixed）。ただし各言語のSDKの成熟度は別に管理されています。公式のStatusページの言語別の表を、主要言語について抜き出すと次のとおりです。

「主要言語で3シグナルがGA」という説明は、PythonやNode.jsには当てはまりません。この2言語でログをSDKから送ると設定や出力形式が今後変わりうるため、安定を優先するならログはファイルに書き、Collectorのfile_log receiverで読む構成が無難です。選び分けはOpenTelemetryのログ実装｜直接送信とfilelog receiverの選び分け、メトリクスの計器の選び方はOpenTelemetryのメトリクス実装｜計器選定とカーディナリティ設計で扱っています。

第4のシグナル・プロファイルとeBPFプロファイラの導入条件

関数単位でCPUやメモリの消費箇所を記録するプロファイルは、4つ目のシグナルとして開発が進んでおり、公式の概念ページでの状態はAlphaです。LinuxではOpenTelemetry eBPF Profilerがアプリに手を入れずにホスト全体のスタックを採取し、READMEは、開発側のテストでのオーバーヘッド上限をCPU 1%・メモリ250MBと記載しています。あらゆる環境での上限を保証する数値ではありません。

カーネル要件は段階的に上がっており、READMEには「5.4を最後にサポートしたコミット以降は5.10以上が必要な場合がある」と書かれています。本番ではCollectorにreceiverとして組み込んだ専用ディストリビューション（otelcol-ebpf-profiler）が推奨で、リポジトリから単体でビルドしたバイナリは本番用途の対象外です。仕組みの前提となるeBPFはeBPFとは？Linuxカーネルを拡張する仕組みと可観測性・ネットワークでできることで解説しています。

OTLPの通信方式とgRPC 4317・HTTP 4318の使い分け

OTLP（OpenTelemetry Protocol）は、3シグナルを共通のスキーマで運ぶOTelの標準プロトコルです。OTLPの仕様は、gRPCの既定ポートを4317、HTTPの既定ポートを4318と定めています。Collector同士をつなぐならgRPC、プロキシ経由やブラウザからの送信ならHTTPが目安です。HTTPの場合、シグナルごとのパスは/v1/traces・/v1/metrics・/v1/logsです。

見落としやすいのが受信側の待ち受けアドレスです。CollectorのOTLP receiverのREADMEでは、endpointの既定値はlocalhost:4317とlocalhost:4318です。同じホストからの送信は届きますが、別ホストや別コンテナからは届きません。外から受けるときだけ0.0.0.0:4317を明示し、ファイアウォールで送信元を絞ってTLSと認証を設定します。

アプリを計装する方法：自動計装と手動計装

テレメトリを生み出す工程を計装（instrumentation）と呼び、OTelは2つの方法を用意しています。

• 自動計装（ゼロコード計装）：Javaエージェントやopentelemetry-instrumentコマンドなどを足すだけで、HTTP・DB・gRPCなど主要ライブラリのトレースとメトリクスが出る。コードの変更は最小限で済む。
• 手動計装：SDKのAPIで、業務処理に固有のスパンや属性（注文ID、テナントなど）を足す。自動計装で取れない粒度を補う。

自動計装でサービス間の流れを可視化し、中身が見えない処理にだけ手動のスパンを足すのが効率的です。属性名はOpenTelemetryのセマンティック規約に合わせておくと、バックエンドを替えてもダッシュボードやクエリを作り直す量が減ります。

OpenTelemetry Collectorの構成と最小構成のYAML

receiver・processor・exporterの役割と設定例

OpenTelemetry Collectorは、テレメトリを受信（receiver）→加工（processor）→送信（exporter）する中継プログラムです。Collectorを挟むと、送信先の切り替え・間引き・バッチ化・再送をアプリの外で一元管理できます。各ホストに置くエージェントと、集約して送るゲートウェイの2つの置き方があります。

同じホストのアプリからOTLPで3シグナルを受け、メモリ上限を守りながらまとめて送る最小構成は次のとおりです。otelcol-contrib 0.164.0のvalidateコマンドで構文と部品名が通ることを確かめています。別ホストから受ける場合は、gRPCのendpointを0.0.0.0:4317、HTTPを0.0.0.0:4318に変え、TLSと認証を加えます。

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: localhost:4317
      http:
        endpoint: localhost:4318
processors:
  memory_limiter:
    check_interval: 1s
    limit_percentage: 80
    spike_limit_percentage: 25
  batch:
exporters:
  otlp_http:
    endpoint: https://your-backend.example.com
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp_http]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp_http]
    logs:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp_http]

memory_limiterは先頭に置き、メモリ使用量がしきい値を超えたときに受信を抑制して、メモリ不足による停止リスクを下げます。ただし、チェック間隔内の急増などによる上限超過は防ぎ切れないため、Collectorへのメモリ割り当てとキュー容量も調整します。Collectorにはcore版（otelcol）と部品を多く収録したcontrib版（otelcol-contrib）があり、収録範囲の違いはOpenTelemetry Collector Contribとは｜coreとの違いとocbで作る自作distroで整理しています。

型名のスネークケース移行と旧名で起動したときの警告

2026年に入り、部品の型名はスネークケースへ順に改名されています。coreのCHANGELOGとcontribのCHANGELOGによると、主な改名は次の版で入りました。

otlphttp・filelog・hostmetricsは非推奨の別名として残っています。ただし、表中のqueuebatchからqueue_batchへの改名は破壊的変更として告知されており、旧名の互換性を一律には扱えません。0.164.0で旧名の設定を起動すると、ログに"otlphttp" alias is deprecated; use "otlp_http" insteadと"hostmetrics" alias is deprecated; use "host_metrics" insteadの警告が出ました。resourcedetectionも同じ警告でresource_detectionを案内されます。別名はいずれ削除される前提で、版を上げるたびに起動ログのwarnを確認します。

LinuxサーバーにCollectorを入れてsystemdで常駐させる手順

debとrpmでotelcol-contribを入れるコマンド（v0.164.0）

公式のLinuxインストール手順のとおり、Collectorの各リリースにはamd64・arm64などのDEB・RPMパッケージが含まれ、systemdのある環境ではサービスとして登録されます。Releasesページでの最新は2026年10月26日公開のv0.164.0です。版番号は変数にしておき、journaldのログも集めるならcontrib版を選びます。

# Debian・Ubuntu系（amd64）
OTELCOL_VERSION=0.164.0
BASE=https://github.com/open-telemetry/opentelemetry-collector-releases/releases/download/v${OTELCOL_VERSION}
wget ${BASE}/otelcol-contrib_${OTELCOL_VERSION}_linux_amd64.deb
wget ${BASE}/otelcol-contrib_${OTELCOL_VERSION}_linux_amd64.deb.sha256
sha256sum -c otelcol-contrib_${OTELCOL_VERSION}_linux_amd64.deb.sha256 && sudo dpkg -i otelcol-contrib_${OTELCOL_VERSION}_linux_amd64.deb

# RHEL・Amazon Linux系（amd64）
OTELCOL_VERSION=0.164.0
BASE=https://github.com/open-telemetry/opentelemetry-collector-releases/releases/download/v${OTELCOL_VERSION}
wget ${BASE}/otelcol-contrib_${OTELCOL_VERSION}_linux_amd64.rpm
wget ${BASE}/otelcol-contrib_${OTELCOL_VERSION}_linux_amd64.rpm.sha256
sha256sum -c otelcol-contrib_${OTELCOL_VERSION}_linux_amd64.rpm.sha256 && sudo rpm -ivh otelcol-contrib_${OTELCOL_VERSION}_linux_amd64.rpm

systemctl status otelcol-contrib

添付の.sha256で照合し、一致したときだけ入れます。arm64ではファイル名のamd64をarm64に置き換えます。systemdを持たない環境では、同じReleasesページのtar.gzを展開してバイナリを直接起動します。

設定ファイルの置き場所と専用ユーザーの読み取り権限

パッケージが入れるsystemdユニットは、環境ファイル/etc/otelcol-contrib/otelcol-contrib.confのOTELCOL_OPTIONSで--config=/etc/otelcol-contrib/config.yamlを渡し、rootではなく専用ユーザーotelcol-contribで動きます。Restart=on-failureも指定済みです。core版ではディレクトリ名が/etc/otelcol/になります。

専用ユーザーで動く点が、ログ収集で最初につまずく箇所です。journald receiverのREADMEはCollectorのユーザーがjournalctlでジャーナルを読めることを条件にしており、多くの環境ではsudo usermod -aG systemd-journal otelcol-contribでsystemd-journalグループへ加えます。/var/log配下のファイルも同様に読み取り権限が要ります。ユニットファイルの書式はsystemdとは？読み方・SysVinitとの違いとsystemctl・ユニットファイルの基本で確認できます。

host_metricsとjournaldでCPU・メモリ・systemdログを集める設定

ホストの数値はHost Metrics receiver（メトリクスはbeta）で集め、cpu・memory・load・filesystem・networkなどのスクレイパーを選んで有効にします。ログはJournald receiver（alpha）で読み、ホストにjournalctlコマンドがあることが前提です。

# /etc/otelcol-contrib/config.yaml
receivers:
  host_metrics:
    collection_interval: 30s
    scrapers:
      cpu:
      memory:
      load:
      filesystem:
      network:
  journald:
    units: [sshd, nginx]
    priority: info
    convert_to_semantic_conventions: true
processors:
  batch:
exporters:
  debug:
    verbosity: basic
  otlp_http:
    endpoint: https://your-backend.example.com
service:
  pipelines:
    metrics:
      receivers: [host_metrics]
      processors: [batch]
      exporters: [debug, otlp_http]
    logs:
      receivers: [journald]
      processors: [batch]
      exporters: [debug, otlp_http]

unitsで対象のユニットを絞ると送信量を抑えられます。例のsshd・nginxは実環境のユニット名に置き換え、journalctl -u 対象ユニットで収集対象のログが出ることを確認します。convert_to_semantic_conventionsはv0.162.0で追加された設定で、有効にするとMESSAGEがログ本文に、PRIORITYが重大度に入り、ほかのログと同じ形で検索できます。古い版のまま貼ると未知のキーとして起動に失敗するため、版を確かめてから使います。journaldに出ないアプリのログファイルは、file_log receiverで末尾を追いかけて読みます。

journalctlとdebugエクスポーターによる受信確認

設定を書き換えたら、構文を検証してから再起動し、Collector自身のログを追います。

sudo -u otelcol-contrib /usr/bin/otelcol-contrib validate --config=/etc/otelcol-contrib/config.yaml
sudo systemctl restart otelcol-contrib
sudo journalctl -u otelcol-contrib -f

debugエクスポーターは受け取ったデータの件数をログへ書き出すため、送信先の手前で「データが入ってきているか」を切り分けられます。流れを確認できたらdebugをパイプラインから外します。Collectorをコンテナで動かしてホストの数値を取る場合は、ホストのルートを-v /:/hostfsでマウントし、root_path: /hostfsを設定するようREADMEに書かれています。

アプリの自動計装をホスト単位で入れる公式システムパッケージ

2026年7月、OpenTelemetryのPackaging SIGがLinux向けのシステムパッケージを公開しました。opentelemetryというメタパッケージをaptまたはdnfで入れると、OpenTelemetry Injectorが動的リンカの設定を通じて、以後に起動したJava・.NET・Node.js・Pythonのプロセスへ自動計装を読み込ませます。送信先の既定はlocalhostの4317・4318番です。前節のホスト収集設定にはOTLP receiverがないため、自動計装の受け口にするには、最小構成例のOTLP receiverと、受信するシグナルのパイプラインを追加します。

ただし公式は「本番ワークロード向けではない」と明記しています。リポジトリは仮置きで、パッケージは未署名のため手順は署名検証を無効にする前提、Collectorも含まれません。現時点は検証環境で試す段階で、本番は言語ごとのエージェントを個別に入れる方法を続けます。

KubernetesでのCollector配置：DaemonSetとDeploymentの二層

Kubernetesでは、HelmチャートかOpenTelemetry OperatorでCollectorを入れます。各ノードで集めるDaemonSetと、集約して送るDeploymentの二層構成が定番で、Operatorを使うとPodへの自動計装の注入も宣言的に管理できます。Operator自体はStatusページで「mixed」とされ、v1alpha1とv1beta1のリソースが混在している点に注意します。構成例はOpenTelemetryのKubernetes構成｜Operator導入とCollector二層設計にまとめています。

OpenTelemetryとPrometheusの違いと連携

OpenTelemetryとPrometheusの役割・収集方式・データモデルの比較

「OpenTelemetryとPrometheusの比較」は、比べる対象の層が違う点を押さえると整理できます。Prometheusはメトリクスを集めて時系列DBに保存し、PromQLで照会・アラートまで行う監視システムです。OpenTelemetryは3シグナルを計装して運ぶ標準で、保存の機能を持ちません。

OTelで計装したメトリクスの保存先としてPrometheusを使う組み合わせが一般的です。差分（delta）で送る送信元からPrometheusへ入れる場合は、Prometheusの公式ガイドのとおり実験的な機能フラグで累積へ変換する必要があり、送信側を累積にそろえるほうが扱いやすくなります。

Prometheus 3系のOTLP受信へCollectorから書き込む設定

Prometheus 3系は、起動フラグ--web.enable-otlp-receiverを付けると/api/v1/otlp/v1/metricsでOTLP（HTTP）を受けます。OTLPの受け取り自体は2023年のv2.47.0で実験機能として入り、3.0でこのフラグに変わりました。3.xの安定性保証には受信エンドポイントが含まれています。既定で無効なのは、Prometheusが認証なしで動くため、明示しない限り外部からの書き込みを受けない設計だからです。Collector側はOTLP/HTTPのexporterで、末尾の/v1/metricsを除いたURLを指定します。

# prometheus.yml（OTLPで受けるときの推奨設定の一部）
storage:
  tsdb:
    out_of_order_time_window: 30m
otlp:
  promote_resource_attributes:
    - service.name
    - service.instance.id
    - host.name

上の設定をprometheus.ymlに保存し、次のコマンドでPrometheusを起動します。

prometheus --config.file=prometheus.yml --web.enable-otlp-receiver

次の設定はCollector側の設定ファイルに保存します。送信先のホスト名は実環境に置き換えてください。

# Collector側（host_metricsで集め、resource_detectionでhost.nameを付けて送る）
receivers:
  host_metrics:
    collection_interval: 30s
    scrapers:
      cpu:
      memory:
processors:
  resource_detection:
    detectors: [system]
  batch:
exporters:
  otlp_http/prometheus:
    endpoint: http://prometheus.internal:9090/api/v1/otlp
    tls:
      insecure: true
service:
  pipelines:
    metrics:
      receivers: [host_metrics]
      processors: [resource_detection, batch]
      exporters: [otlp_http/prometheus]

この構成をPrometheus 3.15.1とotelcol-contrib 0.164.0で動かし、host_metricsのcpuとmemoryを送ったところ、Prometheus側にはsystem_cpu_time_seconds_total・system_memory_usage_bytes・system_cpu_logical_countの3系列名が入りました。OTelのsystem.memory.usage（単位By）が、既定の変換方式UnderscoreEscapingWithSuffixesによってアンダースコア区切りと単位の接尾辞付きの名前に変わったことになります。

ラベルの付き方にも癖があります。host_metricsはResource属性を付けないため、ホスト名はresource_detectionプロセッサのsystem検出器でhost.nameとして付けています。これをpromote_resource_attributesに書くとhost_nameラベルとして全系列に付きました。任意のResource属性は既定では各メトリクスのラベルに昇格しないため、ホスト別に集計したい属性はここで指定します。また実測では送信元にservice.nameとservice.instance.idの両方が無かったため、job・instanceラベルとtarget_info系列は作られませんでした。本番ではresourceプロセッサなどでservice.nameに加え、各インスタンスを識別する一意なservice.instance.idも付けてから送ります。out_of_order_time_windowは、複数のCollectorから届くサンプルの順序が前後しても取りこぼさないための設定です。

既存のPrometheusやZabbixを残して併用する判断

Prometheusのスクレイプ運用が回っているなら置き換える必要はなく、exporterは残してアプリのトレースと固有のメトリクスだけをOTelで足すのが最も負担の小さい形です。受け側のPrometheusの構築と保持期間の見積りはPrometheusで監視を構築する手順｜exporter設計・PromQL・保持期間の見積り、ログとトレースまで含めてGrafanaスタックへ流す構成はGrafana OpenTelemetry連携の構成｜OTLP受信から3シグナル統合までで扱っています。

Zabbixのような統合監視ツールでも同じで、アラートはZabbixに残し、詳細なテレメトリをOTelで足せば既存の通知や運用手順を壊さずに済みます。Zabbixの仕組みはZabbixとは？仕組み・できること・費用・他ツールとの違いで整理しています。

AWS・Datadog・Sentryなど送信先ごとの受け口

AWSでは、OTelを基にした配布物AWS Distro for OpenTelemetry（ADOT）が提供され、X-Ray SDKとX-Rayデーモンは2026年2月25日にメンテナンスモードへ移りました（以後のリリースはセキュリティ修正のみ）。X-Rayのドキュメント履歴には、2027年2月25日にSDKとデーモンのサポートを終了するという告知が載っています。新規の計装はOTelのSDKかADOTで書くのが前提になります。X-Rayの位置づけの変化はAWS X-Rayとは｜CloudWatchとの違いとOpenTelemetry移行後の使い方、ADOTとCloudWatchを組み合わせる構成はAWSオブザーバビリティの実装｜ADOT・CloudWatch・Container Insightsで計装する構成で解説しています。

監視SaaSはOTLPの受け口を持ちますが、独自エージェント経由と比べて使える機能が欠けることがあります。DatadogはDatadog OpenTelemetry連携の4方式、SentryはSentry OpenTelemetry連携の3経路で方式ごとの差を事前に確認しておきます。

導入時に注意するデータ量・機微情報・版の追従

テレメトリは放置するとデータ量と保管費が膨らむため、トレースはサンプリングで間引き、メトリクスは属性の組み合わせ（カーディナリティ）を抑えます。開始時に間引くヘッドベースか、完了後に選別するテールベースかの選び方はトレースサンプリングとは？ヘッドベースとテールベースの仕組みで扱っています。Linuxホストでは、host_metricsのprocessスクレイパーを有効にするとプロセスごとに系列が増えるため、調査が必要なときだけ対象を絞って使います。

属性にメールアドレスやトークンを載せないこと、OTLPの通信のTLS化と認証は最初の設定で済ませます。Collectorは2週間前後でリリースされ設定の書き換えを伴う変化も入るため、版を固定し、決まった間隔でCHANGELOGの「Breaking changes」を読んでから上げます。

OpenTelemetryを採用する条件と見送る場面

複数バックエンド・サービス間トレースでのOTel採用条件

Collectorの更新と障害対応を担当する体制を確保でき、次のいずれかに当てはまるなら、OTelの採用をすすめます。

• 監視SaaSの乗り換えや併用を数年以内に検討する可能性がある。
• リクエストが複数のサービスをまたぎ、遅延の発生箇所をトレースで特定したい。
• Linuxサーバー・コンテナ・複数のクラウドが混在し、収集の仕組みをそろえたい。

これらの環境では、製品ごとに分散していた収集設定と送信先の管理をCollectorに集約できます。

Collectorの配置や送信先の選定を含めた監視基盤は、作った後の版の追従と設定の見直しまでが運用の範囲です。一創ではシステムの保守運用・内製化支援として、監視基盤の運用設計と担当者への引き継ぎを支援しています。

少数サーバーの死活監視における既存ツール継続の判断

監視対象が数台のLinuxサーバーで、知りたいのがCPU・ディスク使用率と死活だけなら、OTelを新たに入れる理由は薄いと判断します。Zabbixやnode_exporterで足りている環境にCollectorを加えると、設定ファイルと版の追従という運用対象が1つ増えるだけです。追従する担当者を置けない体制なら見送り、アプリのトレースが必要になった時点を切り替えの目安にします。

よくある質問

OTelの読み方は？OpenTelemetryとの関係は？

OTelはOpenTelemetryの略称で、「オーテル」と読むのが一般的です。OpenTelemetry自体は「オープンテレメトリ」と読みます。どちらも同じプロジェクトを指し、公式サイトやGitHubのリポジトリ名でもOTelの表記が使われています。

127.0.0.1:4317へ送ってもCollectorに届かないのはなぜですか？

まず送り手と受け手が同じホスト（同じネットワーク名前空間）にいるかを確かめます。Collectorの受信口は既定でlocalhostにしか開かないため、コンテナ内のアプリから127.0.0.1へ送るとコンテナ自身を指してしまい届きません。この場合はCollectorのendpointを0.0.0.0:4317にしてサービス名で送ります。次に、HTTPで送っているのに4317番を指定していないか（HTTPは4318番）を確認し、最後にdebugエクスポーターで受信件数を見ます。

Linux自体のテレメトリ（Ubuntu Insightsなど）とは別物ですか？

別物です。OpenTelemetryは運用者が自分のサーバーやアプリの状態を手元の監視基盤へ集める仕組みで、ディストリビューションのテレメトリは開発元が利用状況を集める仕組みです。Ubuntuは25.10でUbuntu ReportからUbuntu Insightsへの部分的な移行を開始したと公式Discourseで告知しており、送信はオプトインで、同意はubuntu-insights consentコマンドで変更できます。

Prometheusのnode_exporterとCollectorのhost_metricsはどちらを使う？

Prometheusでの監視がすでに回っていて、ホストの数値だけが必要ならnode_exporterで足ります。トレースやログも同じ経路で集めたい、あるいは送信先を将来変える可能性があるなら、Collectorのhost_metricsで集めてPrometheusのOTLP受信へ送る構成にします。この場合、メトリクス名はnode_exporterのnode_で始まる名前とは別体系になるため、既存のダッシュボードやアラートのPromQLは書き換えが必要です。

Collectorは必ず必要ですか？

アプリのSDKから直接バックエンドへ送ることもできます。この記事のhost_metricsとjournald receiverで収集する構成ではCollectorが必要です。ただし、node_exporterなど別の収集手段もあるため、サーバー単位の観測にCollectorが必須というわけではありません。トレースの保存先として広く使われるJaegerもv2でCollectorを土台に作り直されており、詳しくはJaegerとは？v2でOpenTelemetryを取り込んだ分散トレーシングの仕組みで扱っています。

関連記事

• Prometheusで監視を構築する手順｜exporter設計・PromQL・保持期間の見積り
• OpenTelemetryのKubernetes構成｜Operator導入とCollector二層設計
• Grafana OpenTelemetry連携の構成｜OTLP受信から3シグナル統合まで
• OpenTelemetryのメトリクス実装｜計器選定とカーディナリティ設計
• OpenTelemetry Collector Contribとは｜coreとの違いとocbで作る自作distro