Gerenciando configuração

O agente Control fornece uma abordagem integrada para configuração independente do ambiente onde está implantado. Dois métodos para gerenciar a configuração do agente estão disponíveis:

• Configuração local: um arquivo values.yaml abrangente usado durante a instalação inicial Helm .

• Configuração remota: uma configuração centralizada, baseada em YAML, que você cria no New Relic Control e que é implantada remotamente em toda a sua frota.

A configuração remota é o método recomendado para o gerenciamento diário. Ele garante um comportamento consistente do agente em todo o seu ambiente, simplifica o gerenciamento de mudanças e permite que você dimensione sem atualizar manualmente os arquivos YAML locais em cada host.

Compreendendo as duas camadas de configuração

A configuração do agente Control está estruturada em duas camadas:

1. Configuração principal do agente Control: Estas são as configurações de nível superior que controlam como o agente Control opera, como sua conexão com o New Relic, sua identidade e detalhes de gerenciamento de frota.

2. Configuração do agente gerenciado: São os chart_values individuais para cada subagente (por exemplo, agente de infraestrutura, Fluent Bit) que o agente Control implanta e gerencia.

Quando uma configuração local e remota estão presentes, o agente Control aplica a seguinte lógica:

1. A configuração remota tem precedência. Quaisquer configurações definidas em uma configuração remota do New Relic Control substituirão as configurações correspondentes no arquivo values.yaml local.
2. Para substituir intencionalmente as configurações remotas pela sua configuração local, você pode implantar uma configuração remota vazia por meio do New Relic Control. Essa alteração será aplicada a todos os clusters da frota selecionada.

Configuração Kubernetes

Estas instruções e exemplos se aplicam ao agente de controle em execução em um cluster do Kubernetes.

Configuração values.yaml local para Kubernetes

O arquivo de configuração local do Kubernetes, usado durante a instalação, contém todas as configurações do agente Control e seu agente gerenciado.

Este exemplo mostra as duas camadas de configuração em um único arquivo.

# 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-bootstrap/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: "*"

O exemplo demonstra como configurar o Agent Control junto com dois agentes gerenciados: o agente de infraestrutura Kubernetes e Fluent Bit para encaminhamento de logs. Por exemplo, se você não quiser enviar métricas de saúde para seu coletor de log Fluent Bit , basta definir sendMetrics: false no arquivo YAML antes de executar o comando de instalação.

Configuração remota para Kubernetes

A configuração remota garante um comportamento consistente do agente em todo o seu ambiente, simplifica o gerenciamento de alterações e permite que você dimensione a observabilidade sem gerenciar manualmente os arquivos YAML locais.

Para implantar a configuração centralmente no cluster, defina esse mesmo conteúdo YAML na seção Configurations do Controle de Agentes. Você pode então aplicar a configuração a uma frota inteira de clusters como parte de uma implantação remota. Isso é chamado de arquivo de configuração remota .

Exemplo de configuração: controle de agente no Kubernetes

Configuração: Controle de agente no Kubernetes Os exemplos a seguir mostram como configurar o Controle de agente para gerenciar diferentes conjuntos de agentes. Essas configurações podem ser utilizadas durante a instalação inicial ou como parte de uma configuração remota no Controle de Agentes.

Para explorar todas as configurações disponíveis, consulte values-newrelic.yaml.

Os exemplos a seguir mostram como configurar o agente Control com um conjunto de subagentes usando o arquivo values.yaml local.

Agente de Controle com New Relic Infrastructure e Fluent Bit

Este exemplo implanta Agent Control com monitoramento de infraestrutura e Fluent Bit para coleta de logs.

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

Controle de agente com OpenTelemetry e configurações personalizadas do coletor

com OpenTelemetry e configurações de coletor personalizadas Este exemplo implanta o agente Control com a distribuição New Relic do OpenTelemetry (NRDOT) e desabilita o receptor filelog no gráfico Helm gerenciadonr-k8s-otel-collector .

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

Exemplo de configuração: configuração de agente remoto no Kubernetes

Os exemplos a seguir mostram como configurar agentes individuais remotamente a partir da interface do New Relic Control .

Configuração remota: New Relic Infrastructure

Este exemplo mostra como configurar remotamente o agente da New Relic Infrastructure para Kubernetes usando o Controle de Agentes. Ele permite a coleta de métricas do processo definindo enableProcessMetrics: true.

chart_version: "*"
chart_values:
  newrelic-infrastructure:
    enableProcessMetrics: true

Configuração remota: Fluent Bit

Este exemplo configurou Fluent Bit remotamente via Controle de Agentes. Ele habilita relatórios métricos de saúde do coletor de logs definindo sendMetrics: true.

chart_version: "*"
chart_values:
  newrelic-logging:
    sendMetrics: true

Configuração remota: Prometheus

Este exemplo configura o agente Prometheus remotamente usando o Controle de Agentes. Ele permite que low-data mode reduza o volume de telemetria e desabilite a integração padrão.

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

Configuração remota: OpenTelemetry

Este exemplo configura o coletor New Relic OpenTelemetry e habilita lowDataMode como uma opção válida.

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

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

Configuração de proxy para Kubernetes

O agente Control suporta configuração de proxy para rotear o tráfego através de proxies corporativos. As configurações de proxy podem ser definidas por meio de variáveis de ambiente ou diretamente no arquivo de configuração.

Precedência de proxy

Agent Control usará as configurações de proxy na seguinte ordem de precedência:

1. proxy Campo de configuração na configuração de Agent Control
2. HTTP_PROXY variável de ambiente
3. HTTPS_PROXY variável de ambiente

Configuração de proxy com certificados autoassinados

Para configurações de proxy usando autenticação HTTPS com certificados autoassinados, você precisa fornecer o pacote de certificado da CA e configurar a autenticação de 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

Configuração de proxy para agente gerenciado

Ao usar um proxy, você também deve configurar as definições de proxy para cada agente gerenciado individualmente. Consulte a documentação específica de cada agente para obter opções de configuração de proxy.

Gerenciamento de segredos

O agente Control fornece um mecanismo robusto para gerenciar dados confidenciais, como senhas e chaves de API, recuperando-os de provedores secretos dedicados. Isso garante que informações confidenciais não sejam codificadas diretamente em arquivos de configuração. O sistema atualmente suporta os seguintes provedores secretos:

• HashiCorp Vault: referido como nr-vault na configuração.
• Secrets Kubernetes : referidos como nr-kubesec na configuração.

Definindo segredos na configuração

Para utilizar segredos, defina-os no arquivo YAML de configuração do agente-Control seguindo estas etapas:

1. Defina a seção secrets_providers : configure seus provedores secretos centralmente nesta seção. Certifique-se de que cada entrada corresponda a um provedor suportado.
2. Configurar fontes secretas: para cada provedor, especifique uma ou mais fontes. Uma fonte inclui os detalhes de configuração necessários (por exemplo, URL, token) para que o agente de controle se conecte e recupere um grupo de segredos.
3. Utilize o espaço reservado na configuração do agente: Em vez dos dados confidenciais reais, utilize uma string de espaço reservado na configuração do seu agente. O agente de controle substitui automaticamente esses espaços reservados pelos segredos recuperados durante o processo de renderização.

O exemplo de configuração de controle de agente a seguir demonstra como configurar a recuperação de segredos de duas fontes do Vault dentro da seção 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:
  ...

Usando segredos em uma configuração de agente

Depois que as fontes forem definidas, em uma configuração de agente, você poderá referenciar o vault usando uma sintaxe de espaço reservado específica com o caminho correto. O controle do agente recupera o segredo e o usa para renderizar o arquivo de configuração final que o agente irá usar.

Exemplo de configuração de agente utilizando espaço reservado do vault:

config_agent: |+
  enable_process_metrics: true
  custom_attributes:
    username: "${nr-vault:local-instance:secret:my_secret:username}"
    organization: "${nr-vault:remote:my_mount:my_path:organization}"

Neste exemplo:

O espaço reservado ${nr-vault:local-instance:secret:my_secret:username} instrui o agente de controle a recuperar o valor associado à chave username do segredo no caminho secret/my_secret usando a fonte do vault local-instance. O espaço reservado ${nr-vault:remote:my_mount:my_path:organization} também recupera o valor da chave da organização da fonte remota.

Após a recuperação bem-sucedida, o controle do agente renderiza esses segredos da origem e do caminho especificados, armazenando o resultado em um segredo do K8s ou em um arquivo de configuração privado para uso pelo agente correspondente.

Segredos do cofre

Configure as fontes do vault com as seguintes configurações:

No arquivo de configuração, cada segredo armazenado no Vault pode ser acessado definindo um espaço reservado com:

• source_name: O nome da origem do Vault definida em secrets_providers.
• mount: O nome da montagem do mecanismo secreto.
• path: O caminho específico para o segredo.
• specific key: a chave específica dentro do segredo a ser recuperada.

Exemplo de formato de espaço reservado completo:

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

Segredos do Kubernetes

Se o pod de controle do agente tiver permissões, como por meio de uma conta de serviço e controle de acesso baseado em função (RBAC), para acessar os segredos e o namespace necessários, o controle do agente poderá acessar os segredos diretamente da API Kubernetes sem precisar de uma configuração de fontes separada.

No arquivo de configuração do agente, recupere cada valor secreto usando um espaço reservado especificando:

• namespace: o namespace do Kubernetes onde o segredo está localizado.
• name: O nome do objeto secreto do Kubernetes.
• specific key: a chave específica dentro do segredo da qual recuperar o valor.

Por exemplo, use o formato de espaço reservado:

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

Configuração de repositório privado

O agente Control suporta a configuração do repositório Helm privado para implantar o próprio agente Control e o agente gerenciado. Isso permite ambientes onde os gráficos do New Relic Helm não são diretamente acessíveis.

1. Habilite repositório privado para agente

Por razões de segurança, somente o repositório explicitamente habilitado será permitido na configuração remota. Para habilitar repositório específico, é necessário atualizar a configuração do agente 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
    # ...

A configuração do repositório permitida pode então ser usada em sua configuração remota dentro do New Relic Control. Exemplo:

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

Além disso, você precisa configurar a instalação Helm do agente Control para usar seu repositório privado se o próprio gráfico agent-control-bootstrap estiver em um repositório privado. Isso é separado da configuração do agente gerenciado. Consulte agent-control-bootstrap Helm chart values.yaml para configurar a seção installationJob. Especificamente:

• chartRepositoryUrl contendo a URL do seu repositório
• name se estiver usando um nome de gráfico diferente
• repositorySecretReferenceName e repositoryCertificateSecretReferenceName para autenticação (veja a seção de autenticação abaixo para detalhes)

2. Configure autenticação para repositório privado

Você precisa configurar recursos adicionais para habilitar a autenticação para acessar seu repositório privado:

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

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

Configuração Linux

Estes são os caminhos padrão para configuração do agente Control:

• Local arquivo de configuração: /etc/newrelic-agent-control/config.yaml
• Remote arquivo de configuração: /var/lib/newrelic-agent-control/config.yaml (se habilitado via Controle de Agentes de implantação)
• Definição de serviço: /lib/systemd/system/newrelic-agent-control.service
• Arquivo de ambiente de serviço: /etc/newrelic-agent-control/newrelic-agent-control.conf

Por padrão, o agente pode orquestrar o agente de infraestrutura e o coletor OpenTelemetry:

# Configures the integration with Fleet Control
fleet_control:
  # EU region? Use: https://opamp.service.eu.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
    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/io.opentelemetry.collector:0.1.0"

Você pode renomear ou remover qualquer agente com base em seus requisitos de observabilidade. O nome do agente deve ser um nome de rótulo RFC-1035 válido.

Você também pode usar variáveis de ambiente para definir as configurações do agente:

• Use o prefixo NR_ (sublinhado único) para destino da configuração de controle do agente principal.
• Use __ (sublinhados duplos) para direcionar as configurações disponíveis no agente Control. Isso é necessário para evitar colisões com chaves de configuração que contêm sublinhados.
• Variáveis de ambiente só têm precedência sobre o arquivo de configuração local. Se a configuração remota estiver habilitada, as variáveis de ambiente não serão consideradas.
• Por exemplo, para definir uma configuração dinâmica para o fleet_control::endpoint, adicione o NR_FLEET_CONTROL__ENDPOINT=https://opamp.service.newrelic.com/v1/opamp no arquivo de definição de serviço.

Configurar agentes

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/io.opentelemetry.collector:0.1.0"

Você pode renomear ou remover qualquer agente com base em seus requisitos de observabilidade. O nome do agente deve ser um nome de rótulo RFC-1035 válido.

Você também pode usar variáveis de ambiente para definir as configurações do agente:

• Use o prefixo NR_ (sublinhado único) para destino da configuração de controle do agente principal.
• Use __ (sublinhados duplos) para direcionar as configurações disponíveis no agente Control. Isso é necessário para evitar colisões com chaves de configuração que contêm sublinhados.
• Variáveis de ambiente só têm precedência sobre o arquivo de configuração local. Se a configuração remota estiver habilitada, as variáveis de ambiente não serão consideradas.
• Por exemplo, para definir uma configuração dinâmica para o fleet_control::endpoint, adicione o NR_FLEET_CONTROL__ENDPOINT=https://opamp.service.newrelic.com/v1/opamp no arquivo de definição de serviço.

Configurar o agente

O agente Control pode atualmente gerenciar os seguintes tipos de agentes predefinidos no host:

• Agente New Relic Infrastructure: newrelic/com.newrelic.infrastructure. Todos os recursos existentes no agente de infraestrutura são suportados, incluindo orquestração de integração no host e nosso encaminhador de integração de logs baseado em FluentBit.
• Distribuição New Relic para OpenTelemetry: newrelic/io.opentelemetry.collector

Cada tipo de agente oferece um conjunto de variáveis opcionais que podem ser personalizadas para adaptar seu comportamento. Para personalizar a configuração local do agente:

1. Crie um arquivo values.yml : Este arquivo conterá os valores de configuração desejados.
2. Coloque o arquivo values.yml no diretório /etc/newrelic-agent-control/fleet/agents.d/YOUR-AGENT-NAME/values/. Aqui, YOUR-AGENT-NAME é o nome real do seu agente (por exemplo, nr-infra-agent).

Aqui está uma lista de variáveis disponíveis para as versões mais recentes do tipo de agente:

• Agente New Relic Infrastructure: 0.1.0
• Distribuição New Relic para OpenTelemetry: 0.1.0

Configuração de amostra

Configuração Remota com Controle de Agentes

Os exemplos a seguir contêm casos de uso comuns que estão prontos para copiar e colar como configuração válida para o agente de controle e o agente gerenciado.

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

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]

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