NRDOT 入門

はじめに

近年、IT システムのマルチクラウド化やマイクロサービス化、サーバーレスアーキテクチャの普及に伴い、システム全体の稼働状況を把握するオブザーバビリティの重要性が急速に高まっています。その中で、テレメトリデータ（メトリクス、ログ、トレース）の収集において業界の標準仕様として急速に支持を集めているのが、Cloud Native Computing Foundation (CNCF) のオープンソースプロジェクトである OpenTelemetry（以下、OTel） です。

現在、多くのエンジニアがベンダーロックインの排除やオープンな規格によるデータ集約を目指し、OTel の導入・検証を進めています。一方で、すでに New Relic をご利用中のお客様の中には、「現状の New Relic エージェントによる監視から、どのように OTel へと移行、あるいは共存させるべきか」「OTel コレクターの構築や運用の負荷が懸念される」といった疑問や課題をお持ちの方も少なくないのではないかと思います。

本記事では、New Relic の利用経験がある既存ユーザーの皆様を対象に、OpenTelemetry の基本概念をおさらいしつつ、New Relic が公式に提供している事前構築済みのコレクターディストリビューション NRDOT（New Relic Distribution of OpenTelemetry）の概要とメリット、そして手軽に始められるハンズオン手順について解説します。

OpenTelemetry (OTel) とは？（簡単なおさらい）

OpenTelemetry（OTel）とは、アプリケーションやインフラストラクチャからテレメトリデータを収集、生成、エクスポートするためのオープンソースの標準化フレームワークおよびツール群です。

かつては、監視ベンダーごとに異なる独自仕様のエージェントや API、SDK を個別に導入する必要がありました。しかし、OTel の登場により、以下の標準化が進行しています。

• 統一されたデータフォーマット（OTLP）: Traces、Metrics、Logs の3つの主要なテレメトリデータを、ベンダーを問わず統一された規格（OpenTelemetry Protocol: OTLP）で送信・表現できます。
• ベンダーロックインの排除: コードに埋め込む SDK やデータ収集を担うコレクターが標準化されているため、背後のバックエンド（可観測性プラットフォーム）を柔軟に変更したり、複数のベンダーに同時にデータを送信したりすることが容易になります。
• 豊富なコミュニティとエコシステム: CNCF において Kubernetes に次いで活発なプロジェクトの一つであり、主要なクラウドプロバイダーや OSS コミュニティ、そして New Relic を含む多くのオブザーバビリティベンダーが開発を主導・サポートしています。

2026 年現在、OTel は標準的なオブザーバビリティ環境を構築するためのデファクトスタンダードとしての地位を確立しつつあります。

New Relic と OpenTelemetryの関係

New Relic は、以前より OpenTelemetry プロジェクトに貢献するベンダーの 1 社であり、その対応に力を入れてきています。New Relic の OTel の取り組みは以下の通りです。

• OTLP データのネイティブ受け入れ

  • New Relicのプラットフォーム（Telemetric Data Platform）は、OTel のデータプロトコルである OTLP をネイティブにサポートしています。つまり、お客様が用意した任意のOpenTelemetry Collector（Upstream Collector）や、アプリケーションに組み込まれた Otel SDK から、直接 New Relic のエンドポイントへ OTLP 形式でデータを送信するだけで、そのままデータの格納と可視化・分析が行えます。

• 独自エージェントと OTel の二者択一からの脱却

  • これまでは、従来の New Relic エージェント（APM エージェントや Infrastructure エージェントなど）を維持するか、あるいはこれらをすべて排除して一から OSS の OTel パイプラインを構築するかの選択を迫られることがありました。しかし、New Relicは「ハイブリッドなアプローチ」および「OTel へのスムーズな移行パス」を支援するアプローチをとっています。

OpenTelemetry の基本構成要素と NRDOT・既存エージェントの位置付け

NRDOT は OTel におけるコレクターのパッケージです。NRDOT では、特に New Relic との連携を円滑に進めるための機能が設定されています。OTel におけるコレクターは、テレメトリデータの受信(Receivers)、処理(Processors), エクスポート(Exporters)を受け持ちます。

本章では、NRDOT の役割を理解するために、まずは OpenTelemetry の技術的な構成要素と、それが New Relic の既存環境においてどのように位置づけられるかを見ていきます。

OpenTelemetry Collector の構成要素

OpenTelemetry におけるデータ収集パイプラインの中心を担うのがコレクター(Collector)です。コレクター内部のパイプラインは、主に以下の3つの主要コンポーネントで構成されています。

• レシーバー (Receivers): 外部からテレメトリデータを受信、またはシステムからデータを収集する役割を持ちます。
  • 例: アプリケーションの SDK 等からデータを受け取る otlp、ホストの稼働統計を収集する hostmetrics、Prometheus形式のメトリクスを収集する prometheus など。
• プロセッサー (Processors): レシーバーが収集したデータを次の宛先に送信する前に、フィルタリング、属性の追加、バッチング（一括処理）、個人情報のマスキングなどの加工処理を行います。
  • 例: データをまとめて効率よく送信する batch、メモリ使用量を制限する memory_limiter、特定のメトリクスをドロップする filter など。
• エクスポーター (Exporters): プロセッサーによる加工済みのデータを、オブザーバビリティバックエンドなどの最終目的地に送信します。
  • 例: New Relicなどの外部プラットフォームにOTLP形式で送る otlp、デバッグ用のログ出力を行う debug など。

OTel コレクターでは、上記のようにテレメトリデータの受信、処理、エクスポートをモジュール化することにより、単一のプロセスで複数の機能を実行することができ、複数のエージェントを実行する必要がありません。結果として、パッケージのメンテナンスなどの管理も一元化することが可能になります。

NRDOT の仕様上の位置付け

OpenTelemetry プロジェクトは、コミュニティが開発した数百に及ぶレシーバーやエクスポーターをアップストリーム（OSS)版として公開しています。NRDOT（New Relic Distribution of OpenTelemetry）は、この OpenTelemetry プロジェクト公式の機能を、New Relic がテスト・サポートを行うサードパーティディストリビューションです。「New Relic で OpenTelemetryを使う際、どのレシーバーやプロセッサーを組み合わせればよいか」を検討し、必要なコンポーネントがカスタマイズされています。これにより、ユーザーが個別にビルドを管理する手間をなくし、即座に本番運用できるパッケージとして提供されています。

既存の New Relic エージェントとの関係

「NRDOT を導入したら、既存の New Relic エージェント（APM や Infrastructure 等）は使えなくなるのか？」という疑問を持たれるかもしれませんが、答えは「いいえ」です。両者は対立するものではなく、以下のように共存、あるいは段階的な移行が可能です。

• APM（アプリケーション）レイヤーとのハイブリッド共存: 既存の New Relic APM エージェントには、OpenTelemetry API との互換性が組み込まれています。すでに New Relic APM エージェントで計装（監視設定）されているアプリケーションに、部分的に OTel SDK を用いたカスタム計装を追加しても、両方のデータが New Relic 上でシームレスに統合されます。

• Infrastructure（インフラ）レイヤーの移行とシームレスな統合: NRDOT は、従来の New Relic Infrastructure エージェントの代替手段となり得ます。NRDOT で収集されたホストメトリクス（CPU やメモリ）は、New Relic の従来の Infrastructure UI（ホスト画面）でそのまま表示できます。これにより、「データ収集レイヤーはオープンスタンダード（OTel）に移行しつつ、可視化画面は使い慣れた New Relic の UI を維持する」という運用が実現します。

NRDOT（New Relic Distribution of OpenTelemetry）の特徴

それでは、具体的に NRDOT が提供する具体的なメリットや機能について解説します。

• 設定の最適化と手間の削減

  • New Relic 向けのエンドポイント構成や、一般的な認証ヘッダー（APIキー）の設定があらかじめ想定されており、最小限の記述で稼働させることができます。また、マルチリージョン（US/EU/JP など）に対応したデフォルト設定も容易です。

• New Relic による公式サポート

  • OSS のコレクターを本番運用する際、予期せぬエラーやパフォーマンス問題が発生した際のトラブルシューティングが懸念点となります。NRDOT を使用している場合、New Relic のグローバルテクニカルサポートを通じて公式な技術支援を受けることができるため、運用リスクを最小限に抑えられます。New Relic グローバルテクニカルサポートのサポート範囲については、以下のドキュメントをご参照ください。

Global Technical Support offerings | New Relic Documentation

• 先進的な最適化機能のプリイン（Adaptive Telemetry Processor: ATP）
  • NRDOT では、2026 年 9 月現在でのプレビュー機能として Adaptive Telemetry Processor（ATP） が提供されています。ATP は、動的な閾値評価やプロセスのモニタリングに基づき、システムに影響のない低価値のテレメトリデータを動的に間引き、リソース逼迫やアノマリー（異常検知）発生時の重要なコンテキストを含むデータを優先して残すインテリジェントフィルタリングを実現します。これにより、データ転送コストを最適化しつつ、オブザーバビリティの品質を維持できます。

[ハンズオン] NRDOT を実際に動かしてみよう

ここでは、手軽に検証環境を構築できるよう、Docker を使用したコンテナ環境での NRDOT の起動と、ホストメトリクスの収集手順を紹介します。

Step 1: 前提条件の整理

NRDOT からデータを送信するために、以下の準備を行ってください。

• New Relic アカウントの用意（まだお持ちでない場合は無料アカウントを作成してください）。

• インジェスト用のライセンスキーの取得。

  • New Relic UIの右上のユーザーメニューから API keys に進み、INGEST - LICENSE タイプのキーを作成し、キーの値を手元に控えます。

• お使いの組織のリージョン確認（US/EU/JP）。

  • アカウントのログイン URL やシステム設定から判別可能です。

Step 2: NRDOTの設定ファイル（config.yaml）の作成

作業用ディレクトリを作成し、その中に config.yaml という名前で以下の内容を保存します。このファイルは、OTel Collector の動作（受信、処理、送信パイプライン）を定義するものです。

receivers:
  # ホスト（コンテナ内部/バインドマウントしたホスト）のメトリクスを収集
  hostmetrics:
    collection_interval: 10s
    scrapers:
      cpu:
      memory:
      load:
      disk:
      filesystem:
      network:

processors:
  # メトリクスやトレースを効率的にバッチング（一括送信）する
  batch:
    timeout: 10s
    send_batch_size: 1000

exporters:
  # OTLP プロトコルで New Relic のエンドポイントへエクスポートする設定
  otlp:
    # US リージョンの場合は otlp.nr-data.net:443
    # EU リージョンの場合は otlp.eu.nr-data.net:443
    # JP リージョンの場合は otlp.jp.nr-data.net:443 
    endpoint: otlp.nr-data.net:443
    headers:
      api-key: "${env:NEW_RELIC_LICENSE_KEY}"

service:
  pipelines:
    metrics:
      receivers: [hostmetrics]
      processors: [batch]
      exporters: [otlp]

上記の設定では、CPU やメモリなどのメトリクスを収集するレシーバーであるホストメトリクス(hostmetrics)レシーバーを設定しています。これにより、インフラストラクチャエージェントが収集するメトリクス相当のテレメトリデータを New Relic に連携することができます。

エクスポーターで指定する OTLP エンドポイントに関しては、先日開設された日本国内データセンター（JP リージョン）のエンドポイントにも OTLP に対応したエンドポイントが用意されています。JP リージョンをご利用いただくことで、より低遅延かつデータレジデンシー要件を満たした運用が可能です。セキュリティやコンプライアンス、パフォーマンス上の要件を満たす必要がある場合には、JP リージョンの利用もご検討ください。

Step 3: Docker によるコンテナの起動

作成した config.yaml を配置したディレクトリで、以下のコマンドを実行します。環境変数 NEW_RELIC_LICENSE_KEY には、Step 1 で控えたライセンスキーを代入してください。

※ここでは、New Relic が公式に提供している事前ビルド済みイメージ newrelic/nrdot-collector を使用します。

• 環境変数の設定（各自のライセンスキーに置き換えてください）

export NEW_RELIC_LICENSE_KEY="your_new_relic_license_key_here"

• コンテナの起動

環境変数 OTEL_RESOURCE_ATTRIBUTES に、リソース属性を指定します。リソース属性として host.id を指定しない場合、Entity Synthesis が機能せず、New Relic 内に NRDOT のエンティティが作成されない点にご注意ください。関連するエンティティが存在しないテレメトリデータは、New Relic 上で「参照はできるものの、他のデータと関連づけられていない」孤立したデータとなってしまいます。その他のリソース属性の設定として、host.name を指定することで、UI 上で作成されたエンティティを識別しやすくしています。

コンテナが起動したら、ログを確認してエラーが出ていないか（接続タイムアウトや認証エラーが発生していないか）を確認します。

docker logs nrdot-collector

Step 4: New Relic UIでのデータ確認

起動後数分が経過したら、New Relicのアカウントにログインし、データが届いているか、Infrastructure UI（Hosts）で確認します。

まず、New Relic の Web UI を開き、Infrastructure メニューから "Hosts"を開きます。正しくテレメトリーデータが New Relic に連携されている場合、通常の Infrastructure エージェントから送信されたホストと同様、ホスト一覧やリソース使用状況のグラフにデータが表示されるようになります。docker コマンド実行時に OTEL_RESOURCE_ATTRIBUTES で指定したホスト名(host.name)を持つホストエンティティがホスト一覧に表示されていれば、当該のホストの詳細画面で NRDOT から連携されたメトリクスを確認することが可能です。

おわりに

本記事では、OpenTelemetry の基本から、New Relic が推進する公式ディストリビューション NRDOT の役割、そして Docker を使用した簡単な起動方法について解説しました。

「オープンスタンダードに移行したいが、移行コストやサポート不在の運用リスクが気になる」というお客様にとって、NRDOT は最適な解決策となりえます。既存の New Relic プラットフォームの利便性や表現力（Infrastructure UI等）を活かしながら、収集レイヤーだけを標準規格に適応させることが可能です。

今回はホストメトリクス（システム監視）を中心とした構成例を示しましたが、NRDOT は Kubernetes 監視やログ転送、APM トレースの集約・ルーティングなど、多岐にわたるユースケースに対応可能です。まずは検証用の開発環境などから、NRDOT を用いたモダンなオブザーバビリティの導入をご検討ください。