Gestion de la configuration

Important

Agent Control et New Relic Control sont désormais disponibles en version générale pour Kubernetes ! La prise en charge des hôtes Linux et Windows fait également partie du programme public preview, conformément à nos politiques de pré-lancement.

Agent Control fournit une approche transparente pour configuration indépendamment de l'environnement dans lequel il est déployé. Deux méthodes de gestion de la configuration de l'agent sont disponibles :

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"

# Values related to the Agent Control's Helm chart release.
# `https://github.com/newrelic/helm-charts/blob/master/charts/agent-control-bootstrap/values.yaml`
agentControlDeployment:
  chartValues:
    systemIdentity:
      organizationId: "****"
      parentIdentity:
        clientId: "****"
        clientSecret: "****"
    config:
      fleet_control:
        # Optional: Specify a fleet_id (entity guid) to automatically connect to an existing fleet.
        fleet_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.
      agents:
        infrastructure:
          agent_type: newrelic/com.newrelic.infrastructure:0.1.0
        logs:
          agent_type: newrelic/io.fluentbit:0.1.0
        agent-operator:
          agent_type: com.newrelic.k8s_agent_operator:0.1.0

    agentsConfig:
      infrastructure:
        # 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:
        # 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:
        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 .

Conseil

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

configuration : Agent Control 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"

# See `https://github.com/newrelic/helm-charts/blob/master/charts/agent-control-bootstrap/values.yaml`
agentControlDeployment:
  chartValues:
    systemIdentity:
      organizationId: "****"
      parentIdentity:
        clientId: "****"
        clientSecret: "****"
    config:
      fleet_control:
        # Optional: Specify a fleet_id (entity guid) to automatically connect to an existing fleet.
        fleet_id: "****"
      agents:
        infrastructure:
          agent_type: newrelic/com.newrelic.infrastructure:0.1.0
        logs:
          agent_type: newrelic/io.fluentbit:0.1.0
        agent-operator:
          agent_type: com.newrelic.k8s_agent_operator:0.1.0
    agentsConfig:
      infrastructure:
        # 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:
        # 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:
        chart_version: "*"

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

avec OpenTelemetry et les 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-bootstrap/values.yaml`
agentControlDeployment:
  chartValues:
    systemIdentity:
      organizationId: "****"
      parentIdentity:
        clientId: "****"
        clientSecret: "****"
    config:
      fleet_control:
        # Optional: Specify a fleet_id (entity guid) to automatically connect to an existing fleet.
        fleet_id: "****"

      # List of managed agents that will be deployed. The key represents the name of the agent and the value holds the configuration.
      agents:
        nr-otel-collector:
          agent_type: "newrelic/com.newrelic.opentelemetry.collector:0.1.0"
    # List of managed agents that will be deployed. The key represents the name of the agent and the value holds the configuration.
    agentsConfig:
      nr-otel-collector:
        chart_version: "*"
        chart_values:
          nr-k8s-otel-collector: {}
          global: {}

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:
  nr-k8s-otel-collector:
    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

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"

agentControlDeployment:
  proxy:
    url: https://proxy-service:8080

  # 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
agentControlCd:
  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 à partir 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 décrits dans Fournisseurs de valeurs.

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é, seuls les référentiels explicitement activés sont autorisés en configuration à distance. Pour activer un référentiel spécifique, mettez à jour la configuration du contrôle de l'agent comme suit :

# values-newrelic.yaml

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

# ...

agentControlDeployment:
  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-bootstrap 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-bootstrap Helm chart values.yaml pour configurer la section installationJob comme suit :

chartRepositoryUrl: L'URL contenant l'emplacement de votre référentiel.
chartName: Le nom du graphique si vous utilisez un nom de graphique différent.
repositorySecretReferenceName et repositoryCertificateSecretReferenceName: les secrets requis pour l’authentification auprès de votre référentiel. Consultez 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 afin d’accéder à votre référentiel privé comme suit :

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
```

configurationLinux

Voici les chemins par défaut pour la configuration du contrôle des agents :

Local fichier de configuration: /etc/newrelic-agent-control/config.yaml
Remote fichier configuration : /var/lib/newrelic-agent-control/config.yaml (si activé via le contrôle de la flotte déployée)
Définition du service : /lib/systemd/system/newrelic-agent-control.service
Fichier d'environnement de service : /etc/newrelic-agent-control/newrelic-agent-control.conf

Par défaut, l'agent peut orchestrer l'agent d'infrastructure et le collecteur 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"

Vous pouvez renommer ou supprimer l’un ou l’autre des agents en fonction de vos besoins d’observabilité. Le nom de l'agent doit être un nom d'étiquette RFC-1035 valide.

Vous pouvez également utiliser des variables d’environnement pour définir les paramètres de l’agent :

Utilisez le préfixe NR_ (soulignement simple) pour cibler la configuration principale du contrôle de l'agent.
Utilisez __ (double trait de soulignement) pour cibler les paramètres disponibles dans Agent Control. Ceci est nécessaire pour éviter les collisions avec les clés de configuration qui contiennent des traits de soulignement.
Les variables d'environnement n'ont priorité que sur le fichier de configuration local. Si la configuration à distance est activée, les variables d'environnement ne sont pas prises en compte.
Par exemple, pour définir une configuration dynamique pour le fleet_control::endpoint, ajoutez le NR_FLEET_CONTROL__ENDPOINT=https://opamp.service.newrelic.com/v1/opamp dans le fichier de définition de service.

Configurer les agents

Agent Control peut actuellement gérer les types d'agents sur hôte prédéfinis suivants :

Agent d'infrastructure New Relic : newrelic/com.newrelic.infrastructure. Toutes les fonctionnalités existantes de l' agentinfrastructure sont prises en charge, y compris l'orchestration de l'intégration sur hôte et l'intégration de notre redirecteur de log basé sur FluentBit.
Distribution New Relic pour OpenTelemetry : newrelic/com.newrelic.opentelemetry.collector

Chaque type d'agent offre un ensemble de variables facultatives qui peuvent être personnalisées pour adapter son comportement. Pour personnaliser la configuration locale de l’agent :

Créez un fichier values.yml : ce fichier contiendra les valeurs de configuration souhaitées.
Placez le fichier values.yml dans le répertoire /etc/newrelic-agent-control/fleet/agents.d/YOUR-AGENT-NAME/values/. Ici, YOUR-AGENT-NAME est le nom réel de votre agent (par exemple, nr-infra-agent).

Voici une liste des variables disponibles pour les dernières versions de type d'agent :

Agent d'infrastructure New Relic : 0.1.0
Distribution New Relic pour OpenTelemetry : 0.1.0

Type d'agent	Variable	Type	Défaut
`com.newrelic.infrastructure`	`config_agent`	Un YAML contenant la configuration de l'agent infrastructure	(vide)
`com.newrelic.infrastructure`	`config_integrations`	Une map YAML (les clés sont des noms de fichiers) contenant la configuration de l'intégration sur hôte	(vide)
`com.newrelic.infrastructure`	`config_logging`	Une carte YAML (les clés sont des noms de fichiers) contenant la configuration du transfert de logs	(vide)
`com.newrelic.infrastructure`	`health_port`	Port pour le serveur d'état local de l'agent d'infrastructure	`/health/status`
`com.newrelic.opentelemetry.collector`	`config`	configuration du collecteur OpenTelemetry (au format YAML)	(vide)
`com.newrelic.opentelemetry.collector`	`health_check.path` `health_check.port`	Chemin et port pour l' extension de vérification de l'état de santé du Collecteur Otel, point de terminaison http local	`localhost:13133/health/status`
Tous les agents gérés	`backoff_delay`	Temps jusqu'à la prochaine tentative si le collecteur ne parvient pas à démarrer (en secondes).	`20s`

Conseil

Vous pouvez configurer les paramètres de l'agent d'infrastructure et les paramètres du collecteur OpenTelemetry selon vos besoins en fonction des configurations prises en charge.

Exemple de configuration

Configuration à distance avec contrôle de la flotte

Les exemples suivants contiennent des cas d’utilisation courants prêts à être copiés et collés en tant que configuration valide pour Agent Control et les agents gérés.

paramètres de l'agent d'infrastructure, paramètres d'intégration Redis et paramètres de transfert de logs pour notre intégration FluentBit. Le config_agent avec un license_key valide est toujours obligatoire. Les autres sections sont facultatives (supprimez ou mettez à jour selon vos besoins) :

config_agent:
  license_key: YOUR_LICENSE_KEY
  custom_attributes:
    env: demo
config_integrations:
  nri-redis-example.yml:
    integrations:
      - name: nri-redis
        env:
          hostname: localhost
          port: 6380
          keys: '{"0":["<KEY_1>"],"1":["<KEY_2>"]}'
          remote_monitoring: true
config_logging:
  fluentbit-example.yml:
    logs:
      - name: syslog
        file: /var/log/syslog
        attributes:
          logtype: linux_syslog

monitoring de base de l'hôte à l'aide du Collecteur Otel ( monitoring des processus désactivée) et du Récepteur OTLP activé pour recevoir les traces, les métriques et les logs des services APM :

config:
  receivers:
    otlp:
      protocols:
        grpc:
        http:

    hostmetrics:
      collection_interval: 20s
      scrapers:
        cpu:
          metrics:
            system.cpu.time:
              enabled: false
            system.cpu.utilization:
              enabled: true
        load:
        memory:
          metrics:
            system.memory.utilization:
              enabled: true
        paging:
          metrics:
            system.paging.utilization:
              enabled: false
            system.paging.faults:
              enabled: false
        filesystem:
          metrics:
            system.filesystem.utilization:
              enabled: true
        disk:
          metrics:
            system.disk.merged:
              enabled: false
            system.disk.pending_operations:
              enabled: false
            system.disk.weighted_io_time:
              enabled: false
        network:
          metrics:
            system.network.connections:
              enabled: false

    filelog:
      include:
        - /var/log/syslog

  processors:
    # group system.cpu metrics by cpu
    metricstransform:
      transforms:
        - include: system.cpu.utilization
          action: update
          operations:
            - action: aggregate_labels
              label_set: [ state ]
              aggregation_type: mean
        - include: system.paging.operations
          action: update
          operations:
            - action: aggregate_labels
              label_set: [ direction ]
              aggregation_type: sum
    # remove system.cpu metrics for states
    filter/exclude_cpu_utilization:
      metrics:
        datapoint:
          - 'metric.name == "system.cpu.utilization" and attributes["state"] == "interrupt"'
          - 'metric.name == "system.cpu.utilization" and attributes["state"] == "nice"'
          - 'metric.name == "system.cpu.utilization" and attributes["state"] == "softirq"'
    filter/exclude_memory_utilization:
      metrics:
        datapoint:
          - 'metric.name == "system.memory.utilization" and attributes["state"] == "slab_unreclaimable"'
          - 'metric.name == "system.memory.utilization" and attributes["state"] == "inactive"'
          - 'metric.name == "system.memory.utilization" and attributes["state"] == "cached"'
          - 'metric.name == "system.memory.utilization" and attributes["state"] == "buffered"'
          - 'metric.name == "system.memory.utilization" and attributes["state"] == "slab_reclaimable"'
    filter/exclude_memory_usage:
      metrics:
        datapoint:
          - 'metric.name == "system.memory.usage" and attributes["state"] == "slab_unreclaimable"'
          - 'metric.name == "system.memory.usage" and attributes["state"] == "inactive"'
    filter/exclude_filesystem_utilization:
      metrics:
        datapoint:
          - 'metric.name == "system.filesystem.utilization" and attributes["type"] == "squashfs"'
    filter/exclude_filesystem_usage:
      metrics:
        datapoint:
          - 'metric.name == "system.filesystem.usage" and attributes["type"] == "squashfs"'
          - 'metric.name == "system.filesystem.usage" and attributes["state"] == "reserved"'
    filter/exclude_filesystem_inodes_usage:
      metrics:
        datapoint:
          - 'metric.name == "system.filesystem.inodes.usage" and attributes["type"] == "squashfs"'
          - 'metric.name == "system.filesystem.inodes.usage" and attributes["state"] == "reserved"'
    filter/exclude_system_disk:
      metrics:
        datapoint:
          - 'metric.name == "system.disk.operations" and IsMatch(attributes["device"], "^loop.*") == true'
          - 'metric.name == "system.disk.merged" and IsMatch(attributes["device"], "^loop.*") == true'
          - 'metric.name == "system.disk.io" and IsMatch(attributes["device"], "^loop.*") == true'
          - 'metric.name == "system.disk.io_time" and IsMatch(attributes["device"], "^loop.*") == true'
          - 'metric.name == "system.disk.operation_time" and IsMatch(attributes["device"], "^loop.*") == true'
    filter/exclude_system_paging:
      metrics:
        datapoint:
          - 'metric.name == "system.paging.usage" and attributes["state"] == "cached"'
          - 'metric.name == "system.paging.operations" and attributes["type"] == "cached"'
    filter/exclude_network:
      metrics:
        datapoint:
          - 'IsMatch(metric.name, "^system.network.*") == true and attributes["device"] == "lo"'

    attributes/exclude_system_paging:
      include:
        match_type: strict
        metric_names:
          - system.paging.operations
      actions:
        - key: type
          action: delete

    transform:
      trace_statements:
        - context: span
          statements:
            - truncate_all(attributes, 4095)
            - truncate_all(resource.attributes, 4095)
      log_statements:
        - context: log
          statements:
            - truncate_all(attributes, 4095)
            - truncate_all(resource.attributes, 4095)

    # used to prevent out of memory situations on the collector
    memory_limiter:
      check_interval: 1s
      limit_mib: 100

    batch:

    resourcedetection:
      detectors: ["env", "system"]
      system:
        hostname_sources: ["os"]
        resource_attributes:
          host.id:
            enabled: true

    resourcedetection/cloud:
      detectors: ["gcp", "ec2", "azure"]
      timeout: 2s
      ec2:
        resource_attributes:
          host.name:
            enabled: false

  exporters:
    otlp:
      endpoint: otlp.nr-data.net:4317
      headers:
        api-key: ${NEW_RELIC_LICENSE_KEY}

  service:
    pipelines:
      metrics:
        receivers: [otlp, hostmetrics]
        processors:
          - memory_limiter
          - metricstransform
          - filter/exclude_cpu_utilization
          - filter/exclude_memory_utilization
          - filter/exclude_memory_usage
          - filter/exclude_filesystem_utilization
          - filter/exclude_filesystem_usage
          - filter/exclude_filesystem_inodes_usage
          - filter/exclude_system_disk
          - filter/exclude_network
          - attributes/exclude_system_paging
          - batch
          - resourcedetection
          - resourcedetection/cloud
        exporters: [otlp]
      traces:
        receivers: [otlp]
        processors: [transform, resourcedetection, resourcedetection/cloud, batch]
        exporters: [otlp]
      logs:
        receivers: [otlp, filelog]
        processors: [transform, resourcedetection, resourcedetection/cloud, batch]
        exporters: [otlp]

Une configuration valide pour Agent Control lui-même montrant comment désactiver les agents, par exemple, le Collecteur Otel :

agents:
  nr-infra-agent:
    agent_type: "newrelic/com.newrelic.infrastructure:0.1.0"
  #nr-otel-collector:
  #  agent_type: "newrelic/com.newrelic.opentelemetry.collector:0.1.0"

Configuration Windows

Voici les chemins par défaut pour la configuration d'Agent Control sous Windows :

Local fichier de configuration: C:\Program Files\New Relic\newrelic-agent-control\local-data\agent-control\local_config.yaml
Remote fichier de configuration : C:\ProgramData\New Relic\newrelic-agent-control\fleet-data\agent-control\remote_config.yaml (synchronisé depuis Fleet Control)
Exécutable du service : C:\Program Files\New Relic\newrelic-agent-control\newrelic-agent-control.exe
Répertoire des logs : C:\ProgramData\New Relic\newrelic-agent-control\logs\

Par défaut, Agent Control sous Windows peut orchestrer l'agent d'infrastructure et le collecteur 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"

Conseil

Pour les comptes régionaux, utilisez le point de terminaison approprié et token_url:

Région UE : https://opamp.service.eu.newrelic.com/v1/opamp et https://system-identity-oauth.service.eu.newrelic.com/oauth2/token
Région Japon : https://opamp.service.jp.newrelic.com/v1/opamp et https://system-identity-oauth.service.jp.newrelic.com/oauth2/token

Vous pouvez renommer ou supprimer l’un ou l’autre des agents en fonction de vos besoins d’observabilité. Le nom de l'agent doit être un nom d'étiquette RFC-1035 valide.

Notes de configuration spécifiques à Windows

Les chemins de fichiers utilisent des barres obliques inverses (\\) et des chemins de type Windows (par exemple, C:\\ProgramData\\...)
Les binaires de l'Agent utilisent des extensions .exe
Le service s'exécute en tant que LocalSystem — assurez-vous que les fichiers de configuration ont des permissions d'écriture restreintes
Les modèles et configurations provenant d'environnements Linux peuvent nécessiter des ajustements de chemin pour la compatibilité Windows

Configurer les agents

Agent Control sous Windows peut actuellement gérer les types d'agents suivants :

Agent d'infrastructure New Relic : newrelic/com.newrelic.infrastructure. Prend en charge les intégrations sur l'hôte et le transfert de logs via le Fluent Bit intégré.
Distribution New Relic pour OpenTelemetry : newrelic/com.newrelic.opentelemetry.collector

Pour personnaliser la configuration locale de l'agent, placez un fichier values.yml dans le répertoire values de l'agent. Les variables disponibles sont les mêmes que pour les hôtes Linux.

Exemple de configuration

Configuration à distance avec Fleet Control

Paramètres de l'agent d'infrastructure avec transfert de logs Windows. Le config_agent avec un license_key valide est toujours obligatoire :

config_agent:
  license_key: YOUR_LICENSE_KEY
  custom_attributes:
    env: production
config_logging:
  windows-event-log.yml:
    logs:
      - name: windows-security
        winlog:
          channel: Security
          collect-eventids:
            - 4624
            - 4625
        attributes:
          logtype: windows_security

Une configuration valide pour Agent Control lui-même sous Windows, montrant comment gérer les agents :

agents:
  nr-infra-agent:
    agent_type: "newrelic/com.newrelic.infrastructure:0.1.0"
  #nr-otel-collector:
  #  agent_type: "newrelic/com.newrelic.opentelemetry.collector:0.1.0"

Fournisseurs de valeurs

Les fournisseurs de valeurs permettent à Agent Control de résoudre des valeurs provenant de sources externes lorsqu’une configuration est rendue, de sorte que les données sensibles telles que les clés de licence, les jetons, ou les mots de passe n’ont pas besoin d’être codées en dur dans vos fichiers de configuration.

Les valeurs sont référencées avec la syntaxe d’espace réservé ${NAMESPACE:NAME} dans la configuration de l’agent. Agent Control les résout chaque fois qu’une configuration est appliquée, y compris lors des mises à jour de configuration à distance, de sorte que les valeurs soumises à une rotation sont prises en compte sans redémarrer Agent Control.

Important

Si Agent Control ne parvient pas à résoudre une valeur, le rendu de la configuration échoue, et l’agent n’est pas démarré. Cela empêche les agents de s’exécuter avec des configurations incomplètes, ou incorrectes.

Après une résolution réussie, Agent Control stocke le résultat rendu dans un secret Kubernetes ou dans un fichier de configuration privé pour être utilisé par l’agent correspondant.

Fournisseurs de valeurs pris en charge

Fournisseur	Espace de nommage de l’espace réservé	Nécessite une configuration
Variables d'environnement	`nr-env`	Non
HashiCorp Vault	`nr-vault`	Oui
Fichiers locaux	`nr-file`	Non
Les secrets de Kubernetes	`nr-kubesec`	Non
ConfigMaps Kubernetes	`nr-kubecm`	Non

Configuration des fournisseurs de valeurs

Seul HashiCorp Vault nécessite une configuration explicite. Définissez-le sous la clé value_providers de la configuration de Agent Control. La clé legacy secrets_providers est toujours acceptée comme alias.

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

Chaque entrée sous sources définit une source Vault nommée avec les paramètres suivants :

Clé YAML	Requis	Description
`url`	Oui	URL complète de Vault, incluant le chemin `/v1`.
`token`	Oui	Jeton utilisé pour s’authentifier auprès du point de terminaison.
`engine`	Oui	Version du moteur secret : `kv1` ou `kv2`.
`client_timeout`	Non	Délai d'attente HTTP pour les requests Vault. La valeur par défaut est `30s`. Défini au niveau `vault`, et non par source.

Variables d'environnement : `nr-env`

Lit une valeur à partir de l'environnement hôte (disponible pour le processus Agent Control).

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

HashiCorp Vault : `nr-vault`

Lit une clé à partir d'un secret KV Vault. Nécessite la configuration value_providers.vault décrite ci-dessus.

L’espace réservé utilise ce format :

"${nr-vault:SOURCE_NAME:MOUNT:PATH:KEY}"

SOURCE_NAME: nom de la source Vault définie dans value_providers.
MOUNT: nom du support moteur secret.
PATH: chemin vers le secret.
KEY: clé dans le secret à récupérer.

Par exemple:

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

Ici, ${nr-vault:local-instance:secret:my_secret:username} récupère la valeur de la clé username à partir du secret à secret/my_secret en utilisant la source local-instance, et ${nr-vault:remote:my_mount:my_path:organization} récupère la clé organization à partir de la source remote.

Fichiers locaux : `nr-file`

Lit le contenu d'un fichier local, en supprimant les espaces de début et de fin.

L'espace réservé prend le chemin absolu vers le fichier :

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

Secrets Kubernetes : `nr-kubesec`

Lit une clé à partir d’un secret Kubernetes. Disponible sur Kubernetes uniquement, et ne nécessite aucune configuration supplémentaire tant que le pod Agent Control dispose des autorisations, via un compte de service et le RBAC, pour accéder aux secrets et espaces de nommage requis.

L’espace réservé utilise ce format :

"${nr-kubesec:NAMESPACE:SECRET_NAME:KEY}"

NAMESPACE: espace de nommage où se trouve le secret.
SECRET_NAME: nom de l’objet secret Kubernetes.
KEY: clé dans le secret à récupérer.

ConfigMaps Kubernetes : `nr-kubecm`

Lit une clé à partir d'un ConfigMap Kubernetes. Disponible uniquement sur Kubernetes, et ne nécessite aucune configuration supplémentaire tant que le pod Agent Control dispose des autorisations pour accéder aux ConfigMaps et espaces de nommage requis.

L’espace réservé utilise ce format :

"${nr-kubecm:NAMESPACE:CONFIGMAP_NAME:KEY}"

NAMESPACE: espace de nommage où se trouve le ConfigMap.
CONFIGMAP_NAME: nom de l’objet ConfigMap Kubernetes.
KEY: clé à récupérer dans la ConfigMap.

Cette traduction automatique est fournie pour votre commodité.

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

Conseil

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

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

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

configurationLinux

Configurer les agents

Conseil

Exemple de configuration

Configuration à distance avec contrôle de la flotte

Agent d'infrastructure, intégration sur hôte et redirecteur de log (FluentBit intégré)

Hôtel New Relic Collecteur

Contrôle des agents New Relic

Configuration Windows

Conseil

Notes de configuration spécifiques à Windows

Configurer les agents

Exemple de configuration

Configuration à distance avec Fleet Control

Agent d'infrastructure avec transfert de logs

Configuration du contrôle des agents

Fournisseurs de valeurs

Important

Fournisseurs de valeurs pris en charge

Configuration des fournisseurs de valeurs

Variables d'environnement : nr-env

HashiCorp Vault : nr-vault

Fichiers locaux : nr-file

Secrets Kubernetes : nr-kubesec

ConfigMaps Kubernetes : nr-kubecm

Comprendre les deux couches de configuration

configuration locale `values.yaml` pour Kubernetes

Variables d'environnement : `nr-env`

HashiCorp Vault : `nr-vault`

Fichiers locaux : `nr-file`

Secrets Kubernetes : `nr-kubesec`

ConfigMaps Kubernetes : `nr-kubecm`