Compatibilidade de configuração para Fluentd upstream

Ao migrar do agente do Logging para o Fluentd upstream, você pode encontrar incompatibilidades de configuração que exigem soluções alternativas para evitar erros de inicialização. Neste documento, descrevemos como resolver as incompatibilidades de configuração.

Mudanças na sintaxe entre o agente do Logging legado e o Fluentd upstream

Enquanto o agente legado do Logging depende da sintaxe do Fluentd v0.12, o Fluentd upstream adota o padrão v1. Essa transição envolve a descontinuação de vários parâmetros e a introdução de novas diretivas aninhadas para lidar com a funcionalidade principal, substituindo as estruturas de configuração simples usadas anteriormente.

Para evitar falhas na inicialização e garantir que seus registros sejam processados corretamente, remova ou substitua os parâmetros descontinuados. As seções a seguir descrevem como atualizar os parâmetros descontinuados.

Configuração do plug-in de saída

A tabela a seguir lista os parâmetros que precisam ser atualizados na configuração do plug-in de saída para evitar erros:

Sintaxe legada do agente do Logging Sintaxe upstream do Fluentd Observações
N/A <buffer> Os plug-ins de saída do Fluentd têm uma seção <buffer>, em <match>, para configurar o buffer de eventos. Para mais informações, consulte a documentação do Fluentd Config: Buffer Section (em inglês).
buffer_type @type
buffer_path path
buffer_chunk_limit chunk_limit_size
disable_retry_limit retry_forever
retry_limit retry_max_times
max_retry_wait retry_max_interval
num_threads flush_thread_count
partial_success N/A Remova esse parâmetro. O Fluentd upstream ativa permanentemente o sucesso parcial por padrão, descartando apenas linhas inválidas.

Confira a seguir um exemplo da configuração do plug-in de saída google-cloud no agente do Logging legado:

<match **>
  @type google_cloud
  buffer_type file
  buffer_path /var/log/google-fluentd/buffers
  buffer_chunk_limit 512KB
  flush_interval 5s
  disable_retry_limit false
  retry_limit 3
  retry_wait 10
  max_retry_wait 300
  num_threads 8
</match>

Depois de fazer as atualizações, a configuração fica assim:

<match **>
  @type google_cloud
  <buffer>
    @type file
    path /var/log/google-fluentd/buffers
    chunk_limit 512KB
    flush_interval 5s
    retry_forever false
    retry_max_times 3
    retry_wait 10
    retry_max_interval 300
    flush_thread_count 8
  </buffer>
</match>

Configuração do plug-in de entrada

A tabela a seguir lista os parâmetros que precisam ser atualizados na configuração do plug-in de entrada para evitar erros:

Sintaxe legada do agente do Logging Sintaxe upstream do Fluentd Observações
format <parse> Para mais informações, consulte a documentação do Fluentd Config: Parse Section (em inglês).
protocol_type <transport> Indique o protocolo do transporte syslog, que pode ser udp, tcp, ou tls.
auto_typecast Remova esse parâmetro quando usado no plug-in de análise json.

Confira a seguir um exemplo de configuração de plug-in de entrada no agente do Logging legado:

<source>
    @type tail
    path /var/log/my-app.log
    format json
</source>

Depois de fazer as atualizações, a configuração fica assim:

<source>
    @type tail
    path /var/log/my-app.log
    <parse>
      @type json
    </parse>
</source>

Serialização de objetos Time do Ruby

O Fluentd upstream exige conversão explícita para objetos Ruby Time brutos usados em filtros <record>, como record_transformer. Sem conversão explícita, esses objetos causam um erro fatal de serialização durante a limpeza do buffer.

Se a configuração usar ${time} com enable_ruby true, será necessário converter explicitamente o objeto em um tipo primitivo, inteiro ou string.

Confira a seguir um exemplo de configuração de plug-in de filtro no agente do Logging legada:

<filter foo.bar>
  @type record_transformer
   enable_ruby true
  <record>
    raw_timestamp ${time}
  </record>
</filter>

Depois de fazer as atualizações, a configuração fica assim:

<filter foo.bar>
  @type record_transformer
   enable_ruby true
  <record>
    raw_timestamp ${time.to_i}
  </record>
</filter>

Transporte e compactação padrão do gRPC

O plug-in de saída google_cloud permite configurar se você quer usar gRPC em vez de REST/JSON para se comunicar com a API Cloud Logging.

Para melhorar o desempenho, recomendamos ativar o transporte gRPC e configurar grpc_compression_algorithm gzip. Essa combinação minimiza a sobrecarga de rede e o consumo de CPU, principalmente ao processar volumes de registros substanciais.

Para implementar essas otimizações, use a seguinte configuração:

<match **>
  @type google_cloud
  use_grpc true
  grpc_compression_algorithm gzip
</match>

Além disso, como o gRPC depende do streaming HTTP/2 na porta 443, verifique se a infraestrutura de rede permite o tráfego gRPC/HTTP/2. Em ambientes em que o gRPC é restrito, é necessário definir explicitamente use_grpc false para reverter à comunicação HTTP/REST padrão.

Padrão de expressão regular do RabbitMQ

Os padrões de expressão regular usados pelo agente do Logging legado para ingestão de registros do RabbitMQ geralmente são incompatíveis com os formatos de saída das versões modernas do RabbitMQ. Essas discrepâncias podem fazer com que os registros sejam processados incorretamente ou descartados silenciosamente durante o processo de coleta.

Os registros modernos do RabbitMQ incorporam precisão de milissegundos em carimbos de data/hora, como YYYY-MM-DD HH:MM:SS.L, e apresentam marcadores específicos de gravidade e PID, como [info] <0.213.0>, que a expressão regular legada não conseguiu corresponder.

Se o agente do Fluentd estiver configurado para coletar registros do RabbitMQ, atualize a seção <parser> para processar corretamente o formato de registro atual.

Confira a seguir um exemplo da configuração do plug-in de entrada do RabbitMQ para o agente do Logging legado:

<source>
  @type tail
  path /var/log/rabbitmq/*.log
  pos_file /var/lib/google-fluentd/pos/rabbitmq.pos
  tag rabbitmq
  format multiline
  format_firstline /^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}/
  format1 /^(?<time>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}) \[(?<severity>\w+)\] (?<message>.*)/
  time_format %Y-%m-%d %H:%M:%S
</source>

Depois de fazer as atualizações, a configuração fica assim:

<source>
  @type tail
  path /var/log/rabbitmq/*.log
  pos_file /var/log/fluentd/pos/rabbitmq.pos
  read_from_head true
  tag rabbitmq
  <parse>
    @type multiline
    format_firstline /^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}\.\d{3}/
    format1 /^(?<time>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}\.\d{3}) \[(?<severity>[^\]]+)\] <(?<pid>[^>]+)> (?m:(?<message>.*))$/
    time_format %Y-%m-%d %H:%M:%S.%L
  </parse>
</source>