Como configurar o agente de operações

Neste docuento, fornecemos detalhes sobre as configurações padrão e personalizadas do agente de operações. Leia este documento se alguma das seguintes situações se aplicar 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 métricas service.

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 uma 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: coleta registros fazendo o acompanhamento de arquivos no disco.
  • syslog: colete o syslog por TCP ou UDP.
  • tcp (disponível na versão 2.3.0 e mais recentes do agente de operações): coletar registros no formato JSON ouvindo uma porta TCP.
  • windows_event_log (somente Windows): colete os registros de eventos do Windows.
  • systemd_journald (disponível com o agente do Ops versões 2.4.0 e posteriores no Linux): colete registros do serviço systemd-journald.

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:

  • Recebedores 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 a include_paths.

  • Recebedores 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.

  • Recebedores tcp:

    • format: obrigatório. Formato do 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]

Amostra de receptor systemd_journald:

receivers:
  RECEIVER_ID:
    type: systemd_journald

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 um 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 adequadamente. 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 para as 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/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 personaliza o detalhamento dos registros do agente de operações e vincula os receptores e processadores de geração de registros aos pipelines. A seção service tem dois elementos: log_level e pipelines.

Nível de detalhamento do registro

log_level, disponível nas versões 2.6.0 e posteriores do agente de operações, personaliza o verbosidade dos registros do submódulo de geração de registros do agente de operações. O padrão é info. As opções disponíveis são: error, warn, info, debug, trace.

Pipelines de geração de registros

pipelines pode conter várias definições e IDs 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.

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

Uma configuração service tem a seguinte estrutura:

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

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:

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

A seguinte configuração de service personaliza o detalhamento de registro para que o submódulo de geração de registros seja debug:

logging:
  service:
    log_level: debug

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
jetty /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
puppet /var/log/puppet/http.log
/var/log/puppet/masterhttp.log
puppet-enterprise /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
rabbitmq /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
salt /var/log/salt/key
/var/log/salt/master
/var/log/salt/minion
/var/log/salt/syndic.loc
solr /var/log/solr/*.log
sugarcrm /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 uma 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 no Windows)
  • mssql (Somente no 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 rótulo para o dispositivo.
Bytes de disco gravados, com rótulo para o dispositivo.
Tempo de E/S de disco, com rótulo para o dispositivo.
Tempo de E/S medido do disco, 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 o dispositivo e a direção.
Tempo de operação do disco, com rótulos para o dispositivo e a direção.
Uso do disco, com rótulos para o dispositivo e o estado.
Utilização do disco, com rótulos para o dispositivo e o estado.
interface
Somente no 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
Atualmente, conexões abertas para IIS
Bytes de rede transferidos por IIS
Conexões abertas ao 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
Atualmente, conexões abertas para o SQL Server
Total de transações por segundo do SQL Server
Transações de gravação por segundo do SQL Server

Operadores 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 personaliza o detalhamento dos registros do módulo de métricas do agente de operações e vincula receptores e processadores de métricas a pipelines. A seção service tem dois elementos: log_level e pipelines.

Nível de detalhamento de métricas

log_level, disponível nas versões 2.6.0 e posteriores do agente de operações, personaliza o verbosidade dos registros do submódulo de métricas do agente de operações. O padrão é info. As opções disponíveis são: error, warn, info, debug.

Pipelines de métricas

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.

Exemplo de configurações service de métricas

Uma configuração service tem a seguinte estrutura:

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

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

A seguinte configuração de service personaliza o detalhamento de registro para o submódulo de métricas como debug:

metrics:
  service:
    log_level: debug