Configure o agente de operações

Este documento fornece detalhes sobre as configurações predefinidas e personalizadas do agente de operações. Leia este documento se alguma das seguintes situações se aplicar a si:

Modelo de configuração

O agente de operações usa uma configuração predefinida integrada. Não pode modificar diretamente esta configuração integrada. Em alternativa, cria um ficheiro de substituições que são unidas com a configuração incorporada quando o agente é reiniciado.

As bases da configuração são as seguintes:

  • receivers: este elemento descreve o que é recolhido pelo agente.
  • processors: este elemento descreve como o agente pode modificar as informações recolhidas.
  • service: este elemento associa recetores e processadores para criar fluxos de dados, denominados pipelines. O elemento service contém um elemento pipelines, que pode conter vários pipelines.

A configuração integrada é composta por estes elementos e usa os mesmos elementos para substituir essa configuração integrada.

Configuração integrada

A configuração integrada do agente de operações define a recolha predefinida de registos e métricas. A imagem seguinte mostra a configuração integrada para Linux e Windows:

Linux

Por predefinição, o agente de operações recolhe registos baseados em ficheiros e métricas do anfitrião.syslog

Para mais informações sobre as métricas recolhidas, consulte o artigo Métricas carregadas pelos recetores.

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 predefinição, o agente de operações recolhe registos de eventos do Windows dos canais System,Application e Security, bem como métricas do anfitrião, métricas do IIS e métricas do SQL Server.

Para mais informações sobre as métricas recolhidas, consulte o artigo Métricas carregadas pelos recetores.

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]

Estas configurações são abordadas mais detalhadamente em Configuração de registo e Configuração de métricas.

Configuração especificada pelo utilizador

Para substituir a configuração incorporada, adicione novos elementos de configuração ao ficheiro de configuração do utilizador. Coloque a configuração do agente de operações nos seguintes ficheiros:

  • Para 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 utilizador é unida à configuração incorporada quando o agente é reiniciado.

Para substituir um recetor, um processador ou um pipeline incorporado, redefina-o no ficheiro config.yaml declarando-o com o mesmo identificador. A partir da versão 2.31.0 do agente Ops, também pode configurar a funcionalidade de rotação de registos do agente. Para mais informações, consulte o artigo Configure a rotação de registos no agente Ops.

Por exemplo, a configuração integrada para métricas inclui um hostmetrics recetor que especifica um intervalo de recolha de 60 segundos. Para alterar o intervalo de recolha das métricas do anfitrião para 30 segundos, inclua um recetor de métricas denominado hostmetrics no seu ficheiro config.yaml que defina o valor collection_interval para 30 segundos, conforme mostrado no exemplo seguinte:

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

Para ver outros exemplos de alteração das configurações incorporadas, consulte Configuração de registo e Configuração de métricas. Também pode desativar a recolha de dados de registo ou de métricas. Estas alterações são descritas nos exemplos de configurações de registo servicee configurações de métricas service.

Pode usar este ficheiro para impedir que o agente recolha registos automáticos e os envie para o Cloud Logging. Para mais informações, consulte o artigo Recolha de registos automáticos.

Também configura a funcionalidade de rotação de registos do agente através deste ficheiro; para mais informações, consulte o artigo Configure a rotação de registos no agente de operações.

Não pode configurar o agente de operações para exportar registos ou métricas para serviços que não sejam o Cloud Logging e o Cloud Monitoring.

Configurações de registo

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

  • receivers: este elemento descreve os dados a recolher dos ficheiros de registo; estes dados são mapeados num modelo <timestamp, record>.
  • processors: este elemento opcional descreve como o agente pode modificar as informações recolhidas.
  • service: este elemento associa recetores e processadores para criar fluxos de dados, denominados pipelines. O elemento service contém um elemento pipelines, que pode incluir várias definições de pipeline.

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

As secções seguintes descrevem cada um destes elementos.

O agente de operações envia registos para o Cloud Logging. Não pode configurá-lo para exportar registos para outros serviços. No entanto, pode configurar o Cloud Logging para exportar registos. Para mais informações, consulte o artigo Encaminhe registos para destinos suportados.

Recetores de registos

O elemento receivers contém um conjunto de destinatários, cada um identificado por um RECEIVER_ID. Um recetor descreve como obter os registos; por exemplo, através da monitorização de ficheiros, da utilização de uma porta TCP ou do Registo de eventos do Windows.

Estrutura dos recetores de registos

Cada destinatário tem de ter um identificador, RECEIVER_ID, e incluir um elemento type. Os tipos válidos são:

  • files: recolha registos monitorizando ficheiros no disco.
  • fluent_forward (versões 2.12.0 e posteriores do agente de operações): recolha registos enviados através do protocolo Fluent Forward sobre TCP.
  • tcp (Versões 2.3.0 e posteriores do agente de operações): recolha registos no formato JSON ao ouvir uma porta TCP.
  • Apenas no Linux:
    • syslog: recolher mensagens Syslog através de TCP ou UDP.
    • systemd_journald (Versões do agente de operações 2.4.0 e posteriores): recolhe registos do journal do systemd do serviço systemd-journald.
  • Apenas para Windows:
    • windows_event_log: recolha registos de eventos do Windows através da API de registo de eventos do Windows.
  • Recetores de registos de aplicações de terceiros

A estrutura receivers tem o seguinte aspeto:

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

Consoante o valor do elemento type, podem existir outras opções de configuração, como se segue:

  • files recetores:

    • include_paths: obrigatório. Uma lista de caminhos do sistema de ficheiros a ler através da monitorização de cada ficheiro. Pode usar um caráter universal (*) nos caminhos; por exemplo, /var/log/*.log (Linux) ou C:\logs\*.log (Windows).

      Para ver uma lista de ficheiros de registo de aplicações Linux comuns, consulte o artigo Ficheiros de registo do Linux comuns.

    • exclude_paths: opcional. Uma lista de padrões de caminhos do sistema de ficheiros a excluir do conjunto correspondente a include_paths.

    • record_log_file_path: opcional. Se estiver definido como true, o caminho para o ficheiro específico a partir do qual o registo de registo foi obtido aparece na entrada de registo de saída como o valor da etiqueta agent.googleapis.com/log_file_path. Quando usa um caráter universal, apenas é registado o caminho do ficheiro a partir do qual o registo foi obtido.

    • wildcard_refresh_interval: opcional. O intervalo no qual os caminhos de ficheiros com carateres universais em include_paths são atualizados. Indicado como uma duração, por exemplo, 30s, 2m. Esta propriedade pode ser útil em volumes de processamento de registos elevados, em que os ficheiros de registo são rodados mais rapidamente do que o intervalo predefinido. Se não for especificado, o intervalo predefinido é de 60 segundos.

  • fluent_forward recetores:

    • listen_host: opcional. Um endereço IP para ouvir. O valor predefinido é 127.0.0.1.

    • listen_port: opcional. Uma porta para ouvir. O valor predefinido é 24224.

  • Recetores syslog (apenas para Linux):

    • transport_protocol: valores suportados: tcp, udp.

    • listen_host: Um endereço IP para escutar.

    • listen_port: uma porta para ouvir.

  • tcp recetores:

    • format: obrigatório. Formato de registo. Valor suportado: json.

    • listen_host: opcional. Um endereço IP para ouvir. O valor predefinido é 127.0.0.1.

    • listen_port: opcional. Uma porta para ouvir. O valor predefinido é 5170.

  • Recetores windows_event_log (apenas para Windows):

    • channels: obrigatório. Uma lista de canais do Registo de eventos do Windows a partir dos quais ler registos.

    • receiver_version: opcional. Controla que API Windows Event Log usar. Os valores suportados são 1 e 2. O valor predefinido é 1.

    • render_as_xml: opcional. Se estiver definido como true, todos os campos do registo de eventos, exceto jsonPayload.Message e jsonPayload.StringInserts, são renderizados como um documento XML num campo de string denominado jsonPayload.raw_xml. O valor predefinido é false. Não é possível definir esta opção como true quando receiver_version é 1.

Exemplos de recetores de registo

Recetor de exemplo files:

receivers:
  RECEIVER_ID:
    type: files

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

Recetor de exemplo fluent_forward:

receivers:
  RECEIVER_ID:
    type: fluent_forward

    listen_host: 127.0.0.1
    listen_port: 24224

Exemplo de recetor syslog (apenas no Linux):

receivers:
  RECEIVER_ID:
    type: syslog

    transport_protocol: tcp
    listen_host: 0.0.0.0
    listen_port: 5140

Recetor de exemplo tcp:

receivers:
  RECEIVER_ID:
    type: tcp

    format: json
    listen_host: 127.0.0.1
    listen_port: 5170

Exemplo de recetor windows_event_log (apenas para Windows):

receivers:
  RECEIVER_ID:
    type: windows_event_log

    channels: [System,Application,Security]

Exemplo de recetor windows_event_log que substitui o recetor incorporado para usar a versão 2:

receivers:
  windows_event_log:
    type: windows_event_log

    channels: [System,Application,Security]
    receiver_version: 2

Recetor de exemplo systemd_journald:

receivers:
  RECEIVER_ID:
    type: systemd_journald

Campos especiais em payloads estruturados

Para processadores e recetores que podem introduzir dados estruturados (os recetores fluent_forward e tcp e o processador parse_json), pode definir campos especiais na entrada que serão mapeados para campos específicos no objeto LogEntry que o agente escreve na API Logging.

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

Campo de registo 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 registo) logName
logging.googleapis.com/httpRequest (HttpRequest) httpRequest
logging.googleapis.com/severity (string) severity
logging.googleapis.com/labels (struct of string:string) labels
logging.googleapis.com/operation (struct) operation
logging.googleapis.com/sourceLocation (struct) sourceLocation
logging.googleapis.com/trace (string) trace
logging.googleapis.com/spanId (string) spanId

Todos os campos de registo estruturados restantes permanecem parte da jsonPayloadestrutura.

Ficheiros de registo do Linux comuns

A tabela seguinte apresenta ficheiros de registo comuns para aplicações Linux usadas frequentemente:

Aplicação Ficheiros de registo comuns
apache Para obter informações sobre ficheiros de registo do Apache, consulte o artigo Monitorizar aplicações de terceiros: servidor Web Apache.
cassandra Para informações sobre ficheiros de registo do Cassandra, consulte Monitorização de aplicações 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
cais /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 obter informações acerca dos ficheiros de registo do Memcached, consulte Monitorização de aplicações de terceiros: Memcached.
mongodb Para obter informações sobre os ficheiros de registo do MongoDB, consulte Monitorização de aplicações de terceiros: MongoDB.
mysql Para obter informações sobre os ficheiros de registo do MySQL, consulte o artigo Monitorizar aplicações de terceiros: MySQL.
nginx Para obter informações sobre os ficheiros de registo do nginx, consulte o artigo Monitorização de aplicações de terceiros: nginx.
postgres Para informações sobre os ficheiros de registo do PostgreSQL, consulte o artigo Monitorização de aplicações de terceiros: PostgreSQL.
fantoche /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 obter informações sobre os ficheiros de registo do RabbitMQ, consulte o artigo Monitorização de aplicações de terceiros: RabbitMQ.
redis Para obter informações sobre os ficheiros de registo do Redis, consulte o artigo Monitorização de aplicações de terceiros: Redis.
redmine /var/log/redmine/*.log
sal /var/log/salt/key
/var/log/salt/master
/var/log/salt/minion
/var/log/salt/syndic.loc
solr Para obter informações sobre os ficheiros de registo do Apache Solr, consulte Monitorização de aplicações de terceiros: Apache Solr.
sugarcrm /var/www/*/sugarcrm.log
syslog /var/log/syslog
/var/log/messages
tomcat Para obter informações acerca dos ficheiros de registo do Apache Tomcat, consulte o artigo Monitorizar aplicações de terceiros: Apache Tomcat.
tratador de animais Para mais informações sobre os ficheiros de registo do Apache ZooKeeper, consulte o artigo Monitorizar aplicações de terceiros: Apache ZooKeeper.

Etiquetas carregadas predefinidas

Por predefinição, os registos podem conter as seguintes etiquetas no LogEntry:

Campo Valor de exemplo Descrição
labels."compute.googleapis.com/resource_name" test_vm O nome da máquina virtual a partir da qual este registo tem origem. Escrito para todos os registos.
labels."logging.googleapis.com/instrumentation_source" agent.googleapis.com/apache_access O valor do destinatário type a partir do qual este registo tem origem, com o prefixo agent.googleapis.com/. Escritas apenas por destinatários de integrações de terceiros.

Processadores de registo

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

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

  • parse_json: analise registos estruturados formatados em JSON.
  • parse_multiline: analise registos de várias linhas. (Apenas no Linux)
  • parse_regex: Analise registos formatados em texto através de padrões de regex para os transformar em registos estruturados formatados em JSON.
  • exclude_logs: Exclui registos que correspondem às regras especificadas (a partir da versão 2.9.0).
  • modify_fields: definir/transformar campos em entradas de registo (a partir da versão 2.14.0).

A estrutura processors tem o seguinte aspeto:

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

Consoante o valor do elemento type, existem outras opções de configuração, como se segue.

parse_json processador

Estrutura de 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 do LogEntry. Outras partes do LogEntry podem ser analisadas definindo determinados campos especiais de nível superior.

  • time_key: opcional. Se a entrada do registo fornecer um campo com uma data/hora, esta opção especifica o nome desse campo. O valor extraído é usado para definir o campo timestamp do LogEntry resultante e é removido da carga útil.

    Se a opção time_key for especificada, também tem de especificar o seguinte:

    • time_format: obrigatório se time_key for usado. Esta opção especifica o formato do campo time_key para que possa ser reconhecido e analisado corretamente. Para ver detalhes do 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"

parse_multiline processador

Estrutura de 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. Apenas é suportado um único valor:

      • language_exceptions: permite ao processador concatenar exceções num único LogEntry, com base no valor da opção language.

    • language: obrigatório. Apenas é suportado um único valor:

      • java: concatena exceções comuns do Java numa única LogEntry.
      • python: concatena exceções comuns do Python numa única LogEntry.
      • go: concatena exceções comuns do Go numa única LogEntry.
Exemplo de configuração
logging:
  receivers:
    custom_file1:
      type: files
      include_paths:
      - /tmp/test-multiline28
  processors:
    parse_java_multiline:
      type: parse_multiline
      match_any:
      - type: language_exceptions
        language: java
    extract_structure:
      type: parse_regex
      field: message
      regex: "^(?<time>[\d-]*T[\d:.Z]*) (?<severity>[^ ]*) (?<file>[^ :]*):(?<line>[\d]*) - (?<message>(.|\\n)*)$"
      time_key: time
      time_format: "%Y-%m-%dT%H:%M:%S.%L"
    move_severity:
      type: modify_fields
      fields:
        severity:
          move_from: jsonPayload.severity
  service:
    pipelines:
      pipeline1:
        receivers: [custom_file1]
        processors: [parse_java_multiline, extract_structure, move_severity]

No processador extract_structure, a declaração field: message significa que a expressão regular é aplicada ao campo jsonPayload.message da entrada do registo. Por predefinição, o recetor de ficheiros coloca cada linha do ficheiro de registo numa entrada de registo com um único campo de carga útil denominado jsonPayload.message.

O processador extract_structure coloca os campos extraídos em subcampos do campo LogEntry.jsonPayload. Outras declarações no ficheiro YAML fazem com que dois dos campos extraídos, time e severity, sejam movidos. A declaração time_key: time extrai o campo LogEntry.jsonPayload.time, analisa a data/hora e, em seguida, adiciona o campo LogEntry.timestamp. O processador move_severity move o campo de gravidade do campo LogEntry.jsonPayload.severity para o campo LogEntry.severity.

Exemplo de ficheiro de registo:

2022-10-17T22:00:00.187512963Z ERROR HelloWorld:16 - javax.servlet.ServletException: Something bad happened
    at com.example.myproject.OpenSessionInViewFilter.doFilter(OpenSessionInViewFilter.java:60)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
    at com.example.myproject.ExceptionHandlerFilter.doFilter(ExceptionHandlerFilter.java:28)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
    at com.example.myproject.OutputBufferFilter.doFilter(OutputBufferFilter.java:33)
Caused by: com.example.myproject.MyProjectServletException
    at com.example.myproject.MyServlet.doPost(MyServlet.java:169)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
    at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)
    at com.example.myproject.OpenSessionInViewFilter.doFilter(OpenSessionInViewFilter.java:30)
    ... 27 common frames omitted

O agente carrega cada linha do ficheiro de registo no Cloud Logging no seguinte formato:

{
  "insertId": "...",
  "jsonPayload": {
    "line": "16",
    "message": "javax.servlet.ServletException: Something bad happened\n    at com.example.myproject.OpenSessionInViewFilter.doFilter(OpenSessionInViewFilter.java:60)\n    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)\n    at com.example.myproject.ExceptionHandlerFilter.doFilter(ExceptionHandlerFilter.java:28)\n    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)\n    at com.example.myproject.OutputBufferFilter.doFilter(OutputBufferFilter.java:33)\nCaused by: com.example.myproject.MyProjectServletException\n    at com.example.myproject.MyServlet.doPost(MyServlet.java:169)\n    at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)\n    at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)\n    at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)\n    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)\n    at com.example.myproject.OpenSessionInViewFilter.doFilter(OpenSessionInViewFilter.java:30)\n    ... 27 common frames omitted\n",
    "file": "HelloWorld"
  },
  "resource": {
    "type": "gce_instance",
    "labels": {
      "instance_id": "...",
      "project_id": "...",
      "zone": "..."
    }
  },
  "timestamp": "2022-10-17T22:00:00.187512963Z",
  "severity": "ERROR",
  "labels": {
    "compute.googleapis.com/resource_name": "..."
  },
  "logName": "projects/.../logs/custom_file",
  "receiveTimestamp": "2022-10-18T03:12:38.430364391Z"
}

parse_regex processador

Estrutura de 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 do registo fornecer um campo com uma data/hora, esta opção especifica o nome desse campo. O valor extraído é usado para definir o campo timestamp do LogEntry resultante e é removido da carga útil.

    Se a opção time_key for especificada, também tem de especificar o seguinte:

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

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

    O texto correspondente aos grupos de captura com nome é colocado nos campos do campo LogEntryjsonPayload. Para adicionar estrutura adicional aos seus registos, use o processador modify_fields.

    Para ver um conjunto de expressões regulares para extrair informações de ficheiros de registo de aplicações Linux comuns, consulte o artigo Ficheiros de registo do Linux comuns.

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"

exclude_logs processador

Estrutura da configuração:

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

A configuração de nível superior para este 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 registo corresponder a alguma regra, o agente de operações não carrega essa entrada.

    Os registos carregados pelo Ops Agent seguem a estrutura LogEntry. Os nomes dos campos são sensíveis a maiúsculas e minúsculas. Só pode especificar regras com base nos seguintes campos e respetivos subcampos:

    • httpRequest
    • jsonPayload
    • labels
    • operation
    • severity
    • sourceLocation
    • trace
    • spanId

    A seguinte regra de exemplo

    severity =~ "(DEBUG|INFO)"

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

    As regras seguem a sintaxe da linguagem de consulta do Cloud Logging, mas apenas suportam um subconjunto das funcionalidades que a linguagem de consulta do Logging suporta:

    • Operadores de comparação: =, !=, :, =~, !~. Apenas são suportadas comparações de strings.
    • 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"'

modify_fields Processador

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

Estrutura de 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 para este processador contém um único campo, fields, que contém um mapa de nomes de campos de saída e as traduções correspondentes. Para cada campo de saída, é aplicada uma origem opcional e zero ou mais operações de mutação.

Todos os nomes dos campos 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 registo original e, por conseguinte, não podem fazer referência ao novo valor de quaisquer outros campos que estejam a ser modificados pelo mesmo processador.

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

  • Nenhuma origem especificada

    Se não for especificado nenhum valor de origem, o valor existente no campo de destino é modificado.

  • move_from: <source field>

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

  • copy_from: <source field>

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

  • static_value: <string>

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

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

  1. default_value: <string>

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

  2. map_values: <map>

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

  3. map_values_exclusive: {true|false}

    Caso o valor <source field> não corresponda a nenhuma chave especificada nos pares map_values, o campo de destino é anulado à força se map_values_exclusive for verdadeiro ou deixado intacto se map_values_exclusive for falso.

  4. type: {integer|float}

    O valor de entrada é convertido num número inteiro ou num número de vírgula flutuante. Se não for possível converter a string num número, o valor de saída não é definido. Se a string contiver um número de vírgula flutuante, mas o tipo for especificado como integer, o número é truncado para um número inteiro.

    Tenha em atenção que a API Cloud Logging usa JSON e, por isso, não suporta um número inteiro de 64 bits completo. Se for necessário um número inteiro de 64 bits (ou superior), tem de ser armazenado como uma string na entrada do registo.

  5. omit_if: <filter>

    Se o filtro corresponder ao registo de registo de entrada, o campo de saída é anulado. Isto pode ser usado para remover valores de marcadores de posição, como:

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

Configurações de exemplo

O processador parse_json transformaria um ficheiro JSON que contivesse

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

Numa estrutura LogEntry com o seguinte aspeto:

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

Em seguida, isto pode ser transformado com modify_fields neste LogEntry:

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

através desta configuração do 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 = "-"
  service:
    pipelines:
      pipeline:
        receivers: [in]
        processors: [parse_json, set_http_request]

Esta configuração lê registos formatados em JSON a partir do /var/log/http.json e preenche parte da estrutura httpRequest a partir de campos nos registos.

Serviço de registo

O serviço de registo personaliza a verbosidade para os registos do próprio agente de operações e associa os recetores e os processadores de registo em pipelines. A secção service tem os seguintes elementos:

  • log_level
  • pipelines

Nível de verbosidade do registo

O campo log_level, disponível com as versões 2.6.0 e posteriores do agente de operações, personaliza a verbosidade dos registos do próprio submódulo de registo do agente de operações. O valor predefinido é info. As opções disponíveis são: error, warn, info, debug e trace.

A configuração seguinte personaliza o nível de detalhe do registo para o submódulo de registo para ser debug:

logging:
  service:
    log_level: debug

Pipelines de registo

O campo pipelines pode conter vários IDs e definições de pipelines. Cada valor pipeline consiste nos seguintes elementos:

  • receivers: obrigatório para novos pipelines. Uma lista de IDs de destinatários, conforme descrito em Registo de destinatários. A ordem dos IDs dos destinatários na lista não é importante. O pipeline recolhe dados de todos os recetores indicados.

  • processors: opcional. Uma lista de IDs de processadores, conforme descrito em Processadores de registo. A ordem dos IDs dos processadores na lista é importante. Cada registo é executado através dos processadores na ordem indicada.

Exemplos de configurações de service registo

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 impedir que o agente recolha e envie entradas /var/log/message ou /var/log/syslog, redefina o pipeline predefinido com uma lista receivers vazia e sem processadores. Esta configuração não para o subcomponente de registo do agente, porque o agente tem de poder recolher registos para o subcomponente de monitorização. A configuração de registo vazia completa tem o seguinte aspeto:

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

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

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

Configurações de métricas

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

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

As secções seguintes descrevem cada um destes elementos.

O agente de operações envia métricas para o Cloud Monitoring. Não pode configurá-lo para exportar métricas para outros serviços.

Recetores de métricas

O elemento receivers contém um conjunto de definições do destinatário. Um recetor descreve de onde obter as métricas, como cpu e memory. Um recetor pode ser partilhado entre vários pipelines.

Estrutura dos recetores de métricas

Cada destinatário tem de ter um identificador, RECEIVER_ID, e incluir um elemento type. Os tipos incorporados válidos são:

  • hostmetrics
  • iis (apenas Windows)
  • mssql (apenas Windows)

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

Cada um destes tipos de recetor recolhe um conjunto de métricas. Para obter informações sobre as métricas específicas incluídas, consulte o artigo Métricas carregadas pelos recetores.

Só pode criar um destinatário de cada tipo. Por exemplo, não pode definir dois destinatários do tipo hostmetrics.

Alterar o intervalo de recolha nos recetores de métricas

Algumas cargas de trabalho críticas podem exigir alertas rápidos. Ao reduzir o intervalo de recolha das métricas, pode configurar alertas mais sensíveis. Para obter informações sobre como os alertas são avaliados, consulte o artigo Comportamento das políticas de alerta baseadas em métricas.

Por exemplo, o recetor seguinte altera o intervalo de recolha das métricas do anfitrião (o ID do recetor é hostmetrics) do valor predefinido de 60 segundos para 10 segundos:

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

Também pode substituir o intervalo de recolha para os recetores de métricas do Windows iis e mssql através da mesma técnica.

Métricas carregadas pelos recetores

As métricas carregadas 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 recetor hostmetrics

O recetor hostmetrics introduz os seguintes grupos de métricas. Para mais informações, consulte a secção associada de 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
Utilização da CPU, com etiquetas para o número da CPU e o estado da CPU
Percentagem de utilização da CPU, com etiquetas para o número da CPU e o estado da CPU
disk Bytes lidos do disco, com etiqueta para o dispositivo
Bytes escritos no disco, com etiqueta para o dispositivo
Tempo de E/S do disco, com etiqueta para o dispositivo
Tempo de E/S ponderado do disco, com etiqueta para o dispositivo
Operações pendentes do disco, com etiqueta para o dispositivo
Operações unidas do disco, com etiquetas para o dispositivo e a direção
Operações do disco, com etiquetas para o dispositivo e a direção
Tempo de operação do disco, com etiquetas para o dispositivo e a direção
Utilização do disco, com etiquetas para o dispositivo e o estado
Utilização do disco, com etiquetas para o dispositivo e o estado
gpu
Apenas para Linux; consulte Acerca das métricas gpu para outras informações importantes. 		Número atual de bytes de memória da GPU usados, por estado
Quantidade máxima de memória da GPU, em bytes, que foi alocada pelo processo
Percentagem de tempo na duração do processo em que um ou mais núcleos estiveram em execução na GPU
Percentagem de tempo, desde a última amostra, em que a GPU esteve ativa
interface
Apenas no Linux 		Contagem total de erros de rede
Contagem total de pacotes enviados através da rede
Número total de bytes enviados através da rede
memory Utilização de memória, com etiqueta para o estado (em buffer, em cache, livre, slab, usado)
Percentagem de utilização de memória, com etiqueta para o estado (em buffer, em cache, livre, slab, usado)
network Número de ligações TCP, com etiquetas para a porta e o estado TCP
swap Trocar operações de E/S, com etiqueta para a direção
Trocar bytes usados, com etiquetas para o dispositivo e o estado
Trocar percentagem usada, com etiquetas para o dispositivo e o estado
pagefile
Apenas Windows 		Percentagem atual do ficheiro de paginação usado por estado
processes Processos de contagem, com etiqueta para o estado
Processos de contagem bifurcados
E/S de leitura do disco por processo, com etiquetas para o nome do processo + outros
E/S de escrita do disco por processo, com etiquetas para o nome do processo + outros
Utilização de RSS por processo, com etiquetas para o nome do processo + outros
Utilização de VM por processo, com etiquetas para o nome do processo + outros
O recetor iis (apenas para Windows)

O recetor iis (apenas no Windows) introduz métricas do grupo iis. Para mais informações, consulte a página Métricas do agente.

Grupo Métrica
iis
Apenas Windows 		Ligações atualmente abertas ao IIS
Bytes de rede transferidos pelo IIS
Ligações abertas ao IIS
Pedidos feitos ao IIS
O recetor mssql (apenas para Windows)

O recetor mssql (apenas no Windows) introduz métricas do grupo mssql. Para mais informações, consulte a página Métricas do agente de operações.

Grupo Métrica
mssql
Apenas Windows 		Ligações atualmente abertas ao SQL Server
Total de transações do SQL Server por segundo
Transações de escrita do SQL Server por segundo

Processadores de métricas

O elemento processor contém um conjunto de definições de processador. Um processador descreve as métricas do tipo de recetor a excluir. O único tipo suportado é exclude_metrics, que usa uma opção metrics_pattern. O valor é uma lista de globs que correspondem aos tipos de métricas do agente de operações que quer excluir do grupo recolhido por um recetor. Por exemplo:

Processador de métricas de amostra

O exemplo seguinte mostra o processador exclude_metrics fornecido nas configurações incorporadas. Este processador fornece um valor vazio, pelo que não exclui nenhuma métrica.metrics_pattern

processors:
  metrics_filter:
    type: exclude_metrics
    metrics_pattern: []

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

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

Isto exclui as métricas de processo da recolha no metrics_filterprocessador que se aplica ao pipeline predefinido no serviço metrics.

Serviço de métricas

O serviço de métricas personaliza a verbosidade para os registos do módulo de métricas do agente de operações e associa os recetores e os processadores de métricas em pipelines. A secção service tem dois elementos: log_level e pipelines.

Nível de detalhe das métricas

log_level, disponível com as versões 2.6.0 e posteriores do Ops Agent, personaliza o nível de detalhe dos registos do submódulo de métricas do Ops Agent. A predefinição é info. As opções disponíveis são: error, warn, info e debug.

Pipelines de métricas

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

  • receivers: obrigatório para novos pipelines. Uma lista de IDs de recetores, conforme descrito em Recetores de métricas. A ordem dos IDs dos destinatários na lista não é importante. O pipeline recolhe dados de todos os recetores indicados.

  • processors: opcional. Uma lista de IDs de processadores, conforme descrito em Processadores de métricas. A ordem dos IDs dos processadores na lista é importante. Cada ponto métrico é executado através dos processadores pela ordem indicada.

Exemplos de configurações de service 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 incorporada de métricas do anfitrião, redefina o pipeline predefinido com uma lista receivers vazia e sem processadores. A configuração completa das métricas tem o seguinte aspeto:

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

O exemplo seguinte mostra a configuração service incorporada para o Windows:

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

A seguinte configuração service personaliza o nível de detalhe do registo para que o submódulo de métricas seja debug:

metrics:
  service:
    log_level: debug

Recolha de registos próprios

Por predefinição, os autorregistos do Fluent Bit do agente de operações são enviados para o Cloud Logging. Estes registos podem incluir muitas informações e o volume adicional pode aumentar os custos de utilização do Cloud Logging.

Pode desativar a recolha destes registos automáticos, a partir da versão 2.44.0 do agente de operações, usando a opção default_self_log_file_collection.

Para desativar a recolha de registos automáticos, adicione uma secção global ao ficheiro de configuração especificado pelo utilizador e defina a opção default_self_log_file_collection com o valor false:

logging:  ...
metrics:  ...
global:
  default_self_log_file_collection: false

Configuração de rotação de registos

A partir da versão 2.31.0 do agente de operações, também pode configurar a funcionalidade de rotação de registos do agente através dos ficheiros de configuração. Para mais informações, consulte o artigo Configure a rotação de registos no agente de operações.