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

O agente de operações também fornece instruções de configuração para coletar métricas e registros de aplicativos de terceiros compatíveis. Consulte Como monitorar aplicativos de terceiros para ver a lista de aplicativos compatíveis.

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.
  • fluent_forward (disponível nas versões 2.12.0 e posteriores do agente de operações): coletar registros enviados pelo protocolo Fluent Forward via TCP.
  • 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.
  • Receptores de registros de aplicativos de terceiros

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 (Linux) ou C:\logs\*.log (Windows).

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

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

    • record_log_file_path: opcional. Se definido como true, o caminho para o arquivo específico de que o registro de registro foi recebido aparecerá na entrada de registro de saída como o valor do identificador agent.googleapis.com/log_file_path. Ao usar um caractere curinga, apenas o caminho do arquivo de que o registro foi recebido é gravado.

    • wildcard_refresh_interval: opcional. O intervalo em que os caminhos de arquivo curinga em include_paths são atualizados. Dada como duração, por exemplo, 30s, 2m. Essa propriedade pode ser útil com capacidades de registro altas em que os arquivos de registro são alternados mais rapidamente do que o intervalo padrão. Se não for especificado, o intervalo padrão será de 60 segundos.

  • Recebedores fluent_forward:

    • 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 é 24224.

  • Recebedores syslog:

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

      É possível usar as seguintes opções adicionais:

      • 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]
    record_log_file_path: true

Amostra de receptor fluent_forward:

receivers:
  RECEIVER_ID:
    type: fluent_forward

    listen_host: 127.0.0.1
    listen_port: 24224

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

Campos especiais em payloads estruturados

Para processadores e receptores que podem ingerir dados estruturados (os receptores fluent_forward e tcp e o processador parse_json), é possível definir campos especiais na entrada que serão mapeados para campos específicos. no objeto LogEntry que o agente grava na API Logging.

Quando o agente de operações recebe dados de registro estruturados externos, ele coloca campos de nível superior no campo jsonPayload do LogEntry, a menos que o nome do campo esteja listado na tabela a seguir:

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([string](/logging/docs/reference/v2/rest/v2/LogEntry#httprequest)) httpRequest
logging.googleapis.com/severity ([string](/logging/docs/reference/v2/rest/v2/LogEntry#logentrysourcelocation)) severity
logging.googleapis.com/labels (estrutura de string:string) labels
logging.googleapis.com/operation ([struct](/logging/docs/reference/v2/rest/v2/LogEntry#logentryoperation)) operation
logging.googleapis.com/sourceLocation ([struct](/logging/docs/reference/v2/rest/v2/LogEntry#logentrysourcelocation)) sourceLocation

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

Arquivos de registros comuns do Linux

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

Aplicativo Arquivos de registros comuns
apache Para informações sobre arquivos de registros do Apache, consulte Como monitorar aplicativos de terceiros: Apache Web Server.
cassandra Para mais informações sobre os arquivos de registros do Cassandra, consulte Como monitorar aplicativos de terceiros: Cassandra.
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 Para informações sobre os arquivos de registros do Memcached, consulte Como monitorar aplicativos de terceiros: Memcached.
mongodb Para mais informações sobre os arquivos de registros do MongoDB, consulte Como monitorar aplicativos de terceiros: MongoDB.
mysql Para informações sobre arquivos de registros do MySQL, consulte Como monitorar aplicativos de terceiros: MySQL.
nginx Para informações sobre arquivos de registros nginx, consulte Como monitorar aplicativos de terceiros: nginx.
postgres Para mais informações sobre os arquivos de registro do PostgreSQL, consulte Como monitorar aplicativos de terceiros: PostgreSQL.
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 Para informações sobre os arquivos de registros do RabbitMQ, consulte Como monitorar aplicativos de terceiros: RabbitMQ.
redis Para mais informações sobre arquivos de registros do Redis, consulte Como monitorar aplicativos de terceiros: Redis.
redmine /var/log/redmine/*.log
salt /var/log/salt/key
/var/log/salt/master
/var/log/salt/minion
/var/log/salt/syndic.loc
solr Para mais informações sobre os arquivos de registros do Apache Solr, consulte Como monitorar aplicativos de terceiros: Apache Solr.
sugarcrm /var/www/*/sugarcrm.log
syslog /var/log/syslog/var/log/messages
tomcat Para informações sobre os arquivos de registros do Apache Tomcat, consulte Como monitorar aplicativos de terceiros: Apache Tomcat.
zookeeper Para mais informações sobre os arquivos de registros do Apache ZooKeeper, consulte Como monitorar aplicativos de terceiros: Apache ZooKeeper.

Rótulos ingeridos padrão

Por padrão, os registros podem conter os seguintes identificadores em LogEntry:

Campo Valor de amostra Descrição
labels."compute.googleapis.com/resource_name" test_vm O nome da máquina virtual de origem do registro. Escrito para todos os registros.
labels."logging.googleapis.com/instrumentation_source" agent.googleapis.com/apache_access Valor do receptor type do qual se origina o registro, com prefixo agent.googleapis.com/. Escrito apenas pelos destinatários das integrações de terceiros.

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.

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

  • parse_json: analisa registros estruturados em formato JSON.
  • parse_multiline: analisa registros de várias linhas. Somente no Linux
  • parse_regex: analisa registros em formato de texto por meio de padrões regex para transformá-los em registros estruturados em formato JSON.
  • exclude_logs: exclui os registros que correspondem às regras especificadas (a partir da versão 2.9.0).
  • modify_fields: define/transforma campos em entradas de registro (a partir da versão 2.14.0).

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:

Processador parse_json

Estrutura da configuração

processors:
  PROCESSOR_ID:
    type: parse_json

    time_key:    <field name within jsonPayload>
    time_format: <strptime format string>

O processador parse_json analisa o JSON de entrada no campo jsonPayload de LogEntry. Outras partes de LogEntry podem ser analisadas configurando determinados campos especiais de nível superior.

  • 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).
Exemplo de configuração
processors:
  PROCESSOR_ID:
    type: parse_json

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

Processador parse_multiline

Estrutura da configuração

processors:
  PROCESSOR_ID:
    type: parse_multiline

    match_any:
    - type: <type of the exceptions>
      language: <language name>

  • match_any: obrigatório. Uma lista de uma ou mais regras

    • type: obrigatório. Somente um valor é compatível:

      • language_exceptions: permite que o processador concatene exceções em um LogEntry, com base no valor da opção language.

    • language: obrigatório. Somente um valor é compatível:

      • java: concatena exceções comuns do Java em uma LogEntry.
Exemplo de configuração
processors:
  PROCESSOR_ID:
    type: parse_multiline

    match_any:
    - type: language_exceptions
      language: java

Processador parse_regex

Estrutura da configuração

processors:
  PROCESSOR_ID:
    type: parse_regex

    regex: <regular expression>

    time_key:    <field name within jsonPayload>
    time_format: <format string>

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

  • 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>.*)$".

    O texto correspondente aos grupos de captura nomeados será colocado em campos no campo jsonPayload do LogEntry. Para adicionar mais estrutura aos registros, use o processador modify_fields.

    Para um conjunto de expressões regulares para extrair informações de arquivos de registros comuns de aplicativos do Linux, consulte Arquivos de registros comuns do Linux.

Exemplo de configuração
processors:
  PROCESSOR_ID:
    type: parse_regex

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

Processador exclude_logs

Estrutura da configuração:

type: exclude_logs
match_any:
  - <filter>
  - <filter>

A configuração de nível superior desse processador contém um único campo, match_any, que contém uma lista de regras de filtro.

  • match_any: obrigatório. Uma lista de uma ou mais regras Se uma entrada de registro corresponder a qualquer regra, o agente de operações não ingerirá essa entrada.

    Os registros ingeridos pelo agente de operações seguem a estrutura LogEntry. Os nomes dos campos diferenciam maiúsculas de minúsculas. Só é possível especificar regras com base nos seguintes campos e nos respectivos subcampos:

    • httpRequest
    • jsonPayload
    • labels
    • operation
    • severity
    • sourceLocation

    O exemplo de regra a seguir

    severity =~ "(DEBUG|INFO)"

    usa uma expressão regular para excluir todos os registros no nível DEBUG e INFO.

    As regras seguem a sintaxe da linguagem de consulta do Cloud Logging, mas são compatíveis apenas com um subconjunto de recursos compatíveis com essa linguagem:

    • Operadores de comparação: =, !=, :, =~, !~. Somente comparações de string são compatíveis.
    • Operador de navegação: .. Por exemplo, jsonPayload.message.
    • Operadores booleanos: AND, OR, NOT.
    • Agrupar expressões com ) (.

Exemplo de configuração

processors:
  PROCESSOR_ID:
    type: exclude_logs
    match_any:
    - '(jsonPayload.message =~ "log spam 1" OR jsonPayload.message =~ "log spam 2") AND severity = "ERROR"'
    - 'jsonPayload.application = "foo" AND severity = "INFO"'

Processador modify_fields

O processador modify_fields permite a personalização da estrutura e do conteúdo de entradas de registro.

Estrutura da configuração

type: modify_fields
fields:
  <destination field>:
    # Source
    move_from: <source field>
    copy_from: <source field>
    static_value: <string>

    # Mutation
    default_value: <string>
    map_values:
      <old value>: <new value>
    type: {integer|float}
    omit_if: <filter>

A configuração de nível superior desse processador contém um único campo, fields, que contém um mapa de nomes de campo de saída e traduções correspondentes. Para cada campo de saída, uma origem opcional e nenhuma ou mais operações de mutação são aplicadas.

Todos os nomes de campo usam a sintaxe separada por pontos da linguagem de consulta do Cloud Logging. Os filtros usam a linguagem de consulta do Cloud Logging.

Todas as transformações são aplicadas em paralelo, o que significa que as origens e os filtros operam na entrada de registro de entrada original e, portanto, não podem fazer referência ao novo valor de nenhum outro campo que esteja sendo modificado pelo mesmo processador.

Opções de origem: é permitida, no máximo, uma origem especificada.

  • Nenhuma origem especificada

    Se nenhum valor de origem for especificado, o valor existente no campo de destino será modificado.

  • move_from: <source field>

    O valor de <source field> será usado como origem para o campo de destino. Além disso, <source field> será removido da entrada de registro. Se um campo de origem for referenciado por move_from e copy_from, o campo de origem ainda será removido.

  • copy_from: <source field>

    O valor de <source field> será usado como origem para o campo de destino. <source field> não será removido da entrada de registro, a menos que também seja referenciado por uma operação move_from ou modificado.

  • static_value: <string>

    A string estática <string> será usada como origem para o campo de destino.

Opções de mutação: zero ou mais operadores de mutação podem ser aplicados a um único campo. Se forem fornecidos vários operadores, eles sempre serão aplicados na seguinte ordem.

  1. default_value: <string>

    Se o campo de origem não existir, o valor de saída será definido como <string>. Se o campo de origem já existir, mesmo que contenha uma string vazia, o valor original não será modificado.

  2. map_values: <map>

    Se o valor de entrada corresponder a uma das chaves em <map>, o valor de saída será substituído pelo valor correspondente do mapa.

  3. map_values_exclusive: {true|false}

    Caso<source field> não corresponda a nenhuma chave especificada nos pares map_values, o campo de destino será forçado a ser desativado se map_values_exclusive for verdadeiro ou permanece inalterado semap_values_exclusive é falso.

  4. type: {integer|float}

    O valor de entrada será convertido em um número inteiro ou um ponto flutuante. Se não for possível converter a string em um número, o valor de saída não será configurado. Se a string contiver um ponto flutuante, mas o tipo for especificado como integer, o número será truncado para um número inteiro.

    A API Cloud Logging usa JSON e, portanto, não é compatível com um número inteiro completo de 64 bits. Se um número inteiro de 64 bits (ou maior) for necessário, ele precisará ser armazenado como uma string na entrada de registro.

  5. omit_if: <filter>

    Se o filtro corresponder ao registro de entrada, o campo de saída será desativado. Isso pode ser usado para remover valores de marcador, como:

    httpRequest.referer:
  move_from: jsonPayload.referer
  omit_if: httpRequest.referer = "-"

Configurações de amostra

O processador parse_json transformaria um arquivo JSON com

{
  "http_status": "400",
  "path": "/index.html",
  "referer": "-"
}

em uma estrutura LogEntry com a seguinte aparência:

{
  "jsonPayload": {
    "http_status": "400",
    "path": "/index.html",
    "referer": "-"
  }
}

Isso poderia ser transformado com modify_fields neste LogEntry:

{
  "httpRequest": {
    "status": 400,
    "requestUrl": "/index.html",
  }
}

usando esta configuração de agente de operações:

logging:
  receivers:
    in:
      type: files
      include_paths:
      - /var/log/http.json
  processors:
    parse_json:
      type: parse_json
    set_http_request:
      type: modify_fields
      fields:
        httpRequest.status:
          move_from: jsonPayload.http_status
          type: integer
        httpRequest.requestUrl:
          move_from: jsonPayload.path
        httpRequest.referer:
          move_from: jsonPayload.referer
          omit_if: jsonPayload.referer = "-"
  pipelines:
    pipeline:
      receivers: [in]
      processors: [parse_json, set_http_request]

Essa configuração lê os registros formatados em JSON de /var/log/http.json e preenche parte da estrutura httpRequest dos campos nos registros.

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

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 das políticas de alertas com base em métricas.

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