Managing configurations

プレビュー

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

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

重要

Agent Control currently only supports Kubernetes. The configurations and examples provided in this document are specific to this environment.

Agent Control provides two methods for managing agent configurations:

Local configuration: A comprehensive values.yaml file used during the initial Helm installation.
Remote configuration: A centralized, YAML-based configuration you create in New Relic Control that is remotely deployed to your entire fleet.

Remote configuration is the recommended method for day-to-day management. It ensures consistent agent behavior across your environment, simplifies change management, and enables you to scale without manually updating local YAML files on each host.

ヒント

The values-newrelic.yaml file, which traditionally defined New Relic agent settings, now also includes configuration for Agent Control. The parameters you define in this file determine how both Agent Control and its managed agents operate. This file is referred to as the local configuration.

Understanding the two layers of configuration

Agent Control's configuration is structured in two layers:

Agent Control's core configuration: These are the top-level settings that control how Agent Control operates, such as its connection to New Relic, its identity, and fleet management details.
Managed agents' configurations: These are the individual chart_values for each subagent (e.g., Infrastructure Agent, Fluent Bit) that Agent Control deploys and manages.

When a local and remote configuration are both present, Agent Control applies the following logic:

Remote configuration takes precedence. Any settings defined in a remote configuration from New Relic Control will override the corresponding settings in the local values.yaml file.
To intentionally override remote settings with your local configuration, you can deploy an empty remote configuration via New Relic Control. This change will apply to all clusters in the selected fleet.

Kubernetes configuration

These instructions and examples apply to Agent Control running on a Kubernetes cluster.

Local `values.yaml` configuration for Kubernetes

The local configuration file for Kubernetes, used during installation, contains all the settings for Agent Control and its managed agents.

This example shows the two layers of configuration within a single file.

# Layer 1: Agent Control's Core Configuration
global:
  cluster: "YOUR_CLUSTER_NAME"
  licenseKey: "YOUR_LICENSE_KEY"
  userKey: "YOUR_USER_KEY"

# Values related to the agent control's Helm chart release.
# `https://github.com/newrelic/helm-charts/blob/master/charts/agent-control/values.yaml`
agent-control-deployment:
  identityClientId: ""
  identityClientSecret: ""
  config:
    fleet_control:
      # Optional: Specify a fleet_id (entity guid) to automatically connect to an existing fleet.
      fleet_id: ""
      auth:
        # New Relic organization ID where agent will connect to.
        organizationId: "YOUR_ORGANIZATION_ID"

    # Layer 2: Managed Agents' Configurations
    # List of managed agents that will be deployed. The key represents the name of the agent and the value holds the configuration.
    subAgents:
      infrastructure:
        type: newrelic/com.newrelic.infrastructure:0.1.0
        content:
          # Ref: `https://github.com/newrelic/helm-charts/tree/master/charts/nri-bundle`
          # Recommended: check and define an explicit chart version (latest stable)
          chart_version: "*"
          chart_values:
            newrelic-infrastructure:
            enableProcessMetrics: true
      logs:
        type: newrelic/io.fluentbit:0.1.0
        content:
          # Ref: `https://github.com/newrelic/helm-charts/tree/master/charts/newrelic-logging`
          # Recommended: check and define an explicit chart version (latest stable)
          chart_version: "*"
          chart_values:
            newrelic-logging:
              sendMetrics: true
      agent-operator:
        type: com.newrelic.k8s_agent_operator:0.1.0
        content:
          chart_version: "*"

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

Remote configuration for Kubernetes

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

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

callout.warning

When you define a configuration in the New Relic Control UI, the YAML structure is different. You only provide the YAML that corresponds to the content block for a single agent.

Sample configurations: Agent Control on Kubernetes

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

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

The following examples show how to configure Agent Control with a set of subagents using the local values.yaml file.

Agent Control with New Relic infrastructure and Fluent Bit

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

global:
  cluster: "YOUR_CLUSTER_NAME"
  licenseKey: "YOUR_LICENSE_KEY"
  userKey: "YOUR_USER_KEY"

# See `https://github.com/newrelic/helm-charts/blob/master/charts/agent-control/values.yaml`
agent-control-deployment:
  identityClientId: ""
  identityClientSecret: ""
  config:
    fleet_control:
      # Optional
      # fleet_id: YOUR_FLEET_ENTITY_GUID
      auth:
        organizationId: "YOUR_ORGANIZATION_ID"
    subAgents:
      infrastructure:
        type: newrelic/com.newrelic.infrastructure:0.1.0
        content:
          # Ref: `https://github.com/newrelic/helm-charts/tree/master/charts/nri-bundle`
          # Recommended: check and define an explicit chart version (latest stable)
          chart_version: "*"

          #chart_values:
          #  newrelic-infrastructure:
          #    enableProcessMetrics: true
      logs:
        type: newrelic/io.fluentbit:0.1.0
        content:
          # Ref: `https://github.com/newrelic/helm-charts/tree/master/charts/newrelic-logging`
          # Recommended: check and define an explicit chart version (latest stable)
          chart_version: "*"

          #chart_values:
          #  newrelic-logging:
          #    sendMetrics: true
      agent-operator:
        type: com.newrelic.k8s_agent_operator:0.1.0
        chart_version: "*"

Agent Control with OpenTelemetry and custom collector settings

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

重要

Security Best Practice: Do not store sensitive values like your license key directly in the configuration. We recommend using a Kubernetes secret. Agent Control can then securely pull these values from the secret at runtime.

global:
  cluster: "YOUR_CLUSTER_NAME"
  licenseKey: "YOUR_LICENSE_KEY"
# Values related to the agent control's Helm chart release.
# `https://github.com/newrelic/helm-charts/blob/master/charts/agent-control/values.yaml`
agent-control-deployment:
  identityClientId: ""
  identityClientSecret: ""
  config:
    fleet_control:
      # Optional: Specify a fleet_id (entity guid) to automatically connect to an existing fleet.
      fleet_id: ""
      auth:
        # New Relic organization ID where agent will connect to.
        organizationId: "YOUR_ORGANIZATION_ID"

    # List of managed agents that will be deployed. The key represents the name of the agent and the value holds the configuration.
    subAgents:
      infrastructure:
        type: newrelic/com.newrelic.infrastructure:0.1.0
        content:
          # Ref: `https://github.com/newrelic/helm-charts/tree/master/charts/nri-bundle%60
          # Recommended: check and define an explicit chart version (latest stable)
          chart_version: "*"
      agent-operator:
        type: newrelic/com.newrelic.k8s_agent_operator:0.1.0
        content:
          chart_version: "*"
      fluentbit:
        type: newrelic/io.fluentbit:0.1.0
        content:
          # Ref: `https://github.com/newrelic/helm-charts/tree/master/charts/newrelic-logging`
          # Recommended: check and define an explicit chart version (latest stable)
          chart_version: "*"
          chart_values:
            global:
              lowDataMode: true
      prometheus:
        type: newrelic/com.newrelic.prometheus:0.1.0
        content:
          chart_version: "*"
          chart_values:
            global:
              lowDataMode: true
            newrelic-prometheus-agent:
              config:
                kubernetes:
                  integrations_filter:
                    enabled: false

Sample configurations: Remote Agent Configurations on Kubernetes

The following examples show how to configure individual agents remotely from the 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

This example configures the New Relic OpenTelemetry collector and enable lowDataMode as a valid option.

重要

Kubernetesシークレットを作成してNew Relicライセンスキーを安全に保存し、それをlicenseKey値の代わりにchart_valuesで使用します。

customSecretName: "your-secret-name"
customSecretLicenseKey: "your-secret-key"

Fleet Controlを使用して、フリート全体でOpenTelemetry設定を定義およびデプロイすることをお勧めします。 OpenTelemetryリモートで構成するには、以下に示す構造でFleet Controlに設定を作成します。必要に応じて、 lowDataModeやreceivers.filelog.enabledなどの値を調整し、その他の関連する Helm チャート設定を含めることができます。

chart_version: "*"
chart_values:
  newrelic-prometheus-agent:
    lowDataMode: true

Proxy configuration for Kubernetes

Agent Control supports proxy configuration to route traffic through corporate proxies. Proxy settings can be set through environment variables or directly in the configuration file.

プロキシの優先順位

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

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

重要

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

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

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

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

global:
  cluster: "YOUR_CLUSTER_NAME"
  licenseKey: "YOUR_LICENSE_KEY"

agent-control-deployment:
  config:
    agentControl:
      content:
        proxy:
          url: https://proxy-service:8080
    subAgents: {}

  # Mount CA certificate bundle to Agent Control
  extraVolumeMounts:
    - mountPath: /etc/ssl/certs/
      name: ca-certs
  extraVolumes:
    - name: ca-certs
      secret:
        secretName: ca-certs

# Configure Flux components to use proxy
agent-control-cd:
  flux2:
    sourceController:
      extraEnv:
        # Configure Flux source-controller to proxy all requests
        - name: HTTPS_PROXY
          value: https://proxy-service:8080
        # Except for in-cluster requests
        - name: "NO_PROXY"
          value: ".cluster.local.,.cluster.local,cluster.local,.svc,127.0.0.0/8,10.0.0.0/8"
      volumeMounts:
        # Mount CA certificate bundle to source-controller trust root store. The bundle should contain the
        # proxy CA cert.
        - mountPath: /etc/ssl/certs/
          name: ca-certs
      volumes:
        - name: ca-certs
          secret:
            secretName: ca-certs

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

注意

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

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

秘密管理

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

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

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

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

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

重要

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

次のエージェント制御設定例は、 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設定を更新する必要があります。

# values-newrelic.yaml

global:
  cluster: "YOUR_CLUSTER_NAME"
  licenseKey: "YOUR_LICENSE_KEY"

# ...

agent-control-deployment:
  config:
    allowedChartRepositoryUrl:
      - https://my-private-repository-1
      - https://my-private-repository-2
    # ...

許可されたリポジトリ設定は、 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. プライベートリポジトリの認証を設定する

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

基本認証 (ユーザー名とパスワード) を使用して認証するには、 Agent Controlネームスペースに、 data.usernameおよびdata.passwordの予想される値を含むシークレットを作成する必要があります。

例：

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
stringData:
  username: "myUser"
  password: "myPassword"

詳細については、 Flux のドキュメントを参照してください。

基本認証を使用する場合、リモート設定は次のように構成する必要があります。

chart_repository:
  url: "https://my-private-repository-1"
  secret_reference:
    name: my-secret

TLS を使用して認証するには、次の内容を含むシークレットを作成する必要があります。

tls.crt およびtls.key : TLSクライアント認証に使用されるクライアント証明書と秘密鍵
ca.crt: サーバーの検証に使用される CA 証明書 (サーバーが自己署名証明書を使用する場合に必要)
Secret のタイプはOpaqueまたはkubernetes.io/tlsである必要があります。Secret 内のすべてのファイルは PEM でエンコードされている必要があります。
例：
```
apiVersion: v1
kind: Secret
metadata:
  name: my-secret
  namespace: newrelic-agent-control
type: kubernetes.io/tls # or Opaque
data:
  tls.crt: <BASE64>
  tls.key: <BASE64>
  # NOTE: Can be supplied without the above values
  ca.crt: <BASE64>
```
詳細については、 Flux のドキュメントを参照してください。
TLS 証明書認証を使用する場合、リモート設定は次のように構成する必要があります。
```
chart_repository:
  url: "https://my-private-repository-1"
  certificate_secret_reference:
    name: my-secret
```

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

プレビュー

重要

ヒント

Understanding the two layers of configuration.css-21sua1{background:none;border:none;width:0;padding:0;}

Kubernetes configuration

Local values.yaml configuration for Kubernetes