New Relic で OpenTelemetry データを最大限に活用する方法

概要

先日 (2025/07), New Relic の APM + OpenTelemetry Convergence の一般提供開始を発表しました。これにより、New Relic プラットフォームはOpenTelemetry (OTel) データに対し、高水準のオブザーバビリティ体験を提供できるようになりました。

OTel 自体はデータ収集フレームワークで、オブザーバビリティバックエンドではないため、計装は導入プロセスの最初のステップに過ぎません。このプロジェクトでは、テレメトリーをどのように生成するかという課題に焦点を当てており、何 に活用するかには焦点を当てていません。OTel によって生成されるデータから実用的な洞察を得るには、これらのデータを取り込み、保存し、相関付けや可視化ができる、高度でスケーラブル、かつ高度な判断力を備えたプラットフォームが必要となります。

New Relic ならそれが実現できます。このブログ記事では、OpenTelemetry コミュニティが公開しているデモアプリ「Astroshop」を New Relic が独自にカスタマイズしたフォーク版 を使用して、New Relic が OTel データからどのように価値を引き出すかをご紹介します。

Astroshop の導入

Astroshop は、OTel コミュニティが複数の言語で構築したマイクロサービスベースの分散システムで、実際の環境に近い形で OTel の実装をデモンストレーションすることができます。New Relic はこのデモアプリケーションのフォーク版を保守しており、計装と分析 (洞察の獲得) の間のギャップを埋めるために、事前に設定を施しています。これにより、セットアップが効率化され、ほぼ即座に New Relic アカウントへデータを送信することができます。

Astroshop には、有効化または無効化できる 機能フラグ も用意されており、実際のソフトウェアで発生するさまざまな問題をシミュレートできます。このブログ記事で使用している例では、productCatalogFailure という機能フラグが有効になっており、特定の 製品ID に対する GetProduct リクエストでエラーが発生するようになっています。

デモアプリケーションの導入は簡単です。まず、お使いの環境が 前提条件 を満たしていることを確認し、フォーク版をクローン します。その後、Kubernetes または Docker を使用して Astroshop をローカル環境に導入してください。次に、導入状況の検証 を行い、最後にデータを確認してみましょう。

New Relic UI の有効化

Astroshop の各種マイクロサービスがデータのレポートを開始すると、エンティティビューでそれぞれのデータを確認できるようになります (デプロイ後、エンティティが表示されるまで数分かかる場合があります)。New Relic アカウントで、APM & Services に移動し、Services - OpenTelemetry をクリックして、「View all（すべて表示）」をクリックします。

注意: すべてのサービスがレスポンスタイム、スループット、エラー率のデータを報告しているわけではないことがわかります。これには次の2つの理由があります。

• APM + OTel Convergence はメトリクスデータに依存しているが、すべてのサービスがレポートしているわけではない
• この OTel プロジェクトは、言語 SDK や API ごとに実装レベルが異なるため、一部のサービスではメトリクスの計装に影響が出ている

APM + OTel UI Convergence は、高水準の APM 体験を OTel データソースにももたらすよう設計されています。その中心は、高度なデータ正規化プロセスです。標準的な OTel データが New Relic の OTLP エンドポイントに送信されると、プラットフォームによって自動的に正規化されたコピーが作成され、New Relic の堅牢な APM セマンティック規約に準拠するようになります。このプロセスは完全に非破壊的です。元の OTel ソースデータは保持され、クエリで参照できるため、データの完全な完全性が確保されます。

UI ではエンティティに紐づいた情報を正確に認識し、関連付けされた状態で表示されます。通常、受信データは膨大で整理されていません、しかし OTel で定義され New Relic プラットフォームによって認識されるセマンティック規約が順守されることによって、関連性が認識でき、整理された UI 表示を実現しています。New Relic では、テレメトリーデータに付加された特定のリソース属性を利用してエンティティを合成します。エンティティの合成とは、UI 上でサービス、ホスト、データベースなどのエンティティを識別・分類・作成するプロセスです。

下記の表は、主要な属性と、それにより利用できる New Relic の各機能の詳細です。

APM + OTel Convergence UI の探索

基本的なバックエンドでの仕組みが理解できたところで、Astroshop のデータを詳しく見てみましょう。この例では、product-catalog サービスを選択します。エンティティをクリックすると、そのエンティティの Summary ビューが表示されます。

少し下にスクロールすると "Errors" チャートと "Transactions" リストが表示されます。「grpc/oteldemo.ProductCatalogService.GetProduct」というトランザクションのエラー率が4%を超えていることがわかります。

GetProduct トランザクションの「View details」ボタンをクリックすると、新しい Transaction 360 ビューが表示されます。これは、従来の単一トレース分析が進化したもので、トランザクションエコシステム全体の動的なビューを提供します。この機能を利用することで、選択した時間枠内に発生している重要なアラートや最新の導入バージョンなど、アプリケーションとインフラのパフォーマンス情報を一目で確認できます。これらのコンテキストによって、発生した問題と、デプロイ作業やホスト、サービスを直接関連づけて理解することができます。

このビューには、トレースデータがサービス内をどのように流れるかを確認できる新しい動的フローマップが含まれています。トレースデータを活用して、上流・下流のエンティティにわたるパフォーマンスの変化を、他の時間帯との比較して確認することができます。

ビューをスクロールすると、トレースで関連するサービスやトランザクションが Participating APM services および Participating transactions で確認できます。

GetProduct トランザクションが問題の原因として示されているため、grpc/oteldemo.ProductCatalogService.GetProduct をクリックしてさらに詳細を確認しましょう。新しい Transaction 360 ビューが開き、画面上部に複数のタブが表示されます。

「See errors」タブを選択すると、このエラーの発生回数など、さらに詳しい情報が表示されます。前述の「Astroshop の導入」セクションで、このブログ記事の例では productCatalogFailure 機能フラグが有効になっていることを記載しました。このエラーグループのメッセージは、この機能フラグが有効になっていることを示す「Error: Product Catalog Fail Feature Enabled」となっており、まさに予想通りの内容です。

注意: エラーが明らかに存在しているにもかかわらず、エラー率チャートにデータが表示されないのはなぜかと思うかもしれません。それは、このチャートでは HTTP ステータスが 500 以下の応答のみをクエリ対象としているためです。（任意のチャートの「…」をクリックすると、いくつかのオプションを示すメニューが表示されます。「View query」を選択すると、そのチャートのデータ生成に使用されている正確なクエリを確認できます。）

この詳細ビューを終了し、Summary ページからアクセスした最初の Transaction 360 ビューに戻った後、ドロップダウン矢印をクリックして「サポート対象インフラストラクチャエンティティ」を展開し、影響の有無を確認できます。