ハンズオン: New RelicでOpenTelemetryコミュニティデモアプリを実行する

以前、実践的なOpenTelemetry：インストゥルメントされたアプリで問題のトラブルシューティングを行うというブログにおいて、KubernetesにOpenTelemetryコミュニティデモアプリケーションをデプロイする方法と、ワークロードやErrors Inboxなどの機能を使用して、New Relicプラットフォームを利用してOpenTelemetryプロトコル（OTLP）データの問題をトラブルシューティングする方法について説明しました。

このブログ記事では、フォークしたコミュニティデモアプリに変更を加え、機能フラグのデモシナリオ、それを有効にする方法、New Relicでそのデータをナビゲートする方法、Helmチャートを使用してOpenTelemetryコレクターでKubernetesクラスタを監視する方法、そして最後にフォークで現在行われている作業についてハンズオン形式で紹介・解説します。ぜひお手元に環境を作って体感してみてください。

デモアプリのNew Relicフォークに加えた変更内容

New Relicはデモアプリのフォークに次の変更を加えました。

• .envファイルにはNew Relic固有の環境変数が含まれているため、データをアカウントにすぐに送信できます。
• Helmユーザーは、OpenTelemetryの代わりに、Python APM用のNew Relicエージェントでインストゥルメントされたバージョンのrecommendationsserviceを有効にすることができます。
• デモに含まれるいくつかの「機能フラグ」を操作する方法を説明するチュートリアルセクションを追加しました（機能フラグの詳細については、この記事の次のセクションで説明します）。

機能フラグのデモシナリオ

弊社のデモアプリの開発と保守を行うチームは、さまざまな状況をシミュレートするために、機能フラグを介して有効にできる多数のデモシナリオを追加しました。これらのシナリオには、特定の呼び出しでのエラー、メモリリーク、CPU負荷の上昇などが含まれます。flagdと呼ばれる機能フラグサービスがフラグを管理します。後ほど説明するように、フラグを有効にすることは設定ファイルの値を更新するのと同じくらい簡単です。

このセクションでは、Helmチャートを使用してアプリをローカルにデプロイし、ウェブストアとロードジェネレーターのUIを表示し、デモシナリオの機能フラグの1つを有効にして、New Relicでデータをナビゲートする方法について説明します。

これで、OpenTelemetry Astronomy Shop DemoアプリケーションのNew Relicフォークを独自の環境にデプロイする準備が整いました。開始するには、以下の手順に従ってください。

デモアプリをローカルで起動するには、次の要件を満たす必要があります。

• Kubernetes 1.23以降のクラスタ（既存のクラスタ、またはminikubeを使用して新しいクラスタを作成することも可能）
• Helm 3.9以降（Helmのインストール手順を参照）
• kubectlがインストールされている（kubectl –helpを実行してテストしてください）
• New Relicアカウント（必要な場合は、こちらからサインアップしてください。永久に無料です）

ステップ1：Helmを使用してアプリをデプロイする

1. まず、フォークのコピーをローカルマシンにクローンし、最上位ディレクトリに移動します。

注：既存のクラスタにアプリをデプロイする場合は、「helm」ディレクトリに移動し、values.yamlファイルを開いてクラスタの名前を更新します（次の画像を参照）。それ以外の場合は、次の手順に進みます。

2. 次に、OpenTelemetry Helmチャートを追加します。

3. アカウントからNew Relicライセンスキー（キータイプ「INGEST – LICENSE」を探します）を取得し、環境変数としてエクスポートします（「<NEW_RELIC_LICENSE_KEY> 」を実際のライセンスキーに置き換えてください）。

4. このステップでは、ネームスペース「otel-demo」を作成し、そのネームスペースのNew Relicライセンスキーを含むKubernetesシークレットを設定します。

次のセクションで機能フラグを有効にするときに問題が発生しないように、ネームスペース「otel-demo」を使用することをお勧めします。これは、values.yamlファイルにハードコードされているためです。別のネームスペースを使用する場合は、values.yamlファイル内のインスタンスもすべて更新する必要があります。次のスクリーンショットは、OpenTelemetryリソース属性として設定されている場所を示しています。

5. 最後に、リリース名「newrelic-otel」で Helmチャートをインストールし、指定されたvalues.yamlを渡します（設定変更時にリリース名を変更すると、そのリリースで実行中のインスタンスを確認できます）。

• 米国ベースのアカウントの場合：

• EUベースのアカウントの場合：

ステップ2：フロントエンドとロードジェネレーターのUIを表示する

1. アプリケーションがデプロイされると、ターミナルに次のように表示されます。新しいターミナル/CLIウィンドウで、表示された「kubectl」コマンドをコピーして実行し、ウェブストア（フロントエンド）とロードジェネレーターのUIサービスをフロントエンドプロキシに転送します（GrafanaとJaegerのURLも表示されますが、現時点ではこれらのURLは機能しません。動作させるには追加の設定が必要ですが本ポストの趣旨から外れるため割愛します）。

2. エラーが発生した場合は、ポートを再度転送する前にポッドが実行中であることを確認してください。

3. 数分後には、前のスクリーンショットに表示されているURLを介してデモアプリのフロントエンドにアクセスできるようになります。一般的なeコマースサイトと同様にサイト内をクリックすることができます。また、デモアプリにはユーザートラフィックをシミュレートするロードジェネレーターが付属しているため、継続してアクセスが行われるようになっています。

4. ロードジェネレーターは、Python負荷テストフレームワークのLocustに基づいており、フロントエンドからのユーザーリクエストをシミュレートします。ロードジェネレーターUIにアクセスすると、失敗したリクエストや平均期間など、シミュレートされたトラフィックに関するデータを表示できます。

ステップ3：New Relicでデモアプリのデータを表示する

New Relicアカウントに移動し、左側のメニューですべてのエンティティをクリックして、 すべて表示を選択します。

開いたビューには、OpenTelemetryでインストゥルメントされたすべてのサービスのリストが表示され、レスポンスタイム、スループット、エラー率のメトリクスも表示されます。リストをスクロールしていくと、エラー率が一般的に0%に近いことがわかります。機能フラグを有効にすると、影響を受けるサービスのエラー率メトリクスが変更されます。これについては、次のセクションで詳しく説明します。

「エンティティ」ビューでは、loadgenerator、frontend-web、kafkaの各サービスのレスポンスタイム、スループット、エラー率のメトリクスが表示されていないことに気付くと思います。これは、この画面を生成するために実行されているクエリが、特定のサービスやエンティティの「サーバー」または「コンシューマー」というラベルが付けられた特定のスパンの平均応答時間をもとに生成しているのですが、これらのサービスはこのパラメーターに適合するスパンを生成してないためです。サービスをクリックすると、データが報告されていないのではなく、テレメトリーが実際に収集されていることを確認できます。今回のシナリオには直接関係のない部分なので、気にしなくて大丈夫です。

ステップ4：デモシナリオの機能フラグを有効にする

機能フラグを有効にして、含まれているシナリオの1つをシミュレートするのは簡単です。「src/flagd/demo.flagd.json」ファイルの「defaultVariant」の値を「on」に編集します。この手順では、viを使用してターミナルでファイルを直接編集します。

このセクションでは、productCatalogFailure機能フラグを有効にします。これにより、製品ID「OLJCESPC7Z」の「GetProduct」リクエストに対してエラーが生成されます。

1. まず、flagdサービスのconfigmapを表示します。

• 「newrelic-otel」以外のリリース名を使用した場合は、使用したリリース名に置き換えます。

• 問題が発生した場合は、configmap名が間違っている可能性があります。次のコマンドを使用すると、flagdのconfigmapの正しい名前を見つけることができます。末尾に「-flagd-config」が追加された結果を探します。

2. flagdのconfigmapを表示できるようになったら、編集してみましょう。

3. ターミナルでファイルが開いたら、viを使用してファイルを編集します。まず、文字iを入力します。これにより、「挿入」モードが有効になり、ファイルを変更できるようになります。ファイル内を移動するには矢印キーを使用します。次のスクリーンショットに示すように正しい行に到達したら、offをonに置き換え、escキーを押して「挿入」モードを終了し、:wqと入力しEnterキーを押してファイルを保存して終了します。

4. 変更を適用するには、flagdサービスを再起動します。

ポッドを確認するには、kubectl get pods -n otel-demoを使用します。kubectl get configmap newrelic-otel-flagd-config -n otel-demo -o yamlを使用して、設定変更が取得されたことを確認することもできます。

問題が発生した場合には、次の基本的なトラブルシューティング手順を実行してください。

• 特定のポッドのログを表示する：kubectl logs <pod-name> -c flagd -n otel-demo
• 問題のあるポッドのデバッグコンテナを開いて、ファイルシステムを調べる：kubectl debug -it <pod-name> -n otel-demo --image=busybox --target=flagd -- /bin/sh
  • 探しているディレクトリが見つからない場合は、ディレクトリまたは設定ファイルがポッド内に正しくマウントまたは作成されていない可能性があります。

ステップ5：New Relicで機能フラグデータを表示する

数分後、OpenTelemetryサービスのエンティティビューに移動すると、いくつかのサービスのエラー率メトリクスの変化を確認できます。エラー率（%）列をクリックして、サービスをエラー率で並べ替えます。時間の経過とともにエラー率が増加し、次のスクリーンショットに示されている値付近で横ばいになることがわかります。

何が起こっているのか調べてみましょう。productcatalogserviceをクリックし、TRIAGEメニューからErrors Inboxに移動します。「Error: ProductCatalogService Fail Feature Flag Enabled」というメッセージを含むエラーグループが表示されます。

有効にした機能フラグにより、製品ID「OLJCESPC7Z」の「GetProduct」リクエストに対してproductcatalogserviceでエラーが生成されてます。エラーグループをクリックして下にスクロールすると、製品IDがこれらのエラートレースの属性として収集されていることがわかります。

このビューでは、エラートレースの例に簡単に移動できます。一番下までスクロールし、属性「trace.id」の値として提供されているリンクされたトレースをクリックします。

表示されるビューには、接続されたサービスのマップを含む、このエラーグループのトレースの全体が表示されます。次のスクリーンショットで強調表示されているドロップダウンメニューから、エラー範囲のいずれかをクリックして、さらに詳しく見てみましょう。

フロントエンドサービスはproductcatalogserviceを呼び出しますが、製品ID「OLJCESPC7Z」の「GetProduct」リクエストはエラーを返すため、フロントエンドサービスに対して500が返されます。このリンクからソースコードを確認できます。

checkoutserviceについてはどうでしょうか。そのサービスに移動して、 Errors inboxページをクリックすると、次のエラーグループが表示されます。

エラーグループをクリックすると、checkoutserviceがproductcatalogserviceを呼び出し、製品 ID「OLJCESPC7Z」にエラーが生成されたために「PlaceOrder」呼び出しが失敗したことがわかります。

このデモシナリオは、1つのアプリのエラーが複数のサービスと複数のエンドポイントにどのような影響を与えるかを示す良い例です。これは人為的なエラーであるため、特に有用なトラブルシューティング情報は多く収集されませんが、カスタムインストゥルメンテーションを追加して、エラーログなどのより詳細なレベルを収集できます。

OpenTelemetryを使用してKubernetesクラスタを監視する

このセクションでは、nr-k8s-otel-collector Helmチャートを使用して、OpenTelemetryコレクターでクラスタを監視する方法について説明します。この機能はまだ開発中であり、プレビュープログラムの一部として提供されていることに注意してください（詳細については、プレリリースポリシーを参照してください）。代わりにNew Relic Kubernetesインテグレーションを使用する場合は、このブログ記事を参照してください。

このHelmチャートでは、OpenTelemetryインストゥルメンテーションと、プロバイダーに依存しないように設計されたNew Relic Kubernetes UIを使用してクラスターを監視できます。コレクターに統合されたKubernetesコンポーネントによって生成されたデータは、Kubernetesナビゲーター、概要ダッシュボード、 Kubernetes APMの概要ページなど、New Relicのすぐに使用できるエクスペリエンスを自動的に強化します。

1. コードエディターで、「helm」ディレクトリに移動し、nr-k8s-values.yamlという名前の新しいファイルを作成します。
2. このサンプルvalues.yamlファイルの生の内容をコピーして、新しく作成したnr-k8s-values.yamlファイルに貼り付けます。
3. ファイルに次の変更を加えます。
   1. 23行目のクラスタの名前を更新します。
   2. ライセンスキーを25行目に追加します（またはカスタムシークレットを作成します）。
   3. ファイルを保存します。
4. チャートをインストールします。

数分後、New RelicアカウントでKubernetesクラスタに関する情報を表示できるようになります。前の手順でクラスタ名を変更しなかった場合は、「opentelemetry-demo」という名前のクラスタが表示され、ネームスペース「otel-demo」を持つアプリケーションポッドを表示できます。自身のアカウントでKubernetesに移動し、クラスタを選択してデモアプリポッドを表示します。

Kubernetesインテグレーションに精通している場合は、OpenTelemetryによってモニターされるクラスタのメトリクス名が、Kubernetesインテグレーションによってモニターされるクラスタのメトリクス名と異なることに気付くでしょう。これは、それらのメトリクス名が主にkube-state-metricsから取得されるためです。メトリクスのリストを取得するには、「データのクエリ」に移動し、次のクエリを実行します（必要に応じてクラスタ名を置き換えます）。

現在のデフォルトのコレクターはNRDOT（New Relic Distribution of OpenTelemetry）ですが、他のコレクターディストリビューションを使用することもできます。Kubernetesのキュレートされたエクスペリエンスを適切に有効にするには、次の項目を含めることをお勧めします。

• デプロイメントコレクターの設定
• DaemonSetコレクターの設定

今後のフォークアプリの追加シナリオ

デモアプリが活発に開発されているのと同様に、当社はフォークの開発とメンテナンスも積極的に行っています。当社が現在取り組んでいること、または近い将来に計画していることをいくつかご紹介します。

• 残りのデモシナリオ機能フラグはテスト中です
• 各デモシナリオのトラブルシューティングチュートリアル
• Dockerクイックスタートメソッドを使用するときに、recommendationserviceのNew Relicインストゥルメンテーションを有効にする機能フラグを追加します
• フォークのロードマップ

ご提案がある場合、またはフォークの実行中に問題が発生した場合は、リポジトリで問題を開いてお知らせください。