OpenTelemetryとNew Relic Oneでアプリケーションのトラブルシューティングをより迅速に

OpenTelemetryとNew Relic Oneを始める

OpenTelemetryを始めるには、お客様のアプリケーションとサービスでお試しいただくのが一番良いでしょう。そうすることで、インストルメンテーションの価値を直ちに活用し、すでに自分が使い慣れたインストルメントサービスも実行できます。

それが難しい場合は、当社と提携するOnline Boutique cloud-native microservicesをデモアプリケーションとして使用するか、またはNew Relic’s OpenTelemetry examplesのいずれかをお使いいただけます。

データを取り込む

OpenTelemetry SDK/APIでお客様のサービスをインストルメント化した後、ネイティブのOTLPエンドポイントを使用してNew Relic Oneにデータを取り込むことができます。OTLPエンドポイントでのデータの取り込みに必要なのは、わずか数ステップです。

1. お客様のOTLP（推奨）、または対応するNew RelicのOTLPエンドポイント（otlp.nr-data.net:4317またはhttps://otlp.nr-data.net:4318）のOTLP/HTTPエクスポーターを選択します。

2. ヘッダーの属性とAPIキーを追加します。値は、データを送信するNew Relicアカウントのアカウントライセンスキーです。

以下の例は、OpenTelemetryコレクターを使用した場合にotel-config.yamファイルでどのように表示されるかを示しています。

代わりに、OTLP/HTTPエクスポーターを使用することもできます。

詳細については、OpenTelemetry quick start のドキュメントをご参照ください。

New Relic OneでOpenTelemetryデータを表示する

アプリケーションからNew Relic OneへOpenTelemetryデータ送信が開始され、データを動的なUIで直ちに確認できるようになります。UIでは、OpenTelemetryの属性（service.version、http.status_code、thread.nameなど）のあらゆるステップを使用して、レスポンスタイム、エラーレート、スループットなどのメトリクスのグループ化、ファセット、フィルタリングを実行します。これには、データベース、トランザクション、エラー、分散トレーシングから厳選して収集されたビューも含まれており、トラブルシューティングに役立ちます。以下に、いくつかのシナリオの概要を示します（マイクロサービスのデモアプリとともに提示されます）。精選されたOpenTelemetryエクスペリエンスは、すべてのエンジニアにとって非常に役立つものです。

環境の日常的なモニタリング

Ops/DevOpsのエンジニアは、定期的に環境全体で何が起こっているのか理解する必要があります。New Relic Explorerは、設定不要で、すべてのOpenTelemetryデータを一箇所に集約します。すべてのアカウントで、エステート内の重大な変更が強調されるため、事前に設定された閾値やダッシュボードに頼ることなく、発生しつつある問題をリアルタイムで発見できます。環境全体にわたる変化や健全性に対する迅速な洞察を得て、問題のすばやい分析、理解、そして解決を導くことができます。New Relic Explorerには、エステート全体の可視化と調査、および理解を可能にするいくつかのアプローチがあります。

• New Relic Lookoutは、すべてのアカウントにわたるリアルタイム表示を提供し、全テレメトリにおける変化を、理解しやすくアクセス可能な、設定不要のユーザーエクスペリエンスとして強調します。直感的なサークル型のビジュアルでは、直近の変化の深刻度が色で表現され、変化の規模がサイズで表現され、最も注目すべき内容はどれであるか示されます。
• New Relic Navigatorは、タグに基づく特定のエンティティグループに焦点をあて、問題を示しているサービスの詳細をすばやく掘り下げます。そのため、すべてのアカウントにわたるOpenTelemetryサービスの健全性について迅速に把握することができます。以下のスクリーンショットは、複数のOpenTelemetryサービスがアラートを発している様子を示しています。

ただし、この例からは、アラートを発するこれらのサービスがどのように関連しているかは読み取れません。New Relicエクスプローラーはシステムの俯瞰的な視点を提供しますが、分散アーキテクチャー内のサービスとその依存関係を可視化するには、どうすれば良いでしょうか？

そこでAutomapが登場します。これにより、パフォーマンス上の問題を迅速に特定できるようになります。Automapと関連するエンティティ ウィジェットを使用することで、他のサービスの健全性の問題を特定し、それらのサービスがどのように自身のインフラストラクチャのコンポーネントと関連しているか理解できます。

以下のスクリーンショットのFrontEndサービスのAutoMapでは、AdServiceを含む5つの他のサービスとの依存関係が示されています。AutoMap は、根本的な原因を突き止めるための道筋を示します。

エラー時のトラブルシューティング

また、OpenTelemetryサービスで設定した閾値に基づいてエラーを発行するアラートを作成し、トラブルシューティングを行うことも可能です。これらのOpenTelemetryサービスのステータスカラーは、New Relic Explorer またはactivity streamに表示され、クリティカル、または警告を要する違反の詳細を確認することもできます。

上記のスクリーンショットでは、アクティビティ ストリームから、AdServiceがクリティカルな違反を示し、エラーレートが閾値を超えているのがわかります。では、エラーの発生しているトレースを確認してみましょう。

エラートレースのひとつをクリックすると、上記で示されているように、画面上部にtrace mapが表示されます。Trace mapでは、個別のスパンと併せ、特定のリクエスト（トレース）の実施に関わるすべての異なるサービスを可視化できます。各エンティティにカーソルを合わせると豊富なコンテキストが表示され、トレースのコンテキストから逸脱せずに、エンティティに特化した詳細を確認することができます。加えて、エラーの根本原因を探るのに使用できる、OpenTelemetryインストルメンテーションから生成されるスタックトレースなどのエラー詳細を確認することもできます。エラー詳細は、OpenTelemetryの仕様に従って取り込まれたスパンのイベントに基づいて顕在化されます。以下のスクリーンショットでは、追加のエラー詳細が赤いボックス内に表示されています。

トレーシングエラーに加え、スパンイベントとしてログを取り込んだり、サポートされているログフォワーダーを使用してアプリケーションログをNew Relic Oneに送信し、自身のサービスのパフォーマンスを関連ログと相関付けることができます。以下に示す通り、Logs in context により、調査しているトレースと関連する特定のログ行に直接移動して、問題のトラブルシューティングを迅速に行えるようになりました。

進化し続けるNew RelicのOpenTelemetryユーザーインタフェース

OpenTelemetryプロジェクトの成熟に伴い、New Relic OneによるOpenTelemetryのサポートも継続的に進化しています。私たちが目指すのは、インストルメンテーションのソースが何であれ、エンジニアがNew Relic Oneの能力を十全に活用することで、問題の根本原因を特定するのに必要なデータをすばやく発見し、アプリケーションとサービスのパフォーマンスを最適化できるようにすることです。

New Relic OneでのOpenTelemetryの使用に関してのフィードバックは、New Relic Oneの上部ナビゲーションにある「フィードバック」ボタンを選択して、貴重なご意見をお送りください。

まだお試しでなければ、いますぐ無料アカウントをご登録いただき、お客様のNew Relic OneアカウントへのOpenTelemetry送信を開始しましょう。毎月100GBのデータを無料で使用できます。