OpenTelemetryは可観測性のオープンな標準です。New Relicはこの新しいオープンな標準に注力しており、OpenTelemetryネイティブな形式OTLPでのテレメトリーデータの取り込みに対応しています。では、実際にOpenTelemetryを使ってNew Relicにテレメトリーデータを送信し、活用するには何がまず必要なのか実際に試してみましょう。
OpenTelemetryとは何なのか詳しく知りたい方は、「OpenTelemetryを理解する」シリーズの抄訳記事をご覧ください。
ライセンスキーを準備する
事前準備としては、ライセンスキーを用意しておきます。New Relicにサインアップすると、そのアカウントに対してデフォルトでライセンスキーが用意されているため、それをメモしておくだけでもOKです。
ただ、ライセンスキーを誤ってGitHubに公開するなどしたときのために、別途ライセンスキーを作成して使うことをおすすめします。新規に作成する方法は以前のブログ「データIngest用のライセンスキーを新規に作成する」を参照してください。
アプリケーションから直接New Relicに送信する場合
それでは、早速アプリケーションをOpenTelemetryで計測してみましょう。そのためには、まずアプリケーションを計装（計測コードを実装）する必要があります。OpenTelemetryではアプリケーションの言語ごとに計装のためのライブラリが用意されていますが、設定の概念はほぼ同じであるためそこを説明します。詳細な手順はOpenTelemetryのInstrumentationのページから自分の使う言語のページを参照してください。
計装コードを設定する中で、Exporterを設定する手順が出てくるはずです。例えばConsole（標準出力）へ出力するExporterをまず使う方法が紹介されている言語もあります。その場合、OpenTelemetryで計測されたテレメトリーデータが標準出力に出力されるので動作確認をすることができます。
まず必要な設定は、このExporterにOTLPフォーマットで送信するExporterを設定することです。OTLPとはOpenTelemetry Protocolのことで、OpenTelemetryが定めているデータフォーマットです。New RelicはOTLPでのデータ受信をサポートしているため、OTLPで送信するExporterを設定します。
その次に、OTLPフォーマットのExporterで送信先と誰が送信しているかを識別する認証情報を設定します。また、オプションですが、サービス名(Service Name)を設定することをおすすめします。送信先はNew Relicが提供しているエンドポイントを指定します。こちらのドキュメントにある通り、New Relicのデータ保存先がUSかEUかで異なります。データ保存先はNew Relicのアカウント作成時に指定したものであり、デフォルトはUSです。アプリケーションが動いている場所とは関係ないためご注意ください。認証情報は、HTTPヘッダーとして設定します。ドキュメントの同じ場所に記載がありますが、ヘッダーのキーの値はapi-keyで、値は先程メモしたライセンスキーを指定します。サービス名の設定方法は、各言語ごとのライブラリを確認してください。
図に示すと下のようになります。OTLP形式をサポートしているオブザーバビリティバックエンドであれば送信先と認証情報の設定を変えるだけで送信することができます。
以上の設定を完了すると、OpenTelemetryで計測したデータがNew Relicに送信され、UIで確認できます。New RelicではOTLP形式で送信されたデータに対して、APM Agentで送信した場合と同様にAPMのUIで確認できるようになります。このときの名前には、Service Nameに設定した名前が使われます。
選択すると、APMと同じようなUIが表示されます。
CollectorをセットアップしてNew Relicに送信する場合
先程のアプリケーションに計装したしたOpenTelemetryから直接New Relicに送信する方法はシンプルですが実運用上、例えば次のような問題があります。
- テレメトリーデータに追加のタグやインフラストラクチャの環境情報を付加したい場合、その処理が（直接は関係ない）アプリケーションに記述されてしまう
- バッチ処理、送信エラー時のリトライや暗号化処理などがアプリケーションプロセス内で処理されるため、アプリケーション本体に負荷がかからないように注意深く実装する必要がある
New RelicのAPM AgentではInfrastructure Agentと連携することや注意深く設計・実装することでこの問題に対応していますが、非常に複雑な実装となります。OpenTelemetryではこのような処理をCollectorとして分離する方法を提供しています。そしてCollectorは次の2通りの方法で展開できるとドキュメントに記載されています。
- Agent方式: アプリケーションと同じホスト（サイドカーなども含む）で実行する方法
- Gateway方式: クラスター、データセンター、リージョンなどの単位で独立したサービスとして実行する方法
両者は排他的な関係ではなく併用することができます。Agent方式だけを採用する場合はこの図のようにAgentからNew Relicへテレメトリーデータを送信できます。
Gateway方式と併用する場合、StandaloneなCollectorが展開されます。Gateway方式では、複数のアプリケーションからのテレメトリーデータをまとめて処理できるため、分散トレーシングでtail-basedなサンプリングが可能になります。（tail-basedなサンプリングのメリットについては以前のブログ「分散トレースとサンプリングについて知っておくべきこと」を読んでみてください）また、アプリケーションと独立して動作することから、コレクターの設定変更をアプリケーションのライフサイクルとは分離することができます。バックエンドに送信するデータの上限を設定するサンプリングも可能になります。
このようなCollectorをすばやくセットアップするためにOpenTelemetryからotel/opentelemetry-collectorというコンテナイメージが提供されています。先程から何度か紹介しているNew Relicのドキュメントでは、このコンテナイメージを使ったコレクターの展開方法を紹介しています。このドキュメントに従ってCollectorを起動した場合、コンテナを起動したホストの4317ポートでOTLPフォーマットのデータを受信し、受信したテレメトリーデータをNew Relicのエンドポイントに送信するコレクターが起動します。したがって、アプリケーション側のExporterでは送信先をhttp://<コンテナホストのIP>:4317 に設定します。そして認証情報はコレクターが設定するため、アプリケーションのExporterでのヘッダーの設定を削除しても動くようになります。
このCollectorのコンテナイメージは設定ファイルを追加することでさまざまな機能が利用できるようになります。Receiverを追加することで、Jaegarで計装しているアプリケーションからのテレメトリーデータを受信しOTLPフォーマットで送信できます。Exporterを追加し、New Relic以外のバックエンドにも送信できます。Processorを追加し、カスタムタグの追加やサンプリングを行えます。またさらに機能を追加をすることも可能なつくりになっています。詳細はOpenTelemetryのドキュメントを参照してください。
New RelicはOTLP形式を受信できます。ぜひOpenTelemetryを検証するときのバックエンドとして、すぐに利用できるSaaSとしてご活用ください。
次のステップ
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
