• /
  • EnglishEspañolFrançais日本語한국어Português
  • ログイン今すぐ開始

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

英語版と翻訳版に矛盾がある場合は、英語版が優先されます。詳細については、このページを参照してください。

問題を作成する

構成

プレビュー

この機能はまだ開発中ですが、ぜひお試しください。

この機能は現在、弊社のプレリリース ポリシーに従ってプレビュー プログラムの一部として提供されています。

従来values-newrelic.yaml New Relicエージェント設定を定義していた ファイルには、 の設定も含まれるようになりました。Agent Controlこのファイルで定義する問題により、 Agent Controlとその管理対象エージェントの両方がどのように動作するかが決まります。 このファイルはローカル設定と呼ばれます。

設定例を次に示します。

このサンプルでは、Agent Control インフラストラクチャエージェントと転送ログ用の 2 つのマネージド エージェントとともにKubernetes Fluent Bitを構成する方法を示します。たとえば、 Fluent Bit Collector にヘルス メトリクスを送信したくない場合は、インストール コマンドを実行する前に YAML ファイルにsendMetrics: falseを設定するだけです。

プロイ設定をクラスタ全体で一元的に展開するには、 の Configurations [設定]Fleet Control セクションでこれと同じ YAML コンテンツを定義します。その後、その設定をリモート展開の一部としてクラスタのフリート全体に適用できます。 これはリモート設定ファイルと呼ばれます。

リモート設定により、環境全体でエージェントの一貫した動作が保証され、変更管理が簡素化され、ローカル YAML ファイルを手動で管理することなく監視を拡張できるようになります。

Agent Control Kubernetes ConfigMapsを使用して設定を保存および適用します。 ローカル設定とリモート設定の両方が存在する場合、デフォルトではリモート設定が優先されます。 リモート設定を意図的にオーバーライドしてローカル設定に戻すには、 を介して 空のリモート設定 をデプロイできます。Fleet Controlこの変更は、選択したフリート内のすべてのクラスターに適用されることに注意してください。

利用可能なすべての構成設定を確認するには、 values-newrelic.yamlを参照してください。

サンプル設定

次の例は、さまざまなエージェントのセットを管理するようにAgent Controlを構成する方法を示しています。 これらの設定は、初期導入中、またはFleet Controlのリモート設定の一部として使用できます。

New Relic InfrastructureとFluent Bit

この例では、インフラストラクチャ監視とログ収集用の 備えたデプロイAgent Control Fluent Bit使用します。

カスタムコレクター設定を備えた OpenTelemetry

この例では、New Relic ディストリビューションの OpenTelemetry (NRDOT) コレクターを使用して Agent Control をデプロイし、管理対象のnr-k8s-otel-collector Helm チャート内のfilelogレシーバーを無効にします。

リモート設定: New Relicインフラストラクチャ

この例では、New Relic Kubernetesを使用して の Infrastructure エージェントをリモートで設定する方法を示します。Fleet ControlenableProcessMetrics: true設定することでプロセス メトリクス収集を有効にします。

リモート設定: Fluent Bit

この例では、Fleet Control を介して Fluent Bit をリモートで構成しました。sendMetrics: true設定すると、ログコレクターからのヘルス メトリクス レポートが有効になります。

リモート設定: Prometheus

この例では、Fleet Control を使用して Prometheus エージェントをリモートで構成します。これにより、 low-data modeテレメトリーの音量を下げ、デフォルトの統合を無効にすることができます。

リモート設定: OpenTelemetry

プロキシの設定

Agent Control 、企業のプロキシまたはネットワーク仲介を介してトラフィックをルーティングするためのプロキシ設定をサポートします。 プロキシ設定は、環境変数を通じて、または設定ファイルで直接設定できます。

プロキシの優先順位

Agent Control次の優先順位でプロキシ設定を使用します。

  1. proxy Agent Control設定の設定フィールド
  2. HTTP_PROXY 環境変数
  3. HTTPS_PROXY 環境変数

重要

プロキシ設定は現在、署名検証用の証明書の取得と互換性がありません。 プロキシを設定する必要がある場合は、次のオプションがあります。

  • ファイアウォール例外をhttps://newrelic.comに追加して、そのエンドポイントへのrequestsプロキシをスキップできるようにします (推奨)
  • fleet_control.signature_validation.certificate_pem_file_pathを通じてローカル証明書を使用します (証明書のローテーションは手動で処理する必要があります)
  • fleet_control.signature_validation.enabled: falseを設定して署名検証を無効にします (セキュリティ上の理由から強く推奨されません)

自己署名証明書を使用したプロキシ設定

自己署名証明書による HTTPS 認証を使用するプロキシ設定の場合、CA 証明書バンドルを提供し、プロキシ認証を構成する必要があります。

マネージドエージェント用プロキシ設定

注意

Agent Controlでプロキシを構成しても、管理するエージェントに対して同じプロキシ設定が自動的に構成されるわけではありません。 各エージェントには独自のプロキシ設定があり、そのエージェント固有の設定形式と要件に従って個別に設定する必要があります。

プロキシを使用する場合は、管理対象エージェントごとにプロキシ設定を個別に構成する必要があります。プロキシ設定オプションについては、各エージェントの固有のドキュメントを参照してください。

秘密管理

Agent Control専用のシークレット プロバイダーからパスワードやAPIキーなどの機密データを取得して管理するための堅牢なメカニズムを提供します。 これにより、機密情報が設定ファイルに直接ハードコードされなくなります。 システムは現在、次のシークレット プロバイダーをサポートしています。

  • HashiCorp Vault: 設定ではnr-vaultと呼ばれます。
  • Kubernetes Secrets: 設定ではnr-kubesecと呼ばれます。

設定でシークレットを定義する

シークレットを利用するには、次の手順に従って、エージェント コントロール設定 YAML ファイル内でシークレットを定義します。

  1. secrets_providersセクションを定義します。このセクションでシークレット プロバイダーを集中的に構成します。各エントリがサポートされているプロバイダーに対応していることを確認します。
  2. シークレット ソースを構成する:プロバイダーごとに、1 つ以上のソースを指定します。ソースには、エージェント制御がシークレットのグループに接続して取得するために必要な設定の詳細 (例: URL、VPN) が含まれています。
  3. エージェント設定でプレースホルダーを使用する:実際の機密データの代わりに、エージェントの設定内でプレースホルダー文字列を使用します。 エージェント コントロールは、レンダリング プロセス中にこれらのプレースホルダーを取得したシークレットに自動的に置き換えます。

重要

エージェント コントロールがシークレットの取得に失敗した場合、設定のレンダリングは失敗し、エージェントは実行されません。 これは、エージェントが不完全または間違った設定で実行されるのを防ぐための重要なセキュリティ機能です。

次のエージェント制御設定例は、 secrets_providersセクション内の 2 つの Vault ソースからシークレットを取得するように設定する方法を示しています。

secrets_providers:
vault:
sources:
local-instance:
url: http://localhost:8200/v1/
token: root
engine: kv2
remote:
url: http://my-remote-server:8200/v1/
token: root
engine: kv1
fleet_control:
...
agents:
...

エージェント設定でのシークレットの使用

ソースを定義した後、エージェント設定で、正しいパスを持つ特定のプレースホルダー構文を使用してボールトを参照できます。 エージェント コントロールはシークレットを取得し、それを使用してエージェントが使用する最終設定ファイルをレンダリングします。

vault プレースホルダーを使用したエージェント設定の例:

config_agent: |+
enable_process_metrics: true
custom_attributes:
username: "${nr-vault:local-instance:secret:my_secret:username}"
organization: "${nr-vault:remote:my_mount:my_path:organization}"

この例では

プレースホルダー${nr-vault:local-instance:secret:my_secret:username}は、ローカル インスタンス ボールト ソースを使用してパスsecret/my_secretのシークレットからキー ユーザー名に関連付けられた値を取得するようにエージェント コントロールに指示します。 プレースホルダー${nr-vault:remote:my_mount:my_path:organization}も同様に、リモート ソースから組織キーの値を取得します。

取得が成功すると、エージェント コントロールは指定されたソースとパスからこれらのシークレットをレンダリングし、対応するエージェントが使用できるように結果を K8s シークレットまたはプライベート構成ファイルに保存します。

ヴォールトの秘密

次の設定で Vault ソースを設定します。

YAMLキー

説明

url

データを要求するURL

token

エンドポイントへの認証に使用されます。

engine

kv1またはkv2を指定します。

構成ファイルでは、次のプレースホルダーを設定することで、Vault に保存されている各シークレットにアクセスできます。

  • source_name : secrets_providersで定義された Vault ソースの名前。
  • mount [マウント]: シークレットエンジンマウントの名前。
  • path : シークレットへの特定のパス。
  • specific key [特定のキー]: 取得するシークレット内の特定のキー。

完全なプレースホルダー形式の例:

"${nr-vault:source_name:my_mount:my_path:my_value}"

Kubernetesの秘密

エージェント コントロールのポッドが、サービス アカウントやロールベースのアクセス制御 (RBAC) などを介して、必要なシークレットとネームスペースにアクセスする権限を持っている場合、エージェント コントロールは、別のソース設定を必要とせずに、 Kubernetes APIからシークレットに直接アクセスできます。

エージェント設定ファイルで、次を指定するプレースホルダーを使用して各シークレット値を取得します。

  • namespace [ネームスペース]: シークレットが存在するKubernetesネームスペース。
  • name : Kubernetes シークレット オブジェクトの名前。
  • specific key [特定のキー]: 値を取得するシークレット内の特定のキー。

たとえば、次のプレースホルダー形式を使用します。

"${nr-kubesec:my_namespace:my_secret:my_value}"

プライベートリポジトリ設定

Agent Control は、Agent Control 自体と管理対象エージェントの両方をデプロイするためのプライベート Helm リポジトリの構成をサポートしています。これにより、New Relic Helm チャートに直接アクセスできない環境が可能になります。

注意

プライベート Helm リポジトリを使用する場合、チャートは互換性があり、チャート内の参照イメージにアクセスできる必要があります。そうしないと、エージェントは期待どおりに動作しません。

1. エージェントのプライベートリポジトリを有効にする

セキュリティ上の理由から、リモート設定では明示的に有効化されたリポジトリのみが許可されます。 特定のリポジトリを有効にするには、 Agent Control設定を更新する必要があります。

許可されたリポジトリ設定は、 New Relic Control 内のリモート設定で使用できるようになります。 例:

chart_version: "1.2.3"
chart_repository:
url: "https://my-private-repository-1"
name: "my-chart-name" # Optional: use only if the chart name doesn't match New Relic's chart name

さらに、 agent-controlチャート自体がプライベート リポジトリ内にある場合は、プライベート リポジトリを使用するようにAgent ControlのHelmを構成する必要があります。 マネージドエージェントの設定とは別のものです。 installationJobセクションを設定するには、 agent-control Helm チャートvalues.yamlを参照してください。具体的には:

  • chartRepositoryUrl リポジトリのURLを含む
  • name 別のチャート名を使用する場合
  • repositorySecretReferenceName 認証にはrepositoryCertificateSecretReferenceName使用します(詳細は以下の認証セクションを参照してください)

2. プライベートリポジトリの認証を設定する

プライベート リポジトリにアクセスするための認証を有効にするには、追加のリソースを設定する必要があります。

Copyright © 2025 New Relic株式会社。

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.