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

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

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

問題を作成する

設定の管理

|View as Markdown (English)

重要

Agent Control と New Relic Control が Kubernetes で一般提供されました。Linux ホストと Windows ホストのサポートも、弊社のプレリリース ポリシーに従ってパブリック プレビュープログラムで提供されます。

Agent Control 、展開されている環境に依存しない設定のためのシームレスなアプローチを提供します。 エージェント設定の管理には 2 つの方法があります。

  • ローカル設定:初期Helmインストレーション中に使用される包括的なvalues.yamlファイル。

  • リモート設定: New Relic Control で作成する集中型の YAML ベースの設定で、フリート全体にリモートで展開されます。

日常の管理にはリモート設定が推奨されます。 これにより、環境全体で一貫したエージェントの動作が保証され、変更管理が簡素化され、各ホスト上のローカル YAML ファイルを手動で更新することなくスケーリングが可能になります。

ヒント

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

設定の 2 つの層を理解する

Agent Controlの設定は 2 つの層で構成されています。

  1. Agent Controlのコア設定:これらは、 New Relicへの接続、ID、フリート管理の詳細など、 Agent Control動作を制御する最上位の設定です。

  2. 管理エージェントの設定:これらは、 Agent Controlコントロール デプロイが管理する各サブエージェント (インフラストラクチャエージェント、 Fluent Bitなど) の個別のchart_valuesです。

ローカル設定とリモート設定の両方が存在する場合、 Agent Control次のロジックを適用します。

  1. リモート設定が優先されます。 New Relic Control からのリモート構成で定義された設定は、ローカルvalues.yamlファイル内の対応する設定を上書きします。
  2. リモート設定をローカル設定で意図的にオーバーライドするには、 New Relic Control を介して空のリモート設定をデプロイできます。 この変更は、選択したフリート内のすべてのクラスターに適用されます。

Kubernetes設定

これらの手順と例は、 Kubernetesクラスタ上で実行されているAgent Controlに適用されます。

Kubernetesのローカルvalues.yaml設定

インストール中に使用されるKubernetesのローカル設定ファイルには、 Agent Controlとその管理対象エージェントのすべての設定が含まれています。

この例では、1 つのファイル内に 2 つの設定レイヤーを示します。

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

Kubernetesのリモート設定

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

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

ヒント

New Relic Control UIで設定を定義する場合、YAML 構造は異なります。 単一のエージェントのcontentブロックに対応する YAML のみを提供します。

サンプル設定: KubernetesでのAgent Control

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

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

次の例は、ローカルvalues.yamlファイルを使用してサブエージェントのセットでAgent Controlを構成する方法を示しています。

New Relic InfrastructureとFluent BitによるAgent Control

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

OpenTelemetryおよびカスタム コレクター設定を使用したAgent Control

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

重要

セキュリティのベスト プラクティス: ライセンスキーなどの機密性の高い値を設定に直接保存しないでください。 Kubernetes シークレットの使用をお勧めします。Agent Control 、実行時にシークレットからこれらの値を安全に取得できます。

サンプル設定: Kubernetesでのリモートエージェント設定

次の例は、New Relic Control UI から個々のエージェントをリモートで構成する方法を示しています。

リモート設定: 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

この例では、New Relic OpenTelemetry コレクターを設定し、 lowDataMode有効なオプションとして有効にします。

重要

セキュリティのベスト プラクティス: ライセンスキーなどの機密性の高い値を設定に直接保存しないでください。 Kubernetes シークレットの使用をお勧めします。Agent Control 、実行時にシークレットからこれらの値を安全に取得できます。

Kubernetesのプロキシ設定

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

プロキシの優先順位

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

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

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

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

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

注意

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

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

秘密管理

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

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

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-bootstrapチャート自体がプライベート リポジトリにある場合は、プライベート リポジトリを使用するようにAgent ControlのHelmを構成する必要があります。 マネージドエージェントの設定とは別のものです。 agent-control-bootstrap Helm チャートvalues.yamlを参照して、 installationJobセクションを次のように構成します。

  • chartRepositoryUrl: リポジトリの場所を含む URL。
  • chartName: 別のチャート名を使用している場合はチャート名。
  • repositorySecretReferenceName およびrepositoryCertificateSecretReferenceName : リポジトリへの認証に必要なシークレット。詳細については、以下の認証セクションを参照してください。

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

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

Linuxの設定

Agent Control設定のデフォルト パスは次のとおりです。

  • Local 設定ファイル: /etc/newrelic-agent-control/config.yaml
  • Remote 設定ファイル: /var/lib/newrelic-agent-control/config.yaml ( Fleet Controlデプロイメント経由で有効な場合)
  • サービス定義: /lib/systemd/system/newrelic-agent-control.service
  • サービス環境ファイル: /etc/newrelic-agent-control/newrelic-agent-control.conf

デフォルトでは、エージェントはインフラストラクチャエージェントとOpenTelemetryを調整します。

# Configures the integration with Fleet Control
fleet_control:
# EU region? Use: https://opamp.service.eu.newrelic.com/v1/opamp
# JP region? Use: https://opamp.service.jp.newrelic.com/v1/opamp
endpoint: https://opamp.service.newrelic.com/v1/opamp
headers:
api-key: YOUR_INGEST_KEY
auth_config:
# EU region? Use: https://system-identity-oauth.service.eu.newrelic.com/oauth2/token
# JP region? Use: https://system-identity-oauth.service.jp.newrelic.com/oauth2/token
token_url: "https://system-identity-oauth.service.newrelic.com/oauth2/token"
client_id: "YOUR_CLIENT_ID
provider: "local"
private_key_path: "path/to/key"
# Configures the agents to be supervised by Agent Control
agents:
# Agent name (RFC-1035 valid label)
nr-infra-agent:
# The supported agent type and agent type version
agent_type: "newrelic/com.newrelic.infrastructure:0.1.0"
nr-otel-collector:
agent_type: "newrelic/com.newrelic.opentelemetry.collector:0.1.0"

監視要件に基づいて、いずれかのエージェントの名前を変更または削除できます。 エージェント名は有効な RFC-1035ラベル名である必要があります。

環境変数を使用してエージェント設定を定義することもできます。

  • メインのAgent Control設定をターゲットにするには、 NR_ (単一のアンダースコア) プレフィックスを使用します。
  • Agent Controlで使用可能な設定を対象にするには、 __ (二重アンダースコア) を使用します。 これは、アンダースコアを含む設定キーとの衝突を避けるために必要です。
  • 環境変数はローカル設定ファイルよりも優先されます。 リモート設定が有効になっている場合、環境変数は考慮されません。
  • たとえば、 fleet_control::endpoint動的な設定を定義するには、サービス定義ファイルにNR_FLEET_CONTROL__ENDPOINT=https://opamp.service.newrelic.com/v1/opampを追加します。

エージェントを構成する

Agent Control現在、次の事前定義されたオンホスト エージェント タイプを管理できます。

各エージェント タイプには、その動作に合わせてカスタマイズできるオプションの変数のセットが用意されています。エージェントのローカル設定をカスタマイズするには:

  1. values.ymlファイルを作成します: このファイルには必要な設定値が含まれます。
  2. values.ymlファイルを/etc/newrelic-agent-control/fleet/agents.d/YOUR-AGENT-NAME/values/ディレクトリに配置します。ここで、 YOUR-AGENT-NAMEエージェントの実際の名前です (例: nr-infra-agent )。

最新のエージェント タイプ バージョンで使用可能な変数のリストは次のとおりです。

  • New Relicインフラストラクチャ エージェント: 0.1.0
  • OpenTelemetry の New Relic ディストリビューション: 0.1.0

エージェントタイプ

変数

タイプ

デフォルト

com.newrelic.infrastructure

config_agent

インフラストラクチャエージェント設定を含む YAML

(空の)

com.newrelic.infrastructure

config_integrations

オンホストインテグレーション設定を含む YAML マップ (キーはファイル名)

(空の)

com.newrelic.infrastructure

config_logging

ログ転送設定を含む YAML マップ (キーはファイル名)

(空の)

com.newrelic.infrastructure

health_port

インフラストラクチャエージェントのローカルステータスサーバー用のポート

/health/status

com.newrelic.opentelemetry.collector

config

OpenTelemetryコレクター設定(YAML形式)

(空の)

com.newrelic.opentelemetry.collector

health_check.path health_check.port

OTel コレクターヘルスチェック拡張機能ローカル http エンドポイントのパスとポート

localhost:13133/health/status

すべての管理対象エージェント

backoff_delay

コレクターの起動に失敗した場合の次回の再試行までの時間 (秒単位)。

20s

ヒント

サポートされている設定に従って、必要に応じてインフラストラクチャエージェント設定OpenTelemetry設定を構成できます。

サンプル設定

Fleet Controlによるリモート設定

次の例には、 Agent Controlおよびマネージド エージェントの有効な設定としてコピー アンド ペーストできる一般的な使用例が含まれています。

Windowsの設定

Windows上のAgent Control設定のデフォルト パスは次のとおりです。

  • Local 設定ファイル: C:\Program Files\New Relic\newrelic-agent-control\local-data\agent-control\local_config.yaml
  • Remote 設定ファイル: C:\ProgramData\New Relic\newrelic-agent-control\fleet-data\agent-control\remote_config.yaml (Fleet Control から同期)
  • サービス実行可能ファイル: C:\Program Files\New Relic\newrelic-agent-control\newrelic-agent-control.exe
  • ログディレクトリ: C:\ProgramData\New Relic\newrelic-agent-control\logs\

デフォルトでは、 Windows上のAgent ControlインフラストラクチャエージェントとOpenTelemetryを調整できます。

# Configures the integration with Fleet Control
fleet_control:
endpoint: https://opamp.service.newrelic.com/v1/opamp
headers:
api-key: YOUR_INGEST_KEY
auth_config:
token_url: "https://system-identity-oauth.service.newrelic.com/oauth2/token"
client_id: "YOUR_CLIENT_ID"
provider: "local"
private_key_path: "path\\to\\key"
# Configures the agents to be supervised by Agent Control
agents:
# Agent name (RFC-1035 valid label)
nr-infra-agent:
# The supported agent type and agent type version
agent_type: "newrelic/com.newrelic.infrastructure:0.1.0"
nr-otel-collector:
agent_type: "newrelic/com.newrelic.opentelemetry.collector:0.1.0"

ヒント

リージョンアカウントの場合は、適切なエンドポイントとtoken_urlを使用してください:

  • EU地域:https://opamp.service.eu.newrelic.com/v1/opampおよび https://system-identity-oauth.service.eu.newrelic.com/oauth2/token
  • JP地域:https://opamp.service.jp.newrelic.com/v1/opampおよび https://system-identity-oauth.service.jp.newrelic.com/oauth2/token

監視要件に基づいて、いずれかのエージェントの名前を変更または削除できます。 エージェント名は有効な RFC-1035ラベル名である必要があります。

Windows固有の設定に関する注意事項

  • ファイルパスはバックスラッシュ( \\ )とWindowsスタイルのパス(例: C:\\ProgramData\\... )を使用します。
  • エージェントバイナリは.exe拡張機能を使用します
  • サービスはLocalSystemとして実行されます。設定ファイルの書き込み権限が制限されていることを確認してください。
  • Linux 環境のテンプレートと設定では、 Windows互換性のためにパスの調整が必要になる場合があります。

エージェントの設定

Windows上のAgent Control現在、次のエージェント タイプを管理できます。

  • New Relicインフラストラクチャ エージェント: newrelic/com.newrelic.infrastructure 。 内蔵のFluent Bitによるオンホスト統合とログ転送をサポートします。
  • OpenTelemetry の New Relic ディストリビューション: newrelic/com.newrelic.opentelemetry.collector

エージェントのローカル設定をカスタマイズするには、エージェントの値ディレクトリにvalues.ymlファイルを配置します。 使用可能な変数はLinux ホストの場合と同じです。

サンプル設定

Fleet Controlによるリモート設定

値プロバイダー

値プロバイダーを使用すると、設定のレンダリング時にAgent Controlが外部ソースから値を解決できるため、ライセンスキー、トークン、パスワードなどの機密データを設定ファイルにハードコードする必要がなくなります。

値は、エージェント設定内の ${NAMESPACE:NAME} プレースホルダー構文を使用して参照されます。Agent Control は、リモート設定の更新を含め、設定が適用されるたびにそれらを解決するため、Agent Control を再起動することなくローテーションされた値が取得されます。

重要

Agent Controlが値の解決に失敗した場合、設定のレンダリングは失敗し、エージェントは起動しません。これにより、不完全または不適切な設定でエージェントが実行されるのを防ぎます。

解決に成功すると、Agent Controlは、対応するエージェントが使用できるように、レンダリングされた結果をKubernetesシークレットまたはプライベート設定ファイルに保存します。

サポートされている値プロバイダー

プロバイダー

プレースホルダーのネームスペース

設定が必要です

環境変数

nr-env

いいえ

HashiCorp Vault

nr-vault

はい

ローカルファイル

nr-file

いいえ

Kubernetesの秘密

nr-kubesec

いいえ

Kubernetes ConfigMap

nr-kubecm

いいえ

値プロバイダーの設定

HashiCorp Vaultのみ明示的な設定が必要です。Agent Control設定のvalue_providersキーの下に定義します。レガシーキーsecrets_providersは、引き続きエイリアスとして受け入れられます。

value_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
client_timeout: 10s
fleet_control:
...
agents:
...

sources の各エントリは、次の設定を持つ名前付き Vault ソースを定義します:

YAMLキー

必須

説明

url

はい

/v1パスを含む、完全なVault URL。

token

はい

エンドポイントに対する認証に使用されるトークン。

engine

はい

シークレットエンジンのバージョン:kv1またはkv2

client_timeout

いいえ

Vault requestsのHTTPタイムアウト。デフォルトは30sです。ソースごとではなく、vaultレベルで設定します。

環境変数: nr-env

ホスト環境から値を読み取ります(Agent Controlプロセスで利用可能)。

config_agent:
license_key: "${nr-env:NEW_RELIC_LICENSE_KEY}"

HashiCorp Vault: nr-vault

Vault KVシークレットからキーを読み取ります。上記のvalue_providers.vault設定が必要です。

プレースホルダーはこの形式を使用します:

"${nr-vault:SOURCE_NAME:MOUNT:PATH:KEY}"
  • SOURCE_NAMEvalue_providersで定義されたVaultソースの名前。
  • MOUNT: シークレットエンジンマウントの名前。
  • PATH:シークレットへのパス。
  • KEY: 取得するシークレット内のキー。

例えば:

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}local-instanceソースを使用してsecret/my_secretのシークレットからusernameキーの値を取得し、${nr-vault:remote:my_mount:my_path:organization}remoteソースからorganizationキーを取得します。

ローカルファイル: nr-file

ローカルファイルの内容を読み取り、先頭と末尾の空白をトリミングします。

プレースホルダーには、ファイルへの絶対パスを指定します:

config_agent:
license_key: "${nr-file:/etc/newrelic/license.key}"

Kubernetesシークレット: nr-kubesec

Kubernetesシークレットからキーを読み取ります。Kubernetesでのみ利用可能です。Agent Controlポッドが、サービスアカウントとRBACを通じて、必要なシークレットとネームスペースにアクセスする権限を持っている限り、追加の設定は必要ありません。

プレースホルダーはこの形式を使用します:

"${nr-kubesec:NAMESPACE:SECRET_NAME:KEY}"
  • NAMESPACE: シークレットが存在するネームスペース。
  • SECRET_NAME:Kubernetesシークレットオブジェクトの名前。
  • KEY: 取得するシークレット内のキー。

Kubernetes ConfigMaps: nr-kubecm

Kubernetes ConfigMap からキーを読み取ります。Kubernetes でのみ利用可能であり、Agent Control ポッドが必要な ConfigMap とネームスペースにアクセスする権限を持っている限り、追加の設定は必要ありません。

プレースホルダーはこの形式を使用します:

"${nr-kubecm:NAMESPACE:CONFIGMAP_NAME:KEY}"
  • NAMESPACE: ConfigMap が配置されているネームスペース。
  • CONFIGMAP_NAME:Kubernetes ConfigMapオブジェクトの名前。
  • KEY:取得するConfigMap内のキー。
Copyright © 2026 New Relic株式会社。

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