Gestion de la configuration

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 ne prend actuellement en charge que Kubernetes. La configuration et les exemples fournis dans ce document sont spécifiques à cet environnement.

Agent Control fournit deux méthodes pour gérer la configuration de l'agent :

Configuration locale : un fichier values.yaml complet utilisé lors de l'installation initiale Helm .
Configuration à distance : une configuration centralisée basée sur YAML que vous créez dans New Relic Control et qui est déployée à distance sur l'ensemble de votre flotte.

La configuration à distance est la méthode recommandée pour la gestion quotidienne. Il garantit un comportement cohérent de l'agent dans votre environnement, simplifie la gestion des changements et vous permet d'évoluer sans mettre à jour manuellement les fichiers YAML locaux sur chaque hôte.

Conseil

Le fichier values-newrelic.yaml , qui définissait traditionnellement les paramètres de l'agent New Relic, inclut désormais également la configuration du contrôle de l'agent. Les paramètres que vous définissez dans ce fichier déterminent le fonctionnement d'Agent Control et de ses agents gérés. Ce fichier est appelé configuration locale.

Comprendre les deux couches de configuration

La configuration d'Agent Control est structurée en deux couches :

Configuration principale d'Agent Control : il s'agit des paramètres de niveau supérieur qui contrôlent le fonctionnement d'Agent Control, tels que sa connexion à New Relic, son identité et les détails de gestion de flotte.
Configuration des agents gérés : il s'agit des chart_values individuels pour chaque sous-agent (par exemple, agent d'infrastructure, Fluent Bit) que Agent Control déploie et gère.

Lorsqu'une configuration locale et une configuration distante sont toutes deux présentes, Agent Control applique la logique suivante :

La configuration à distance est prioritaire. Tous les paramètres définis dans une configuration distante à partir de New Relic Control remplaceront les paramètres correspondants dans le fichier values.yaml local.
Pour remplacer intentionnellement les paramètres distants par votre configuration locale, vous pouvez déployer une configuration distante vide via New Relic Control. Ce changement s'appliquera à tous les clusters de la flotte sélectionnée.

configurationKubernetes

Ces instructions et exemples s’appliquent à Agent Control exécuté sur un cluster Kubernetes.

configuration locale `values.yaml` pour Kubernetes

Le fichier de configuration local pour Kubernetes, utilisé lors de l'installation, contient tous les paramètres d'Agent Control et de ses agents gérés.

Cet exemple montre les deux couches de configuration dans un seul fichier.

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

configuration à distance pour 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

Lorsque vous définissez une configuration dans l’interface utilisateur de contrôle New Relic, la structure YAML est différente. Vous fournissez uniquement le YAML correspondant au bloc content pour un seul agent.

Exemple de configuration : Contrôle des agents sur 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.

Les exemples suivants montrent comment configurer Agent Control avec un ensemble de sous-agents à l'aide du fichier values.yaml local.

Contrôle des agents avec New Relic Infrastructure et 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: "*"

Contrôle des agents avec OpenTelemetry et paramètres de collecteur personnalisés

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

Meilleure pratique de sécurité : ne stockez pas de valeurs sensibles comme votre clé de licence directement dans la configuration. Nous vous recommandons d’utiliser un secret Kubernetes. Agent Control peut ensuite extraire en toute sécurité ces valeurs du secret au moment de l'exécution.

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

Exemple de configuration : configuration de l'agent distant sur Kubernetes

Les exemples suivants montrent comment configurer des agents individuels à distance à partir de l'interface utilisateur de New Relic Control .

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

Cet exemple configure le collecteur New Relic OpenTelemetry et active lowDataMode comme option valide.

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

configuration du proxy pour Kubernetes

Agent Control prend en charge la configuration du proxy pour acheminer le trafic via les proxys d'entreprise. Les paramètres proxy peuvent être définis via des variables d'environnement ou directement dans le fichier de configuration.

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

Comprendre les deux couches de configuration.css-21sua1{background:none;border:none;width:0;padding:0;}

configurationKubernetes

configuration locale values.yaml pour Kubernetes

configuration à distance pour Kubernetes

callout.warning

Exemple de configuration : Contrôle des agents sur Kubernetes

Contrôle des agents avec New Relic Infrastructure et Fluent Bit

Configuration locale pour l'infrastructure et Fluent Bit

Contrôle des agents avec OpenTelemetry et paramètres de collecteur personnalisés

Important

OpenTelemetry configuration

Exemple de configuration : configuration de l'agent distant sur 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

configurationà distance OpenTelemetry

configuration du proxy pour 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

Comprendre les deux couches de configuration

configuration locale `values.yaml` pour Kubernetes