Como configurar o agente de operações

Neste documento, fornecemos detalhes sobre as configurações padrão e personalizadas do agente de operações. Leia este documento se uma das seguintes situações se aplica a você:

Modelo de configuração

O agente de operações usa uma configuração padrão integrada. não é possível modificar diretamente essa configuração integrada. Em vez disso, você cria um arquivo de modificações mescladas com a configuração integrada quando o agente é reiniciado.

Os elementos básicos da configuração são os seguintes:

  • receivers: esse elemento descreve o que é coletado pelo agente.
  • processors: esse elemento descreve como o agente pode modificar as informações coletadas.
  • service: esse elemento vincula receptores e processadores para criar fluxos de dados, chamados de pipelines. O elemento service contém um elemento pipelines, que pode conter vários pipelines.

A configuração integrada é composta desses elementos, e você usa os mesmos elementos para modificar essa configuração integrada.

Configuração integrada

A configuração integrada do agente de operações define a coleção padrão para registros e métricas. Veja a seguir a configuração integrada para Linux e Windows:

Linux

Por padrão, o agente de operações coleta registros syslog baseados em arquivos e métricas de host.

Para mais informações sobre as métricas coletadas, consulte Métricas ingeridas pelos tipos de receptor.

logging:
  receivers:
    syslog:
      type: files
      include_paths:
      - /var/log/messages
      - /var/log/syslog
  service:
    pipelines:
      default_pipeline:
        receivers: [syslog]
metrics:
  receivers:
    hostmetrics:
      type: hostmetrics
      collection_interval: 60s
  processors:
    metrics_filter:
      type: exclude_metrics
      metrics_pattern: []
  service:
    pipelines:
      default_pipeline:
        receivers: [hostmetrics]
        processors: [metrics_filter]

Windows

Por padrão, o agente de operações coleta logs de eventos do Windows dos canais System, Application e Security, além de métricas de host, métricas de IIS e métricas do SQL Server.

Para mais informações sobre as métricas coletadas, consulte Métricas ingeridas pelos tipos de receptor.

logging:
  receivers:
    windows_event_log:
      type: windows_event_log
      channels: [System, Application, Security]
  service:
    pipelines:
      default_pipeline:
        receivers: [windows_event_log]
metrics:
  receivers:
    hostmetrics:
      type: hostmetrics
      collection_interval: 60s
    iis:
      type: iis
      collection_interval: 60s
    mssql:
      type: mssql
      collection_interval: 60s
  processors:
    metrics_filter:
      type: exclude_metrics
      metrics_pattern: []
  service:
    pipelines:
      default_pipeline:
        receivers: [hostmetrics, iis, mssql]
        processors: [metrics_filter]

Essas configurações são discutidas em mais detalhes em Configuração do Logging e Configuração de métricas.

Configuração especificada pelo usuário

Para modificar a configuração integrada, adicione novos elementos ao arquivo de configuração do usuário. Coloque a configuração no agente de operações nos seguintes arquivos:

  • No Linux: /etc/google-cloud-ops-agent/config.yaml.

  • Para Windows: C:\Program Files\Google\Cloud Operations\Ops Agent\config\config.yaml.

Qualquer configuração especificada pelo usuário é mesclada com a configuração integrada quando o agente é reiniciado.

Para modificar um receptor, processador ou pipeline integrado, redefina-o no arquivo config.yaml declarando-o com o mesmo identificador.

Por exemplo, a configuração integrada de métricas inclui um receptor hostmetrics que especifica um intervalo de coleta de 60 segundos. Para alterar o intervalo de coleta de métricas do host para 30 segundos, inclua um receptor de métricas chamado hostmetrics no arquivo config.yaml que define o valor collection_interval como 30 segundos, como mostrado no exemplo a seguir:

metrics:
  receivers:
    hostmetrics:
      type: hostmetrics
      collection_interval: 30s

Para outros exemplos de como alterar as configurações integradas, consulte Configuração do Logging e Configuração de métricas.

Também é possível desativar a coleta de dados de geração de registros ou métricas. Essas alterações são descritas no exemplo de configurações de service de geração de registros e configurações de servicemétricas.

Configurações de geração de registros

A configuração logging usa o modelo de configuração descrito anteriormente:

  • receivers: esse elemento descreve os dados a serem coletados dos arquivos de registros. Esses dados são mapeados em um modelo de <timestamp, record>.
  • processors: esse elemento opcional descreve como o agente pode modificar as informações coletadas.
  • service: esse elemento vincula receptores e processadores para criar fluxos de dados, chamados de pipelines. O elemento service contém um elemento pipelines, que pode incluir várias definições de pipeline.

Cada receptor e cada processador podem ser usados em vários pipelines.

As seções a seguir descrevem cada um desses elementos.

Receptores de geração de registro

O elemento receivers contém um conjunto de receptores, cada um identificado por um RECEIVER_ID. Um receptor descreve como recuperar os registros. por exemplo, fazendo o acompanhamento de arquivos com uma porta TCP ou do log de eventos do Windows.

Estrutura de receptores de registro

Cada receptor precisa ter um identificador RECEIVER_ID e incluir um elemento type. Os tipos válidos são:

  • files
  • syslog
  • tcp (disponível nas versões 2.3.0 e posteriores do agente de operações)
  • windows_event_log (somente para Windows)

A estrutura receivers tem a seguinte aparência:

receivers:
  RECEIVER_ID:
    type: files
    ...
  RECEIVER_ID_2:
    type: syslog
    ...

Dependendo do valor do elemento type, pode haver outras opções de configuração, da seguinte maneira:

  • Receptores files:

    • include_paths: obrigatório. Uma lista de caminhos do sistema de arquivos a serem lidos acompanhando cada arquivo. Um caractere curinga (*) pode ser usado nos caminhos. por exemplo, /var/log/*.log.

      Para ver uma lista de arquivos de registros comuns de aplicativos, consulte Arquivos de registros comuns.

    • exclude_paths: opcional. Uma lista de padrões de caminho do sistema de arquivos a serem excluídos do conjunto correspondente por include_paths.

  • Receptores syslog:

    • transport_protocol: opcional. Valores aceitos: tcp, udp. O padrão é tcp.

      Se o valor de transport_protocol for tcp, as seguintes opções extras poderão ser usadas:

      • listen_host: opcional. Um endereço IP para detectar. O valor padrão é 0.0.0.0.

      • listen_port: opcional. Uma porta a ser detectada. O valor padrão é 5140.

  • Receptores tcp:

    • format: obrigatório. Formato de registro. Valor compatível: json.

    • listen_host: opcional. Um endereço IP para detectar. O valor padrão é 127.0.0.1.

    • listen_port: opcional. Uma porta a ser detectada. O valor padrão é 5170.

  • Receptores windows_event_log (somente para Windows):

    • channels: obrigatório. Uma lista de canais do log de eventos do Windows em que os registros são lidos.

Exemplos de receptores de registro

Amostra de receptor files:

receivers:
  RECEIVER_ID:
    type: files

    include_paths: [/var/log/*.log]
    exclude_paths: [/var/log/not-this-one.log]

Amostra de receptor syslog:

receivers:
  RECEIVER_ID:
    type: syslog

    transport_protocol: tcp
    listen_host: 0.0.0.0
    listen_port: 5140

Amostra de receptor tcp:

receivers:
  RECEIVER_ID:
    type: tcp

    format: json
    listen_host: 127.0.0.1
    listen_port: 5170

Amostra de receptor windows_event_log (somente Windows):

receivers:
  RECEIVER_ID:
    type: windows_event_log

    channels: [System,Application,Security]

Processadores de geração de registros

O elemento opcional processors contém um conjunto de diretivas de processamento, cada uma identificada por um PROCESSOR_ID. Um processador descreve como manipular as informações coletadas por um receptor.

Estrutura de processadores de geração de registros

Cada processador precisa ter um identificador exclusivo e incluir um elemento type. Os tipos válidos são:

  • parse_json
  • parse_regex

A estrutura processors tem a seguinte aparência:

processors:
  PROCESSOR_ID:
    type: parse_json
    ...
  PROCESSOR_ID_2:
    type: parse_regex
    ...

Dependendo do valor do elemento type, há outras opções de configuração, da seguinte maneira:

  • Os processadores parse_json e parse_regex:

    • field: opcional. O nome do campo no registro a ser analisado. Se a opção field não for especificada, o processador analisará o campo message.

    • time_key: opcional. Se a entrada de registro fornecer um campo com carimbo de data/hora, essa opção especificará o nome desse campo. O valor extraído é usado para definir o campo timestamp do LogEntry resultante e é removido do payload.

      Se a opção time_key for especificada, você também precisará especificar o seguinte:

      • time_format: obrigatório se time_key for usado. Essa opção especifica o formato do campo time_key para que ele possa ser reconhecido e analisado corretamente. Para detalhes sobre o formato, consulte o guia strptime(3).
  • Processadores parse_regex:

    • regex: obrigatório. A expressão regular para analisar o campo. A expressão precisa incluir nomes de chave das subexpressões correspondentes. Por exemplo, "^(?<time>[^ ]*) (?<severity>[^ ]*) (?<msg>.*)$".

      Para um conjunto de expressões regulares para extrair informações de arquivos de registro, consulte Arquivos de registro comuns.

Exemplos de processadores de registros

Exemplo de processador parse_json:

processors:
  PROCESSOR_ID:
    type: parse_json

    field:       message
    time_key:    time
    time_format: "%Y-%m-%dT%H:%M:%S.%L%Z"

Exemplo de processador parse_regex:

processors:
  PROCESSOR_ID:
    type: parse_regex

    field:       message
    regex:       "^(?<time>[^ ]*) (?<severity>[^ ]*) (?<msg>.*)$"
    time_key:    time
    time_format: "%Y-%m-%dT%H:%M:%S.%L%Z"

Campos especiais em payloads estruturados

É possível definir campos específicos no objeto LogEntry que o agente grava na API Logging. Nos registros estruturados, o agente de operações remove os campos listados na tabela a seguir da estrutura jsonPayload:

Campo de registro Campo LogEntry

Opção 1



"timestamp": {
  "seconds": CURRENT_SECONDS,
  "nanos": CURRENT_NANOS,
}

Opção 2



{
  "timestampSeconds": CURRENT_SECONDS,
  "timestampNanos": CURRENT_NANOS,
}
timestamp
receiver_id (não é um campo de registro) logName
logging.googleapis.com/httpRequest httpRequest
logging.googleapis.com/severity severity
logging.googleapis.com/labels labels
logging.googleapis.com/operation operation
logging.googleapis.com/sourceLocation sourceLocation

Todos os campos de registros estruturados restantes permanecem como parte da estrutura jsonPayload.

Serviço da geração de registros

O serviço de geração de registros vincula os receptores e os processadores de registros aos pipelines.

A seção service tem um único elemento, pipelines, que pode conter vários IDs e definições de pipeline. Cada definição de pipeline consiste nos seguintes elementos:

  • receivers: obrigatório para novos pipelines. Uma lista de IDs de receptor, conforme descrito em Receptores de geração de registros. A ordem dos IDs dos receptores na lista não importa. O pipeline coleta dados de todos os receptores listados.

  • processors: opcional. Uma lista de IDs de processador, conforme descrito em Processadores de registro. A ordem dos IDs do processador na lista importa. Cada registro é executado pelos processadores na ordem listada.

Uma configuração service tem a seguinte estrutura:

service:
  pipelines:
    PIPELINE_ID:
      receivers:  [...]
      processors: [...]
    PIPELINE_ID_2:
      receivers:  [...]
      processors: [...]

Exemplo de configurações da geração de registros do service

Para desativar a ingestão de registros integrada, redefina o pipeline padrão com uma lista receivers vazia e sem processadores. Toda a configuração de geração de registros tem a seguinte aparência:

logging:
  service:
    pipelines:
      default_pipeline:
        receivers: []

A configuração a seguir service define um pipeline com o ID custom_pipeline:

service:
  pipelines:
    custom_pipeline:
      receivers:
      - RECEIVER_ID
      processors:
      - PROCESSOR_ID

Arquivos de registros comuns

A tabela a seguir lista arquivos de registros comuns para aplicativos usados com frequência:

Aplicativo Arquivos de registros comuns
Apache /var/log/apache*/access.log
/var/log/httpd/access_log
/var/log/apache*/error.log
/var/log/httpd/error_log
cassandra /var/log/cassandra/cassandra.log
/var/log/cassandra/output.log
/var/log/cassandra/system.log
Chef /var/log/chef-server/bookshelf/current
/var/log/chef-server/chef-expander/current
/var/log/chef-server/chef-pedant/http-traffic.log
/var/log/chef-server/chef-server-webui/current
/var/log/chef-server/chef-solr/current
/var/log/chef-server/erchef/current
/var/log/chef-server/erchef/erchef.log.1
/var/log/chef-server/nginx/access.log
/var/log/chef-server/nginx/error.log
/var/log/chef-server/nginx/rewrite-port-80.log
/var/log/chef-server/postgresql/current
Gitlab /home/git/gitlab/log/application.log
/home/git/gitlab/log/githost.log
/home/git/gitlab/log/production.log
/home/git/gitlab/log/satellites.log
/home/git/gitlab/log/sidekiq.log
/home/git/gitlab/log/unicorn.stderr.log
/home/git/gitlab/log/unicorn.stdout.log
/home/git/gitlab-shell/gitlab-shell.log
Jenkins /var/log/jenkins/jenkins.log
píer /var/log/jetty/out.log
/var/log/jetty/*.request.log
/var/log/jetty/*.stderrout.log
Joomla /var/www/joomla/logs/*.log
Magento /var/www/magento/var/log/exception.log
/var/www/magento/var/log/system.log
/var/www/magento/var/report/*
mediawiki /var/log/mediawiki/*.log
memcached /var/log/memcached.log
mongodb /var/log/mongodb/*.log
mysql /var/log/mysql.log
/var/log/mysql/mysql.log
/var/log/mysql/mysql-slow.log
nginx /var/log/nginx/access.log
/var/log/nginx/error.log
Postgres /var/log/postgres*/*.log
/var/log/pgsql/*.log
boneco /var/log/puppet/http.log
/var/log/puppet/masterhttp.log
boneco /var/log/pe-activemq/activemq.log
/var/log/pe-activemq/wrapper.log
/var/log/pe-console-auth/auth.log
/var/log/pe-console-auth/cas_client.log
/var/log/pe-console-auth/cas.log
/var/log/pe-httpd/access.log
/var/log/pe-httpd/error.log
/var/log/pe-httpd/other_vhosts_access.log
/var/log/pe-httpd/puppetdashboard.access.log
/var/log/pe-httpd/puppetdashboard.error.log
/var/log/pe-httpd/puppetmasteraccess.log
/var/log/pe-mcollective/mcollective_audit.log
/var/log/pe-mcollective/mcollective.log
/var/log/pe-puppet-dashboard/certificate_manager.log
/var/log/pe-puppet-dashboard/event-inspector.log
/var/log/pe-puppet-dashboard/failed_reports.log
/var/log/pe-puppet-dashboard/live-management.log
/var/log/pe-puppet-dashboard/mcollective_client.log
/var/log/pe-puppet-dashboard/production.log
/var/log/pe-puppetdb/pe-puppetdb.log
/var/log/pe-puppet/masterhttp.log
/var/log/pe-puppet/rails.log
rabbitdb /var/log/rabbitmq/*.log
/var/log/rabbitmq/*-sasl.log
/var/log/rabbitmq/startup_err
/var/log/rabbitmq/startup_log
redis /var/log/redis*.log
/var/log/redis/*.log
redmine /var/log/redmine/*.log
sal /var/log/salt/key
/var/log/salt/master
/var/log/salt/minion
/var/log/salt/syndic.loc
Solr /var/log/solr/*.log
açúcar /var/www/*/sugarcrm.log
syslog /var/log/syslog/var/log/messages
tomcat /var/log/tomcat*/catalina.out
/var/log/tomcat*/localhost.*.log
/var/log/tomcat*/localhost_access_log.%Y-%m-%d.txt
zookeeper /var/log/zookeeper/zookeeper.log
/var/log/zookeeper/zookeeper_trace.log

A tabela a seguir lista algumas expressões regulares que são úteis para analisar registros:

Aplicativo Expressão regular
Apache ^(?<host>[^ ]*) [^ ]* (?<user>[^ ]*) \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^\"]*?)(?: +\S*)?)?" (?<code>[^ ]*) (?<size>[^ ]*)(?: "(?<referer>[^\"]*)" "(?<agent>[^\"]*)")?$
Apache2 ^(?<host>[^ ]*) [^ ]* (?<user>[^ ]*) \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^ ]*) +\S*)?" (?<code>[^ ]*) (?<size>[^ ]*)(?: "(?<referer>[^\"]*)" "(?<agent>.*)")?$
apache_error ^\[[^ ]* (?<time>[^\]]*)\] \[(?<level>[^\]]*)\](?: \[pid (?<pid>[^\]]*)\])?( \[client (?<client>[^\]]*)\])? (?<message>.*)$
mongodb ^(?<time>[^ ]*)\s+(?<severity>\w)\s+(?<component>[^ ]+)\s+\[(?<context>[^\]]+)]\s+(?<message>.*?) *(?<ms>(\d+))?(:?ms)?$
nginx ^(?<remote>[^ ]*) (?<host>[^ ]*) (?<user>[^ ]*) \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^\"]*?)(?: +\S*)?)?" (?<code>[^ ]*) (?<size>[^ ]*)(?: "(?<referer>[^\"]*)" "(?<agent>[^\"]*)")

Configurações das métricas

A configuração metrics usa o modelo de configuração descrito anteriormente:

  • receivers: uma lista de definições de receptor. Um receiver descreve a origem das métricas; por exemplo, métricas do sistema, como cpu ou memory. Os receptores nesta lista podem ser compartilhados entre vários pipelines.
  • processors: uma lista de definições de processador. Um processor descreve como modificar as métricas coletadas por um receptor.
  • service: contém uma seção de pipelines que é uma lista de definições de pipeline. Um pipeline conecta uma lista de receivers a uma lista de processors para formar o fluxo de dados.

As seções a seguir descrevem cada um desses elementos.

Receptores de métricas

O elemento receivers contém um conjunto de definições de receptor. Um receptor descreve de onde recuperar as métricas, como cpu e memory. Um receptor pode ser compartilhado entre vários pipelines.

Estrutura de receptores de métricas

Cada receptor precisa ter um identificador RECEIVER_ID e incluir um elemento type. Os tipos válidos são:

  • hostmetrics
  • iis (somente para Windows)
  • mssql (somente para Windows)

Um receptor também pode especificar a opção collection_interval da operação. O valor está no formato de duração, por exemplo, 30s ou 2m. O valor padrão é 60s.

Cada um desses tipos de receptor coleta um conjunto de métricas: Para informações sobre as métricas específicas incluídas, consulte Métricas ingeridas pelos tipos de receptor.

É possível criar apenas um receptor para cada tipo. Por exemplo, não é possível definir dois receptores do tipo hostmetrics.

Como alterar o intervalo de coleta nos receptores de métricas

Algumas cargas de trabalho críticas podem exigir alertas rápidos. Ao reduzir o intervalo de coleta das métricas, é possível configurar alertas mais confidenciais. Para mais informações sobre como os alertas são avaliados, consulte Comportamento de alertas.

Por exemplo, o receptor a seguir altera o intervalo de coleta de métricas do host (o ID do receptor é hostmetrics) do padrão de 60 segundos para 10 segundos:

metrics:
  receivers:
    hostmetrics:
      type: hostmetrics
      collection_interval: 10s

Você também pode modificar o intervalo de coleta para receptores de métricas iis e mssql do Windows usando a mesma técnica.

Métricas ingeridas pelos receptores

As métricas ingeridas pelo agente de operações têm identificadores que começam com o seguinte padrão: agent.googleapis.com/GROUP. O componente GROUP identifica um conjunto de métricas relacionadas; tem valores como cpu, network e outros.

O receptor hostmetrics processa os seguintes grupos de métricas. Para mais informações, consulte a seção vinculada para cada grupo na página Métricas do agente de operações.

Grupo Métrica
cpu Carga da CPU em intervalos de 1 minuto.
Carga da CPU em intervalos de 5 minutos.
Carga da CPU em intervalos de 15 minutos.
Uso da CPU, com rótulos para o número da CPU e o estado da CPU.
Porcentagem de uso da CPU, com rótulos para o número da CPU e o estado da CPU
disk Bytes de disco lidos, com o marcador para o dispositivo
Bytes de disco gravados, com o marcador para o dispositivo
Tempo de E/S do disco, com o marcador para o dispositivo
I ponderado do disco Tempo/O, com rótulo para o dispositivo
Operações de disco pendentes, com rótulo para o dispositivo
Operações de disco mescladas, com rótulos para o dispositivo e a direção
Operações de disco com rótulos para dispositivo e direção
Tempo de operação do disco, com rótulos para dispositivo e direção
Uso do disco, com rótulos para o dispositivo e o estado
Utilização do disco, com rótulos por dispositivo e estado
interface
Somente Linux
Contagem total de erros de rede
Contagem total de pacotes enviados pela rede
Número total de bytes enviados pela rede
memory Uso de memória, com rótulo para o estado (armazenado em buffer, armazenado em cache, disponível, slab, usado).
Porcentagem de uso de memória, com rótulo para o estado (armazenado em buffer, armazenado em cache, disponível, slab, usado).
network Contagem de conexão TCP, com rótulos de porta e estado TCP.
swap Operações de E/S de troca, com o rótulo para a direção.
Bytes de troca usados, com rótulos para o dispositivo e o estado.
Porcentagem de troca usada, com rótulos para o dispositivo e o estado.
pagefile
Somente no Windows
Porcentagem atual do arquivo de paginação usado pelo estado
processes Contagem de processos, com rótulo para o estado.
Contagem de processos bifurcados.
E/S de leitura de disco por processo, com rótulos para o nome do processo + outros
Por processo E/S de gravação de disco, com rótulos para o nome do processo + outros
Uso de RSS por processo, com rótulos para o nome do processo + outros
Uso de VM por processo, com rótulos para o processo nome + outros

O receptor iis (somente para Windows) ingere as métricas do grupo iis. Para mais informações, consulte a página Métricas do agente.

Grupo Métrica
iis
Somente no Windows
Conexões abertas do IIS no momento
Bytes de rede transferidos pelo IIS
Conexões abertas no IIS
Solicitações feitas ao IIS

O receptor mssql (somente para Windows) ingere métricas do grupo mssql. Para mais informações, consulte a página Métricas do agente de operações.

Grupo Métrica
mssql
Somente no Windows
Conexões abertas atualmente com o SQL Server
Total de transações por segundo do servidor SQL
Transações de gravação por segundo do servidor SQL

Processadores de métricas

O elemento processor contém um conjunto de definições de processador. Um processador descreve as métricas do tipo receptor a serem excluídas. O único tipo compatível é exclude_metrics, que usa uma opção metrics_pattern. O valor é uma lista de globs que correspondem aos tipos de métricas que você quer excluir do grupo coletado por um receptor: por exemplo, agent.googleapis.com/cpu/* ou agent.googleapis.com/processes/*. Para encontrar os nomes totalmente qualificados de métricas individuais, consulte a tabela do grupo na página Métricas do agente de operações.

Exemplo de processador de métricas

O exemplo a seguir mostra o processador exclude_metrics fornecido nas configurações integradas. Esse processador fornece um valor metrics_pattern vazio para que ele não exclua nenhuma métrica.

processors:
  metrics_filter:
    type: exclude_metrics
    metrics_pattern: []

Para desativar a coleta de todas as métricas de processo pelo agente de operações, adicione o seguinte ao arquivo config.yaml:

metrics:
  processors:
    metrics_filter:
      type: exclude_metrics
      metrics_pattern:
      - agent.googleapis.com/processes/*

Isso exclui as métricas de processo da coleta no processador metrics_filter que se aplica ao pipeline padrão no serviço metrics.

Serviço de métricas

O serviço de métricas vincula receptores e processadores de métricas a pipelines.

A seção service tem um único elemento, pipelines, que pode conter vários IDs e definições de pipeline. Cada definição de pipeline consiste nos seguintes elementos:

  • receivers: obrigatório para novos pipelines. Uma lista de IDs de receptor, conforme descrito em Receptores de métricas. A ordem dos IDs dos receptores na lista não importa. O pipeline coleta dados de todos os receptores listados.

  • processors: opcional. Uma lista de IDs de processador, conforme descrito em Processadores de métricas. A ordem dos IDs do processador na lista importa. Cada ponto de métrica é executado pelos processadores na ordem listada.

Uma configuração service tem a seguinte estrutura:

service:
  pipelines:
    PIPELINE_ID:
      receivers:  [...]
      processors: [...]
    PIPELINE_ID_2:
      receivers:  [...]
      processors: [...]

Exemplo de configurações service de métricas

Para desativar a ingestão integrada de métricas do host, redefina o pipeline padrão com uma lista receivers vazia e sem processadores. Toda a configuração de métricas é semelhante a esta:

metrics:
  service:
    pipelines:
      default_pipeline:
        receivers: []

O exemplo a seguir mostra a configuração integrada service para Windows:

metrics:
  service:
    pipelines:
      default_pipeline:
        receivers:
        - hostmetrics
        - iis
        - mssql
        processors:
        - metrics_filter