OpenTelemetry Collector監視

専用のAPM UIエクスペリエンスを使用して、 OpenTelemetry コレクターの健康状態とパフォーマンスを監視します。コレクターに障害が発生したり誤動作したりすると、観察データのブラックアウト、永久的なデータ損失、またはインサイトの歪みが発生する可能性があります。 そのため、コレクターが実行するストリーミング作業に合わせて調整されたAPMエクスペリエンスであるCollectorオブザーバビリティを構築しました。 コレクターの内部テレメトリーを利用して、コレクターの各コンポーネントのパフォーマンスを一目で確認できるため、オブザーバビリティ パイプラインに影響を与える前に問題を特定できます。

コレクター監視を設定する

コレクターの内部テレメトリーを有効にする

デフォルトでは、コレクターは内部テレメトリーを出力しないため、最初にそれを有効にする必要があります。

設定ファイルをダウンロードする

$
curl 'https://raw.githubusercontent.com/newrelic/nrdot-collector-releases/refs/heads/main/examples/internal-telemetry-config.yaml' \
>
  --silent --output internal-telemetry-config.yaml

環境変数の設定

• INTERNAL_TELEMETRY_NEW_RELIC_LICENSE_KEY: 内部テレメトリーの送信先アカウントのライセンスキーを取り込みます。 このキーは、コレクターが New Relic に通常のデータを送信するために使用するキー (以下の例ではNEW_RELIC_LICENSE_KEYとは異なる場合があります。
• INTERNAL_TELEMETRY_SERVICE_NAME: デフォルトはotel-collectorで、New Relic のエンティティ名を決定します
• INTERNAL_TELEMETRY_OTLP_ENDPOINT: デフォルトは米国https://otlp.nr-data.netです。EUにお住まいの場合は、これを https://otlp.eu01.nr-data.net

マージされた設定でコレクターを実行する

コンポーネントとパイプラインの通常の設定 (次の例では--config=/etc/nrdot-collector/config.yaml) に加えて、両方の設定をマージする 2 番目の--config引数を追加します。

$
docker run \
>
  -e INTERNAL_TELEMETRY_NEW_RELIC_LICENSE_KEY='...' \
>
  -e NEW_RELIC_LICENSE_KEY='...' \
>
  -e INTERNAL_TELEMETRY_SERVICE_NAME='demo-collector' \
>
  -v './internal-telemetry-config.yaml:/etc/nrdot-collector/config-internal.yaml' \
>
  newrelic/nrdot-collector:1.10.0 --config=/etc/nrdot-collector/config.yaml \
>
  --config='/etc/nrdot-collector/config-internal.yaml'

代替案（本番環境では推奨されません）

信頼性の理由からこれはお勧めしませんが、テスト目的で設定を直接参照することもできます。その場合、コレクターは起動時にそれを取得します。

$
docker run \
>
  -e INTERNAL_TELEMETRY_NEW_RELIC_LICENSE_KEY='...' \
>
  -e NEW_RELIC_LICENSE_KEY='...' \
>
  -e INTERNAL_TELEMETRY_SERVICE_NAME='demo-collector' \
>
  newrelic/nrdot-collector:1.10.0 --config=/etc/nrdot-collector/config.yaml \
>
  --config='https://raw.githubusercontent.com/newrelic/nrdot-collector-releases/refs/tags/1.10.0/examples/internal-telemetry-config.yaml'

エンティティタグを追加する

タグnewrelic.service.type: otel_collectorは、UI レベルでのエクスペリエンスへのオプトインとして機能します。次のいずれかのオプションを選択します。

• オプション 1 : オプション 2 の設定を含む上記の設定例を使用します。
• オプション 2 : コレクターに引数--config=yaml:service::telemetry::resource::newrelic.service.type: otel_collectorを追加します。これにより、属性がリソース属性として追加され、New Relic が取り込み時にタグ付けを実行します。このオプションを削除すると、タグの有効期限が切れるまでに 1 日かかります。
• オプション 3 : APM UI (ページ上部、エンティティ名の横) からタグを追加します。UI 経由でこれを削除したり、元に戻したりすることもできます。

設定のカスタマイズ

デフォルトの設定では、詳細レベルやサンプリングなどの一般的なオプションを微調整するための形式INTERNAL_TELEMETRY_...の追加の環境変数が公開されます。 詳細については設定自体を参照してください。

コレクターを監視するにはデフォルトの設定を使用することをお勧めします。 ただし、サンプリングやデータ収集レートを下げるなど、ニーズに合わせて設定例を変更することができます。 詳細については、公式ドキュメントを参照してください。設定を変更すると、 UIの特定の部分にデータが表示されない場合があることに注意してください。 制限事項も参照してください。コレクターの内部テレメトリー設定オプションは、OTel コミュニティの進化に応じて変化します。 提供されているデフォルトを使用するかどうかを含め、設定を完全に制御できます。

オーバーヘッドの考慮

すべてのテレメトリーと同様、コレクターの内部テレメトリーによりデータの取り込みが増加します。 オーバーヘッドはワークロードと設定によって異なります。 考慮すべき重要な要素は次のとおりです。

メトリクスは、スループットに関係なく、コレクターとすべてのアクティブなコンポーネントに対して一定のオーバーヘッドを作成します。メトリクスは一定の間隔 (デフォルトでは 60 秒) で放射されます。 それぞれのメタデータ.yamlで示されているように、どのコンポーネントでもカスタムメトリックを発行できます。 これによりオーバーヘッドが増加する可能性があります。

ログ通常の操作中は影響は最小限です。エラー ログが急増するとオーバーヘッドが大きくなる可能性がありますが、ログはデフォルトでサンプリングされるため、オーバーヘッドは軽減されます。サンプリング アルゴリズムでは、定義された間隔ごとに一定数のログが許可され、その後、静的なレートでサンプリングが行われます。service::テレメトリー::ログ::samplingを参照してください。

トレースはデフォルトで無効になっています。理由:

• トレースの成熟度は限られています。 すべてのコンポーネントがインストゥルメント化されているわけではありません。このgithub issue を参照してください。
• 上流エージェントやコレクターからのワークロードやバッチ設定によって異なる、予測できないオーバーヘッド。
• 適応サンプリング アルゴリズムは使用できません。このため、特定のユースケースで予期しないコストが発生するリスクがない、普遍的なサンプリング推奨事項を提供することは不可能になります。

トレースがさらに成熟すると、コレクターがコンポーネント レベルでのデータ処理にどれだけの時間を費やしたかについて貴重なインサイトを提供するようになるでしょう。 トレースの作成中に実験するには、 INTERNAL_TELEMETRY_TRACE_LEVEL=infoを設定し、 INTERNAL_TELEMETRY_TRACE_SAMPLE_RATIO=0.001 (0.1%) などの低いサンプリング レートから開始して、取り込みボリュームを監視し、必要に応じて調整します。

UIでコレクターを表示する

APM UIで内部テレメトリーを探索する

コレクターの内部テレメトリーを表示するには、 APM & Services > Services - OpenTelemetry > your_collector_nameに移動してコレクターのエンティティを調べます。

コレクターが使用するコンポーネントによっては、一部のチャートが表示されない場合があります。たとえば、gRPC 経由で OTLP データを受信またはエクスポートしない場合、RPC チャートは空になります。

概要ページ

概要ページでは、コレクターの状態とパフォーマンスの概要が表示されます。

• 全体的なコレクターの健康メトリクス
• レシーバー、プロセッサー、エクスポーター、バッチ処理（ batchprocessorが必要）の動作のチャート
• メモリリミッターの独自の故障モード専用のチャート

• インフラストラクチャ関係とメトリクス (設定されている場合は、設定例を参照してください)

プロセスページ

プロセス ページでシステム レベルのリソース消費を追跡します。

• CPU使用率と傾向
• メモリ使用量とパターン
• プロセスレベルのパフォーマンス指標

HTTP/RPC ページ

HTTP/RPC ページとのネットワーク通信を監視します。

• HTTPクライアントとサーバーのリクエストメトリクス
• gRPC通信統計
• ネットワークレイテンシとエラー率

注: これらのチャートは、コレクターが HTTP または gRPC 経由で通信するコンポーネント (OTLP レシーバーやエクスポーターなど) を使用し、 INTERNAL_TELEMETRY_METRICS_LEVEL=detailed必要とする場合にのみ表示されます。

設定例

このセクションには、上記のステップバイステップ ガイドをコレクターが関与するさまざまなユース ケースにどのように適用するかを示す例が含まれています。

内部テレメトリーを有効にしたシンプルなコレクター

docker compose を使用して実行されるコレクターの最小限の例。

インフラストラクチャ関係を設定する（オプション、実験的）

上に示したように、 APMコレクターが実行されているインフラストラクチャのインフラストラクチャ メトリクスを表示できますが、それはインフラストラクチャがインストゥルメントされ、 関係を形成できる場合に限られます。 この関係は、コレクターの内部テレメトリーの追加プロパティによって駆動されます。 このトピックの詳細については、 OTel ドキュメントをご覧ください。これを設定する手順は、実際のインフラストラクチャによって大きく異なります。Kubernetes の一般的な選択については、例を作成しました。これは、Kubernetes 向け OTel ソリューションに基づいてコンテナーとサービスの関係を実現する方法を紹介します。

制限

• Collectorテレメトリーはまだ安定していません:

  • 内部テレメトリーのサポートされているバージョンは、NRDOT の構築に使用するコア コレクター バージョンによって暗黙的に定義されます。nrdot- コレクターのマニフェストにある otlpreceiver のバージョンを参照してください。
  • パブリック プレビュー中に送信されるテレメトリが変更された場合、当社は最新バージョンのみをサポートする権利を留保します。 たとえば、 http.client.request.duration （コレクターバージョン >=0.128.0、NRDOT バージョン >=1.2.0、nr-k8s-otel-collectors >=0.8.37) ですが、 http.request.durationではありません。

• エクスポート形式の要件: コレクターUI 、 otlpexporterによってエクスポートされる形式のテレメトリーを想定しています。 Prometheus 経由でエクスポートされたメトリクスはサポートされていません。 たとえば、 http.client.request.durationはサポートされていますが、 http_client_request_durationはサポートされていません。

• カスタム コンポーネント メトリクス:内部テレメトリーのドキュメントに記載されていない内部テレメトリーはまだサポートされていません。 カスタムまたは投稿コンポーネントは標準メトリクスを生成しますが、独自のメトリクスを定義することもできます。 カスタムダッシュボードを書かずにインサイトを取得できる方法を現在開発中です。

• OTel コンテナ用ゴールデンメトリクス: まだ完全にはサポートされていないため、インフラストラクチャ パネルの一部の列がコンテナ用に設定されていない可能性があります。