コレクターオブザーバビリティを使い始める

請求する

Collectorオブザーバビリティの使用は、アカウントに関連付けられた価格モデルに適用され、以下に定義されているように、注文に従ってプレビュー中に請求されます。

この機能に関連するコストは、アカウントに関連付けられた価格モデルに応じて、以下の要因によって決まります。

Core 計算：Core CCUで測定されるサマリーページは、プレビュー期間中は課金対象となります。

データインジェスト: プレビュー期間中は、内部テレメトリからの追加データ (取り込まれた GB 単位で測定) が課金対象となります。

この機能が一般公開された場合、お客様の使用料はご注文に応じて請求されます。

ステップごとの設定

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

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

bash

$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：デフォルトはUS https://otlp.nr-data.netです；EUの場合は、これをhttps://otlp.eu01.nr-data.netに設定してください；JPの場合は、これを次に設定してください https://otlp.jp.nr-data.net

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

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

bash

$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:2.5.0 --config=/etc/nrdot-collector/config.yaml \
>  --config='/etc/nrdot-collector/config-internal.yaml'

重要

service::telemetryノードの下に既存の設定がある場合、 --config引数の順序は重要になります。コレクターは、設定と構成の特定の部分（例: リスト、リーフノードなど)はマージできないため、最後の--config引数によって上書きされます。

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

タグ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 経由でこれを削除したり、元に戻したりすることもできます。

タグ付けしたら、コレクターのデータを探索するために、UIでコレクターを表示するをご覧ください。

オプション：設定をカスタマイズする

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

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

オーバーヘッドの考慮

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

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

コレクターが送信するメトリクスの量を減らす必要がある場合は、メトリクスレベルをnormalに設定することをお勧めします。たとえば、サンプル設定の環境変数INTERNAL_TELEMETRY_METRICS_LEVELを使用します。UIで使用されるdetailedメトリクスは一部のみであり、通常はパフォーマンスやネットワークの問題を微調整するためのメトリクスであるため、必要に応じて再度有効にすることができます。

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

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

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

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

設定例

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

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

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

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

「概要」ページで説明しているように、APMはコレクターが実行されているインフラストラクチャのインフラストラクチャメトリクスを表示できますが、これはインフラストラクチャがインストゥルメントされた状態であり、関係を形成できる場合に限られます。この関係は、コレクターの内部テレメトリーの追加属性によって決定されます。このトピックの詳細については、OTelのドキュメントを参照してください。これを設定する手順は、実際のインフラストラクチャに大きく依存します。一般的な選択肢であるKubernetesについては、 OTel for Kubernetesソリューションに基づいてコンテナとサービスの関係を実現する方法を示す例を作成しました。

この機械翻訳は、参考として提供されています。