--- title: "OpenTelemetryとは？仕組み・Collectorの導入手順とPrometheusとの違い【2026年10月】" url: "https://www.issoh.co.jp/tech/details/3625/" published: 2024-09-20 updated: 2026-10-28 categories: ["監視・オブザーバビリティ"] publisher: "株式会社一創" --- # 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移行の手順](/tech/details/16561/)で扱っています。 [CNCFのプロジェクトページ](https://www.cncf.io/projects/opentelemetry/)によると、2026年5月11日に最上位の成熟度であるGraduatedへ移行し、KubernetesやPrometheusと同じ段階になりました。読み方は「オープンテレメトリ」、略称のOTelは「オーテル」と読むのが一般的です。 ### 保存・可視化・アラートを持たない設計とバックエンドの役割 [公式の「What is OpenTelemetry?」](https://opentelemetry.io/docs/what-is-opentelemetry/)は、OpenTelemetryを「observability backend」ではないと明記し、保存と可視化は他のツールに任せる立場を取っています。OTelを入れただけではダッシュボードもアラートも手に入らないため、計装と転送の層（OTel）と、保存・分析する層（Prometheus、Grafana Tempo、Datadogなど）を別々に選びます。この分業により、OTelによるアプリの計装を維持したまま送信先を変更しやすくなります。ただし、認証・属性変換・ダッシュボード・アラートは移行先に合わせた調整が必要です。監視とオブザーバビリティの言葉の違いから整理したい場合は[オブザーバビリティ（可観測性）とは？監視・APM・テレメトリとの違いと使い分け](/column/details/3077/)が入口になります。 ## 3つのシグナルと言語SDKごとの成熟度 ### トレース・メトリクス・ログの役割と相関 テレメトリデータとは、システムの状態や挙動を外から観測するために出力されるデータの総称です。OpenTelemetryは次の3つを主要なシグナルとして扱います。 | シグナル | 記録するもの | 主な用途 | | ----- | ----------------------- | ------------- | | トレース | 1リクエストがサービス間を流れた経路と所要時間 | 遅延箇所の特定 | | メトリクス | CPU使用率・レイテンシなどの数値の時系列 | 傾向監視・しきい値アラート | | ログ | 個々のイベントの記録 | 原因の究明・監査 | OTelではログにtrace\_id・span\_idを付け、メトリクスにはexemplarを記録することでトレースと関連付けられます。対応したバックエンドで設定しておけば、メトリクスの異常から該当時間帯のトレースへ、遅いスパンからそのリクエストのログへと移れます。 ### 言語SDKの安定度：PythonとJavaScriptのログはDevelopment [仕様のステータス](https://opentelemetry.io/docs/specs/status/)では3シグナルともAPI（ログはBridge API）とOTLPが安定版です（メトリクスのSDK仕様だけは一部が未確定のmixed）。ただし各言語のSDKの成熟度は別に管理されています。[公式のStatusページ](https://opentelemetry.io/status/)の言語別の表を、主要言語について抜き出すと次のとおりです。 | 言語 | トレース | メトリクス | ログ | | ---------- | ------ | ----------- | ----------------- | | Java | Stable | Stable | Stable | | C#/.NET | Stable | Stable | Stable | | Go | Stable | Stable | Release candidate | | Python | Stable | Stable | Development | | JavaScript | Stable | Stable | Development | | PHP | Stable | Stable | Stable | | Ruby | Stable | Development | Development | | Rust | Beta | Stable | Stable | 「主要言語で3シグナルがGA」という説明は、PythonやNode.jsには当てはまりません。この2言語でログをSDKから送ると設定や出力形式が今後変わりうるため、安定を優先するならログはファイルに書き、Collectorのfile\_log receiverで読む構成が無難です。選び分けは[OpenTelemetryのログ実装｜直接送信とfilelog receiverの選び分け](/tech/details/16555/)、メトリクスの計器の選び方は[OpenTelemetryのメトリクス実装｜計器選定とカーディナリティ設計](/tech/details/16557/)で扱っています。 ### 第4のシグナル・プロファイルとeBPFプロファイラの導入条件 関数単位でCPUやメモリの消費箇所を記録するプロファイルは、4つ目のシグナルとして開発が進んでおり、[公式の概念ページ](https://opentelemetry.io/docs/concepts/signals/profiles/)での状態はAlphaです。Linuxでは[OpenTelemetry eBPF Profiler](https://github.com/open-telemetry/opentelemetry-ebpf-profiler)がアプリに手を入れずにホスト全体のスタックを採取し、READMEは、開発側のテストでのオーバーヘッド上限をCPU 1%・メモリ250MBと記載しています。あらゆる環境での上限を保証する数値ではありません。 カーネル要件は段階的に上がっており、READMEには「5.4を最後にサポートしたコミット以降は5.10以上が必要な場合がある」と書かれています。本番ではCollectorにreceiverとして組み込んだ専用ディストリビューション（otelcol-ebpf-profiler）が推奨で、リポジトリから単体でビルドしたバイナリは本番用途の対象外です。仕組みの前提となるeBPFは[eBPFとは？Linuxカーネルを拡張する仕組みと可観測性・ネットワークでできること](/tech/details/13232/)で解説しています。 ## OTLPの通信方式とgRPC 4317・HTTP 4318の使い分け OTLP（OpenTelemetry Protocol）は、3シグナルを共通のスキーマで運ぶOTelの標準プロトコルです。[OTLPの仕様](https://opentelemetry.io/docs/specs/otlp/)は、gRPCの既定ポートを4317、HTTPの既定ポートを4318と定めています。Collector同士をつなぐならgRPC、プロキシ経由やブラウザからの送信ならHTTPが目安です。HTTPの場合、シグナルごとのパスは`/v1/traces`・`/v1/metrics`・`/v1/logs`です。 見落としやすいのが受信側の待ち受けアドレスです。[CollectorのOTLP receiverのREADME](https://github.com/open-telemetry/opentelemetry-collector/blob/main/receiver/otlpreceiver/README.md)では、`endpoint`の既定値は`localhost:4317`と`localhost:4318`です。同じホストからの送信は届きますが、別ホストや別コンテナからは届きません。外から受けるときだけ`0.0.0.0:4317`を明示し、ファイアウォールで送信元を絞ってTLSと認証を設定します。 ## アプリを計装する方法：自動計装と手動計装 テレメトリを生み出す工程を計装（instrumentation）と呼び、OTelは2つの方法を用意しています。 - **自動計装（ゼロコード計装）**：Javaエージェントや`opentelemetry-instrument`コマンドなどを足すだけで、HTTP・DB・gRPCなど主要ライブラリのトレースとメトリクスが出る。コードの変更は最小限で済む。 - **手動計装**：SDKのAPIで、業務処理に固有のスパンや属性（注文ID、テナントなど）を足す。自動計装で取れない粒度を補う。 自動計装でサービス間の流れを可視化し、中身が見えない処理にだけ手動のスパンを足すのが効率的です。属性名は[OpenTelemetryのセマンティック規約](/tech/details/16568/)に合わせておくと、バックエンドを替えてもダッシュボードやクエリを作り直す量が減ります。 ## 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](/tech/details/16572/)で整理しています。 ### 型名のスネークケース移行と旧名で起動したときの警告 2026年に入り、部品の型名はスネークケースへ順に改名されています。[coreのCHANGELOG](https://github.com/open-telemetry/opentelemetry-collector/blob/main/CHANGELOG.md)と[contribのCHANGELOG](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/CHANGELOG.md)によると、主な改名は次の版で入りました。 | 旧名 | 現行名 | 改名された版 | | --------------------- | ------------- | -------- | | otlphttp（exporter） | otlp\_http | v0.144.0 | | filelog（receiver） | file\_log | v0.149.0 | | hostmetrics（receiver） | host\_metrics | v0.151.0 | | queuebatch（processor） | queue\_batch | v0.162.0 | 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インストール手順](https://opentelemetry.io/docs/collector/install/binary/linux/)のとおり、Collectorの各リリースにはamd64・arm64などのDEB・RPMパッケージが含まれ、systemdのある環境ではサービスとして登録されます。[Releasesページ](https://github.com/open-telemetry/opentelemetry-collector-releases/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ユニット](https://github.com/open-telemetry/opentelemetry-collector-releases/blob/main/distributions/otelcol-contrib/otelcol-contrib.service)は、環境ファイル`/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・ユニットファイルの基本](/tech/details/8160/)で確認できます。 ### host\_metricsとjournaldでCPU・メモリ・systemdログを集める設定 ホストの数値は[Host Metrics receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/hostmetricsreceiver/README.md)（メトリクスはbeta）で集め、cpu・memory・load・filesystem・networkなどのスクレイパーを選んで有効にします。ログは[Journald receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/journaldreceiver/README.md)（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向けのシステムパッケージ](https://opentelemetry.io/docs/platforms/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ページ](https://opentelemetry.io/status/)で「mixed」とされ、v1alpha1とv1beta1のリソースが混在している点に注意します。構成例は[OpenTelemetryのKubernetes構成｜Operator導入とCollector二層設計](/tech/details/16559/)にまとめています。 ## OpenTelemetryとPrometheusの違いと連携 ### OpenTelemetryとPrometheusの役割・収集方式・データモデルの比較 「OpenTelemetryとPrometheusの比較」は、比べる対象の層が違う点を押さえると整理できます。Prometheusはメトリクスを集めて時系列DBに保存し、PromQLで照会・アラートまで行う監視システムです。OpenTelemetryは3シグナルを計装して運ぶ標準で、保存の機能を持ちません。 | 項目 | OpenTelemetry | Prometheus | | ------ | --------------------------- | --------------------- | | 対象 | トレース・メトリクス・ログ | メトリクス | | 役割 | 計装・収集・転送 | 収集・保存・照会・アラート | | 収集方式 | プッシュ（OTLP）が中心 | プル（スクレイプ）が中心 | | メトリクス名 | ドット区切り（system.memory.usage） | 既定のOTLP変換：アンダースコア＋接尾辞 | | 累積の扱い | 累積（cumulative）と差分（delta） | 累積が前提 | OTelで計装したメトリクスの保存先としてPrometheusを使う組み合わせが一般的です。差分（delta）で送る送信元からPrometheusへ入れる場合は、[Prometheusの公式ガイド](https://prometheus.io/docs/guides/opentelemetry/)のとおり実験的な機能フラグで累積へ変換する必要があり、送信側を累積にそろえるほうが扱いやすくなります。 ### 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の安定性保証](https://prometheus.io/docs/prometheus/latest/stability/)には受信エンドポイントが含まれています。既定で無効なのは、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・保持期間の見積り](/tech/details/17516/)、ログとトレースまで含めてGrafanaスタックへ流す構成は[Grafana OpenTelemetry連携の構成｜OTLP受信から3シグナル統合まで](/tech/details/16566/)で扱っています。 Zabbixのような統合監視ツールでも同じで、アラートはZabbixに残し、詳細なテレメトリをOTelで足せば既存の通知や運用手順を壊さずに済みます。Zabbixの仕組みは[Zabbixとは？仕組み・できること・費用・他ツールとの違い](/tech/details/3294/)で整理しています。 ## AWS・Datadog・Sentryなど送信先ごとの受け口 AWSでは、OTelを基にした配布物AWS Distro for OpenTelemetry（ADOT）が提供され、X-Ray SDKとX-Rayデーモンは2026年2月25日にメンテナンスモードへ移りました（以後のリリースはセキュリティ修正のみ）。X-Rayの[ドキュメント履歴](https://docs.aws.amazon.com/xray/latest/devguide/document-history.html)には、2027年2月25日にSDKとデーモンのサポートを終了するという告知が載っています。新規の計装はOTelのSDKかADOTで書くのが前提になります。X-Rayの位置づけの変化は[AWS X-Rayとは｜CloudWatchとの違いとOpenTelemetry移行後の使い方](/tech/details/6812/)、ADOTとCloudWatchを組み合わせる構成は[AWSオブザーバビリティの実装｜ADOT・CloudWatch・Container Insightsで計装する構成](/tech/details/15297/)で解説しています。 監視SaaSはOTLPの受け口を持ちますが、独自エージェント経由と比べて使える機能が欠けることがあります。Datadogは[Datadog OpenTelemetry連携の4方式](/tech/details/16564/)、Sentryは[Sentry OpenTelemetry連携の3経路](/tech/details/16571/)で方式ごとの差を事前に確認しておきます。 ## 導入時に注意するデータ量・機微情報・版の追従 テレメトリは放置するとデータ量と保管費が膨らむため、トレースはサンプリングで間引き、メトリクスは属性の組み合わせ（カーディナリティ）を抑えます。開始時に間引くヘッドベースか、完了後に選別するテールベースかの選び方は[トレースサンプリングとは？ヘッドベースとテールベースの仕組み](/tech/details/15713/)で扱っています。Linuxホストでは、`host_metrics`の`process`スクレイパーを有効にするとプロセスごとに系列が増えるため、調査が必要なときだけ対象を絞って使います。 属性にメールアドレスやトークンを載せないこと、OTLPの通信のTLS化と認証は最初の設定で済ませます。Collectorは2週間前後でリリースされ設定の書き換えを伴う変化も入るため、版を固定し、決まった間隔でCHANGELOGの「Breaking changes」を読んでから上げます。 ## OpenTelemetryを採用する条件と見送る場面 ### 複数バックエンド・サービス間トレースでのOTel採用条件 Collectorの更新と障害対応を担当する体制を確保でき、次のいずれかに当てはまるなら、OTelの採用をすすめます。 - 監視SaaSの乗り換えや併用を数年以内に検討する可能性がある。 - リクエストが複数のサービスをまたぎ、遅延の発生箇所をトレースで特定したい。 - Linuxサーバー・コンテナ・複数のクラウドが混在し、収集の仕組みをそろえたい。 これらの環境では、製品ごとに分散していた収集設定と送信先の管理をCollectorに集約できます。 Collectorの配置や送信先の選定を含めた監視基盤は、作った後の版の追従と設定の見直しまでが運用の範囲です。一創では[システムの保守運用・内製化支援](/service/system/maintenance/)として、監視基盤の運用設計と担当者への引き継ぎを支援しています。 ### 少数サーバーの死活監視における既存ツール継続の判断 監視対象が数台の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](https://discourse.ubuntu.com/t/ubuntu-insights-how-telemetry-is-changing-on-ubuntu-desktop/73442)で告知しており、送信はオプトインで、同意は`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を取り込んだ分散トレーシングの仕組み](/tech/details/15582/)で扱っています。 ## 関連記事 - [Prometheusで監視を構築する手順｜exporter設計・PromQL・保持期間の見積り](/tech/details/17516/) - [OpenTelemetryのKubernetes構成｜Operator導入とCollector二層設計](/tech/details/16559/) - [Grafana OpenTelemetry連携の構成｜OTLP受信から3シグナル統合まで](/tech/details/16566/) - [OpenTelemetryのメトリクス実装｜計器選定とカーディナリティ設計](/tech/details/16557/) - [OpenTelemetry Collector Contribとは｜coreとの違いとocbで作る自作distro](/tech/details/16572/) --- 出典: [OpenTelemetryとは？仕組み・Collectorの導入手順とPrometheusとの違い【2026年10月】]()（株式会社一創）