OpenTelemetryは、アプリケーションとホストからテレメトリデータを収集し、そのデータをNewRelicにエクスポートするために使用できるツールキットです。データがNewRelicに入ると、New Relicプラットフォームを使用してデータを分析し、アプリケーションの問題を解決できます。
OpenTelemetryには、New Relicエージェントと重複する機能があるため、以下の情報を確認して、テレメトリの目標を達成するのに役立つかどうかを確認してください。すでにOpenTelemetryに精通していて、開始したい場合は、 セットアップ手順を参照してください。
OpenTelemetryに精通するのに役立つトピックを次に示します。
OpenTelemetryのメリット
OpenTelemetry は、サービスおよびホスト インストルメンテーションに安全でベンダーに依存しない 仕様を 提供するため、New Relic など、選択した個別のバックエンドにデータをエクスポートできます。OpenTelemetry は、サービスとホストのテレメトリ データを収集して転送する方法を標準化する API とライブラリの単一セットを提供します。
OpenTelemetryプロジェクトを構成するコンポーネントは以下の通りです。
- すべてのプロジェクトで一貫性を持たせるための、オブザーバビリティの中核となる柱の仕様。New Relic は、これらすべての シグナル: トレース、メトリクス、ログをサポートしています（詳細は以下の を参照 ）。
- 仕様書に基づいたインターフェースや実装を含むAPI Java、Python、Go、Erlangなどの言語専用に作成されたSDK（APIの参照実装）。
- ベンダーに依存しない実装で、処理やエクスポートを行うコレクターです。
- 任意のバックエンドにデータを送ることができるエクスポーター
OpenTelemetryの各コンポーネントが連携することで、遠隔測定データを取得する上でいくつかの明確な利点が生まれます。
機能 | 説明 |
|---|---|
ユビキタス計測機器 | 単一のオープンスタンダードな計測器は、世界中のエンジニアが貢献することで、より良いカバレッジと柔軟性を提供します。 |
将来性 | インストゥルメンテーションがライブラリやフレームワークに組み込まれ、より多くのベンダーがこのオープンスタンダードをサポートするようになれば、インストゥルメンテーションを変更する必要はなくなると確信できます。 |
新しい技術への対応 | 新しい技術が登場した場合、貢献者はOpenTelemetryへの統合を構築したり、ソースコードに直接インスツルメンテーションを追加することができ、エンドユーザーはこれらの新しい技術を容易にモニターすることができます。 |
シンプルな選択 | どのインスツルメンテーション・オプションを使用するか（プロプライエタリなオプションか、他のオープン・スタンダードのいずれか）を決める必要はありません。 |
クロスプラットフォーム対応 | OpenTelemetryは、様々な言語やバックエンドをサポートしています。OpenTelemetryは、既存の機器を変更することなく、テレメトリをキャプチャしてバックエンドに送信するための、ベンダーニュートラルなパスを表しています。 |
効率化された観測性 | ベンダーは、独自のエージェントやコレクターを開発する必要がないため、単一の規格に対するサポートやテストが容易になります。 |
高次元 | OpenTelemetryは次元メトリクスを使用しているため、AWSリージョン、Kubernetesクラスタ、サービスバージョンなど、データのより多くの側面でフィルタリングやファセットをかけることができます。また、次元メトリクスは、発生から報告までの時間短縮にもつながります。 |
OpenTelemetryのインスツルメンテーションとNew Relicのエージェントのどちらを使うべきでしょうか？
OpenTelemetry を検討する際に、New Relic も検討している可能性があります。 テレメトリ データもキャプチャするエージェント。
ご想像のとおり、OpenTelemetryエージェントとSDKから利用できる機能と、NewRelicエージェントから利用できる機能の間には多くの重複があります。これは、分散トレーステレメトリデータに関心がある場合に特に当てはまります。選択は、必要なものによって異なります。
New Relic と OpenTelemetry インストルメンテーションの両方を調べることをお勧めします。このセクションの情報には、考慮すべき幅広い概念が含まれています。違いを詳しく調べたい場合は、 詳細な比較を参照してください。また、 CNCF の Slack チャンネル #otel-newrelic でこれについて話し合って、 自分に最適なものを決定してください。最初に CNCF の Slack アカウントにサインアップする必要がある場合があります。
OpenTelemetry:進行中の作業
OpenTelemetryはまだ始まったばかりの規格なので、利用可能なものによって選択が影響を受ける可能性があります。仕様の現状については、 OpenTelemetryサイト で確認することができます。
言語固有の OpenTelemetry API や SDK の現状はさまざまで、中にはまだプレアルファ版の言語もあり、サービスをインストゥルメントする方法が記載されていない場合もあります。ほとんどの言語では、New Relic へのデータのエクスポートを開始するのに十分なトレースの実装があります。 各言語のOpenTelemetry仕様準拠の状況をまとめたGitHub の表をご覧ください。
OpenTelemetryが成熟するにつれて、新しいOpenTelemetryデータモデルを引き続きサポートし、プラットフォームで厳選されたUIエクスペリエンスを提供します。
NewRelicエージェント [#apm-agents]
一般に、New Relic の インフラストラクチャ エージェントは、サービスとホストのより多くのテレメトリ データを収集します。 さらに、幅広い構成オプションと広範な自動計測機能を提供します。
OpenTelemetryとNew Relicの連携について [#how-it-works]
以下のセクションの表は、各テレメトリー信号でサポートされている機能を示しています。以下のセクションの詳細やサポートされていないユースケースについて質問がある場合は、 CNCF Slackチャンネル までご連絡ください。また、このページで今後の更新をご確認ください。New Relic を使った実装の全体像を把握したい場合は、 リファレンスアーキテクチャ をご覧ください。
重要
New Relic の exporters for OpenTelemetry は現在非推奨となっており、OTLP を使用して New Relic にデータをエクスポートすることが推奨されています。
トレース
New Relic では、OTLP によるトレース信号の取り込みをサポートしています。上流の仕様の成熟度は 安定しています 。
OpenTelemetryのトレースとスパンは、NewRelicのトレースとスパンと互換性があります。 OpenTelemetryスパンには、オプションで属性（名前と値のペア）とリソース属性が含まれます。これらの属性は、クエリ時にスパンデータをファセットまたはフィルタリングするために使用できるディメンションに直接マップされます。 OpenTelemetryスパンメタデータ（たとえば、 name 、 kind 、およびtrace_id ）も、NewRelicスパンのディメンションに直接マップされます。現時点では、NewRelicはスパンリンクをサポートしていません。
詳細は、 ベストプラクティス ガイドの「トレース」セクションをご覧ください。
機能 | サポート対象 |
|---|---|
✅ | |
❌ | |
✅（ネストされておらず、要素が64以下である必要があります） |
指標
New Relic では、メトリックシグナルの OTLP インジェストをサポートしています。上流の仕様の成熟度は experimental であることに注意してください。私たちは、アップストリームの変更に対応する予定です。
ここでは、私たちがサポートしているOpenTelemetryのデータタイプとその関連マッピングを紹介します。詳細は、 ベストプラクティス ガイドの「Metrics」のセクションをご覧ください。
メトリックタイプ | サポート対象 |
|---|---|
デルタ・サムズ | ✅ |
積算金額 | ✅ |
ゲージ | ✅ |
デルタ・ヒストグラム | ✅ |
概要 | ✅ |
累積ヒストグラム | ❌ |
模範例 | ❌ |
✅（ネストされておらず、要素が64以下である必要があります） |
ログ
New Relic は、ログ信号の OTLP 取り込みのサポートを提供します。上流仕様の成熟度は安定しています。
OpenTelemetryログは、NewRelicのログと互換性があります。 OpenTelemetryログには、オプションで、クエリでログデータをファセットまたはフィルタリングするために使用できるディメンションに直接マップする属性（名前と値のペア）とリソース属性が含まれます。 OpenTelemetryのログメタデータ（たとえば、 name 、 severity_text 、およびtrace_id ）も、NewRelicのログ管理機能のディメンションに直接マップされます。現在、すべてのOpenTelemetryログメッセージタイプをサポートしています。
詳細については、ベストプラクティスガイドのログ情報を参照してください。
機能 | サポート対象 | 説明 |
|---|---|---|
ログ・レコード・ボディ | ✅ | サポートされるタイプ：string, boolean, int, double, bytes |
ログレコードの属性 | ✅ | サポートされるタイプ：string, boolean, int, double, bytes |
LogRecordのフィールド | ✅ | 例：name, severity_text, trace_id |
配列メッセージ（同種） | ✅（ネストされておらず、要素が64以下である必要があります） | |
✅（ネストされておらず、要素が64以下である必要があります） |
次のステップ
OpenTelemetry quick start に従って操作を開始してください。
また、New Relic にエクスポートしたデータを最大限に活用するために、 ベストプラクティス ガイドを確認してください。