A medida que migres del agente de Logging a Fluentd upstream, es posible que encuentres incompatibilidades de configuración que requieran soluciones alternativas para evitar errores de inicio. En este documento, se describe cómo resolver las incompatibilidades de configuración.
Cambios en la sintaxis entre el agente de Logging heredado y Fluentd upstream
Si bien el agente de Logging heredado se basa en la sintaxis de Fluentd v0.12, Fluentd upstream adopta el estándar v1. Esta transición implica la baja de varios parámetros y la introducción de nuevas directivas anidadas para controlar la funcionalidad principal, lo que reemplaza las estructuras de configuración planas que se usaban anteriormente.
Para evitar fallas en el inicio y garantizar que tus registros se procesen correctamente, debes quitar o reemplazar los parámetros que dejaron de estar disponibles. En las siguientes secciones, se describe cómo actualizar los parámetros obsoletos.
Configuración del complemento de salida
En la siguiente tabla, se enumeran los parámetros que se deben actualizar en la configuración del complemento de salida para evitar errores:
| Sintaxis del agente de Logging heredado | Sintaxis de Fluentd ascendente | Notas |
|---|---|---|
| N/A | <buffer> |
Los complementos de salida de Fluentd admiten una sección <buffer>, dentro de la sección <match>, para configurar el almacenamiento en búfer de eventos. Para obtener más información, consulta la sección Config: Buffer de la documentación de Fluentd. |
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 | Quita este parámetro. Fluentd upstream habilita de forma permanente el éxito parcial de forma predeterminada, y solo descarta las líneas no válidas. |
A continuación, se muestra un ejemplo de la configuración del complemento de salida de google-cloud en el agente de Logging heredado:
<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>
Después de realizar las actualizaciones, la configuración se verá de la siguiente manera:
<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>
Configuración del complemento de entrada
En la siguiente tabla, se enumeran los parámetros que se deben actualizar en la configuración del complemento de entrada para evitar errores:
| Sintaxis del agente de Logging heredado | Sintaxis de Fluentd ascendente | Notas |
|---|---|---|
format |
<parse> |
Para obtener más información, consulta la documentación de Fluentd sobre la sección Parse de Config. |
protocol_type |
<transport> |
Indica el protocolo del transporte syslog, ya sea udp, tcp, o tls. |
auto_typecast |
Quita este parámetro cuando se use dentro del complemento de análisis json. |
A continuación, se muestra un ejemplo de la configuración de un complemento de entrada en el agente de Logging heredado:
<source>
@type tail
path /var/log/my-app.log
format json
</source>
Después de realizar las actualizaciones, la configuración se verá de la siguiente manera:
<source>
@type tail
path /var/log/my-app.log
<parse>
@type json
</parse>
</source>
Serialización de objetos Time de Ruby
Fluentd ascendente requiere una conversión explícita para los objetos Time sin procesar de Ruby que se usan dentro de los filtros <record>, como record_transformer. Sin la conversión explícita, estos objetos causan un error fatal de serialización durante el vaciado del búfer.
Si tu configuración usa ${time} con enable_ruby true, debes convertir explícitamente el objeto a un tipo primitivo, ya sea entero o cadena.
A continuación, se muestra un ejemplo de la configuración de un complemento de filtro en el agente de Logging heredado:
<filter foo.bar>
@type record_transformer
enable_ruby true
<record>
raw_timestamp ${time}
</record>
</filter>
Después de realizar las actualizaciones, la configuración se verá de la siguiente manera:
<filter foo.bar>
@type record_transformer
enable_ruby true
<record>
raw_timestamp ${time.to_i}
</record>
</filter>
Valores predeterminados de transporte y compresión de gRPC
El complemento de salida google_cloud te permite configurar si se debe usar gRPC en vez de REST o JSON para comunicarte con la API de Cloud Logging.
Para mejorar el rendimiento, te recomendamos que habilites el transporte de gRPC y configures grpc_compression_algorithm gzip. Esta combinación minimiza la sobrecarga de la red y el consumo de CPU, en especial cuando se procesan volúmenes de registros importantes.
Para implementar estas optimizaciones, usa la siguiente configuración:
<match **>
@type google_cloud
use_grpc true
grpc_compression_algorithm gzip
</match>
Además, como gRPC se basa en la transmisión de HTTP/2 en el puerto 443, debes asegurarte de que tu infraestructura de red permita el tráfico de gRPC/HTTP/2. En los entornos en los que gRPC está restringido, debes definir de forma explícita use_grpc false para volver a la comunicación HTTP/REST estándar.
Patrón de expresión regular de RabbitMQ
Los patrones de expresión regular que usa el agente de Logging heredado para la transferencia de registros de RabbitMQ suelen ser incompatibles con los formatos de salida de las versiones modernas de RabbitMQ. Estas discrepancias pueden provocar que los registros se procesen de forma incorrecta o se descarten de forma silenciosa durante el proceso de recopilación.
Los registros modernos de RabbitMQ incorporan precisión de milisegundos en las marcas de tiempo, como YYYY-MM-DD HH:MM:SS.L, y presentan marcadores específicos de gravedad y PID, como [info] <0.213.0>, que la expresión regular heredada no pudo encontrar.
Si tu agente de Fluentd está configurado para recopilar registros de RabbitMQ, debes actualizar la sección <parser> para controlar correctamente el formato de registro actual.
A continuación, se muestra un ejemplo de la configuración del complemento de entrada de RabbitMQ para el agente de Logging heredado:
<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>
Después de realizar las actualizaciones, la configuración se verá de la siguiente manera:
<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>