Managing configurations

Aperçu

Nous travaillons toujours sur cette fonctionnalité, mais nous aimerions que vous l'essayiez !

Cette fonctionnalité est actuellement fournie dans le cadre d'un programme d'aperçu conformément à nos politiques de pré-sortie.

Important

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.

Conseil

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: "*"

L'exemple montre comment configurer Agent Control avec deux agents gérés :Kubernetes infrastructure l'agent et Fluent Bit pour le transfert de log . Par exemple, si vous ne souhaitez pas envoyer de mesures de santé pour votre Fluent Bit log collecteur, définissez simplement sendMetrics: false dans le fichier YAML avant d'exécuter la commande d'installation.

Remote configuration for Kubernetes

La configuration à distance garantit un comportement cohérent de l'agent dans votre environnement, simplifie la gestion des changements et vous permet de faire évoluer l'observabilité sans gérer manuellement les fichiers YAML locaux.

Pour déployer la configuration de manière centralisée sur le cluster, définissez ce même contenu YAML dans la section de Configurations de contrôle de la flotte. Vous pouvez ensuite appliquer la configuration à une flotte entière de clusters dans le cadre d’un déploiement à distance. Il s’agit du fichier de configuration à distance .

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

Les exemples suivants montrent comment configurer Agent Control pour gérer différents ensembles d’agents. Ces configurations peuvent être utilisées soit lors de l'installation initiale, soit dans le cadre d'une configuration à distance dans le contrôle de la flotte.

Pour explorer tous les paramètres de configuration disponibles, reportez-vous à 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

Cet exemple déploie Agent Control avec monitoring d'infrastructure et Fluent Bit pour la collecte log .

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

Cet exemple déploie Agent Control avec la distribution New Relic d'OpenTelemetry (NRDOT) collecteur et désactive le filelog Récepteur dans le graphique Helm nr-k8s-otel-collector géré.

Important

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.

Configuration à distance : infrastructure New Relic

Cet exemple montre comment configurer à distance l'agent New Relic Infrastructure pour Kubernetes à l'aide du contrôle de la flotte. Il permet la collecte de métriques de processus en définissant enableProcessMetrics: true.

Configuration à distance : Fluent Bit

Cet exemple a configuré Fluent Bit à distance via le contrôle de la flotte. Il active les rapports de métriques de santé à partir du collecteur log en définissant sendMetrics: true.

Configuration à distance : Prometheus

Cet exemple configure l'agent Prometheus à distance à l'aide du contrôle de la flotte. Il permet à low-data mode de réduire le volume de télémétrie et de désactiver l'intégration par défaut.

Configuration à distance : OpenTelemetry

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

Important

Créez un secret Kubernetes pour stocker en toute sécurité la clé de licence New Relic et utilisez-le dans le chart_values en remplacement de la valeur licenseKey :

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

Nous vous recommandons d'utiliser le contrôle de la flotte pour définir et déployer OpenTelemetry configuration sur vos flottes. Pour configurer OpenTelemetry à distance, créez une configuration dans contrôle de la flotte avec la structure indiquée ci-dessous. Vous pouvez ajuster des valeurs telles que lowDataMode ou receivers.filelog.enabled et inclure tout autre paramètre de graphique Helm pertinent en fonction de vos besoins.

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.

Préséance de proxy

Agent Control utilisera les paramètres proxy dans l'ordre de priorité suivant :

proxy Champ de configuration dans la configuration de Agent Control
HTTP_PROXY variable d'environnement
HTTPS_PROXY variable d'environnement

Important

La configuration du proxy n'est actuellement pas compatible avec la récupération du certificat pour la validation de la signature. Si vous devez configurer un proxy, vous disposez des options suivantes :

Ajoutez une exception pare-feu à https://newrelic.com afin que requests à ce point de terminaison puissent ignorer le proxy (recommandé)
Utiliser un certificat local via fleet_control.signature_validation.certificate_pem_file_path (la rotation des certificats doit être gérée manuellement)
Désactivez la validation de signature en définissant fleet_control.signature_validation.enabled: false (fortement déconseillé pour des raisons de sécurité)

Configuration du proxy avec des certificats auto-signés

Pour les configurations de proxy utilisant l'authentification HTTPS avec des certificats auto-signés, vous devez fournir le bundle de certificats CA et configurer l'authentification proxy :

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

Configuration du proxy pour les agents gérés

Prudence

La configuration d'un proxy dans Agent Control ne configure pas automatiquement les mêmes paramètres de proxy pour les agents qu'il gère. Chaque agent possède sa propre configuration proxy qui doit être définie séparément en fonction du format de configuration et des exigences spécifiques de cet agent.

Lorsque vous utilisez un proxy, vous devez également configurer les paramètres de proxy pour chaque agent géré individuellement. Reportez-vous à la documentation spécifique de chaque agent pour les options de configuration du proxy.

Gestion des secrets

Agent Control fournit un mécanisme robuste pour gérer les données sensibles, telles que les mots de passe et les clés API, en les récupérant auprès de fournisseurs de secrets dédiés. Cela garantit que les informations sensibles ne sont pas codées en dur directement dans les fichiers de configuration. Le système prend actuellement en charge les fournisseurs secrets suivants :

HashiCorp Vault : appelé nr-vault dans la configuration.
Secrets Kubernetes : appelés nr-kubesec dans la configuration.

Définition des secrets dans la configuration

Pour utiliser les secrets, définissez-les dans votre fichier YAML de configuration Agent-Control en suivant ces étapes :

Définissez la section secrets_providers : configurez vos fournisseurs de secrets de manière centralisée dans cette section. Assurez-vous que chaque entrée correspond à un fournisseur pris en charge.
Configurer les sources secrètes : pour chaque fournisseur, spécifiez une ou plusieurs sources. Une source inclut les détails de configuration nécessaires (par exemple, URL, jeton) pour que le contrôle de l'agent se connecte et récupère un groupe de secrets.
Utilisez l'espace réservé dans la configuration de l'agent : au lieu des données sensibles réelles, utilisez une chaîne espace réservé dans configuration de votre agent. Le contrôle de l'agent remplace automatiquement ces espaces réservés par les secrets récupérés lors du processus de rendu.

Important

Si le contrôle de l'agent ne parvient pas à récupérer un secret, le rendu de la configuration échouera et l'agent ne sera pas exécuté. Il s’agit d’une fonctionnalité de sécurité essentielle pour empêcher les agents de s’exécuter avec une configuration incomplète ou incorrecte.

L'exemple de configuration de contrôle d'agent suivant montre comment configurer la récupération de secrets à partir de deux sources Vault dans la section secrets_providers :

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:
  ...

Utilisation des secrets dans une configuration d'agent

Une fois les sources définies, dans une configuration d'agent, vous pouvez référencer le coffre à l'aide d'une syntaxe d'espace réservé spécifique avec le chemin correct. Le contrôle de l'agent récupère le secret et l'utilise pour restituer le fichier de configuration final que l'agent va utiliser.

Exemple de configuration d'agent utilisant l'espace réservé du coffre-fort :

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}"

Dans cet exemple :

L'espace réservé ${nr-vault:local-instance:secret:my_secret:username} demande au contrôle de l'agent de récupérer la valeur associée au nom d'utilisateur de la clé à partir du secret du chemin secret/my_secret à l'aide de la source du coffre-fort de l'instance locale. L'espace réservé ${nr-vault:remote:my_mount:my_path:organization} récupère de la même manière la valeur de la clé d'organisation à partir de la source distante.

Après une récupération réussie, le contrôle de l'agent restitue ces secrets à partir de la source et du chemin spécifiés, en stockant le résultat dans un fichier secret K8s ou un fichier de configuration privé à utiliser par l'agent correspondant.

Les secrets du coffre-fort

Configurez les sources du coffre-fort avec les paramètres suivants :

Clé YAML	Description
`url`	URL pour demander des données
`token`	Utilisé pour s'authentifier auprès du point de terminaison.
`engine`	Spécifiez `kv1` ou `kv2`.

Dans le fichier de configuration, chaque secret stocké dans Vault est accessible en définissant un espace réservé avec :

source_name: Le nom de la source Vault définie dans secrets_providers.
mount: Le nom du support moteur secret.
path: Le chemin spécifique vers le secret.
specific key: La clé spécifique dans le secret à récupérer.

Exemple de format d'espace réservé complet :

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

Les secrets de Kubernetes

Si le pod de contrôle d'agent dispose d'autorisations, par exemple via un compte de service et un contrôle d'accès basé sur les rôles (RBAC), pour accéder aux secrets et à l'espace de nommage requis, le contrôle d'agent peut accéder directement aux secrets de l'API Kubernetes sans avoir besoin d'une configuration de sources distincte.

Dans le fichier de configuration de l'agent, récupérez chaque valeur secrète à l'aide d'un espace réservé spécifiant :

namespace: L'espace de nommage Kubernetes où se trouve le secret.
name: le nom de l'objet secret Kubernetes.
specific key: La clé spécifique dans le secret à partir de laquelle récupérer la valeur.

Par exemple, utilisez le format d'espace réservé :

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

Configuration du référentiel privé

Agent Control prend en charge la configuration de Helm privé pour déployer à la fois Agent Control lui-même et les agents gérés. Cela permet des environnements dans lesquels les cartes New Relic Helm ne sont pas directement accessibles.

Prudence

Lors de l'utilisation du référentiel privé Helm, les cartes doivent être compatibles et les images référencées dans les cartes doivent être accessibles. Dans le cas contraire, les agents ne fonctionneront pas comme prévu.

1. Activer le référentiel privé pour les agents

Pour des raisons de sécurité, seul le référentiel explicitement activé sera autorisé en configuration à distance. Pour activer un référentiel spécifique, vous devez mettre à jour la configuration de l'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
    # ...

La configuration référentielle autorisée peut ensuite être utilisée dans votre configuration à distance au sein de New Relic Control. Exemple:

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

De plus, vous devez configurer l'installation Helm d'Agent Control pour utiliser votre référentiel privé si le graphique agent-control lui-même se trouve dans un référentiel privé. Ceci est distinct de la configuration des agents gérés. Reportez-vous au fichier agent-control Helm chart values.yaml pour configurer la section installationJob. Spécifiquement:

chartRepositoryUrl contenant l'URL de votre référentiel
name si vous utilisez un nom de graphique différent
repositorySecretReferenceName et repositoryCertificateSecretReferenceName pour l'authentification (voir la section authentification ci-dessous pour plus de détails)

2. Configurer l'authentification pour le référentiel privé

Vous devez configurer des ressources supplémentaires pour activer l'authentification pour accéder à votre référentiel privé :

Pour vous authentifier à l'aide de l'authentification de base (nom d'utilisateur et mot de passe), vous devez créer un secret dans l'espace de nommage Agent Control contenant les valeurs attendues dans data.username et data.password.

Exemple:

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

Pour plus de détails, consultez la documentation Flux.

Lors de l'utilisation de l'authentification de base, la configuration à distance doit être configurée comme suit :

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

Pour vous authentifier à l’aide de TLS, vous devez créer un secret contenant :

tls.crt et tls.key: certificat client et clé privée utilisés pour l'authentification client TLS
ca.crt: Certificat CA utilisé pour vérifier le serveur (requis si le serveur utilise un certificat auto-signé)
Le secret doit être de type Opaque ou kubernetes.io/tls. Tous les fichiers du Secret doivent être codés en PEM.
Exemple:
```
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>
```
Pour plus de détails, consultez la documentation Flux.
Lors de l'utilisation de l'authentification par certificat TLS, la configuration à distance doit être configurée comme suit :
```
chart_repository:
  url: "https://my-private-repository-1"
  certificate_secret_reference:
    name: my-secret
```

Cette traduction automatique est fournie pour votre commodité.

Aperçu

Important

Conseil

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

Kubernetes configuration

Local values.yaml configuration for Kubernetes

Remote configuration for Kubernetes

callout.warning

Sample configurations: Agent Control on Kubernetes

Agent Control with New Relic infrastructure and Fluent Bit

Configuration locale pour l'infrastructure et Fluent Bit

Agent Control with OpenTelemetry and custom collector settings

Important

OpenTelemetry configuration

Sample configurations: Remote Agent Configurations on Kubernetes

Configuration à distance : infrastructure New Relic

Configuration à distance de l'infrastructure

Configuration à distance : Fluent Bit

Fluent Bit configuration

Configuration à distance : Prometheus

Configuration de Prometheus

Configuration à distance : OpenTelemetry

Important

OpenTelemetry remote configuration

Proxy configuration for Kubernetes

Préséance de proxy

Important

Configuration du proxy avec des certificats auto-signés

Exemple de configuration de proxy Kubernetes

Configuration du proxy pour les agents gérés

Prudence

Gestion des secrets

Définition des secrets dans la configuration

Important

Utilisation des secrets dans une configuration d'agent

Les secrets du coffre-fort

Les secrets de Kubernetes

Configuration du référentiel privé

Prudence

1. Activer le référentiel privé pour les agents

Activer le référentiel privé

2. Configurer l'authentification pour le référentiel privé

Authentification de base

Authentification par certificat TLS

Understanding the two layers of configuration

Local `values.yaml` configuration for Kubernetes