# Configuración de los registros de Amazon ECS para conseguir un alto rendimiento
Para escenarios de alto rendimiento de registros, recomendamos utilizar el controlador de registro `awsfirelens` con Firelens y Fluent Bit. Fluent Bit es un procesador de registro ligero que es eficiente con los recursos y puede gestionar millones de registros. Sin embargo, para lograr un rendimiento óptimo a escala es necesario ajustar su configuración.
En esta sección se describen las técnicas de optimización de Fluent Bit avanzadas para gestionar un alto rendimiento de los registros y, al mismo tiempo, mantener la estabilidad del sistema y garantizar que no se pierdan datos.
Para obtener información acerca de cómo utilizar archivos de configuración personalizados con FireLens, consulte [Uso de un archivo de configuración personalizado](firelens-taskdef.md#firelens-taskdef-customconfig). Para ver más ejemplos, consulte [Ejemplos de FireLens en Amazon ECS](https://github.com/aws-samples/amazon-ecs-firelens-examples) en GitHub.
**nota**
Algunas opciones de configuración de esta sección, como `workers` y `threaded`, requieren AWS para la versión 3 o posterior de Fluent Bit. Para obtener información sobre las versiones disponibles, consulte [Versiones de AWS para Fluent Bit](https://github.com/aws/aws-for-fluent-bit/releases).
## Comprensión de los fragmentos
Fluent Bit procesa los datos en unidades denominadas *fragmentos*. Cuando un complemento INPUT recibe datos, el motor crea un fragmento que se almacena en la memoria o en el sistema de archivos antes de enviarse a los destinos OUTPUT.
El comportamiento del almacenamiento en búfer depende de la opción `storage.type` de las secciones INPUT. De forma predeterminada, Fluent Bit utiliza el almacenamiento en búfer de memoria. Para escenarios de alto rendimiento o producción, el almacenamiento en búfer del sistema de archivos proporciona una mayor resiliencia.
Para obtener más información, consulte [Chunks](https://docs.fluentbit.io/manual/administration/buffering-and-storage#chunks) en la documentación de Fluent Bit y [What is a Chunk?](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#what-is-a-chunk) en el repositorio de ejemplos de AWS para Fluent Bit.
## Almacenamiento en búfer de memoria (predeterminado)
De forma predeterminada, Fluent Bit utiliza el almacenamiento en búfer de memoria (`storage.type memory`). Puede limitar el uso de memoria por cada complemento INPUT mediante el parámetro `Mem_Buf_Limit`.
En el siguiente ejemplo se muestra una configuración de entrada en búfer de memoria:
```
[INPUT]
Name tcp
Tag ApplicationLogs
Port 5170
storage.type memory
Mem_Buf_Limit 5MB
```
**importante**
Cuando `Mem_Buf_Limit` se supera en un complemento, Fluent Bit detiene la entrada y se pierden nuevos registros. Esto puede provocar una contrapresión y ralentizar la aplicación. En los registros de Fluent Bit aparece la siguiente advertencia:
```
[input] tcp.1 paused (mem buf overlimit)
```
El almacenamiento en búfer de memoria es adecuado para casos de uso sencillos con un rendimiento de registro de bajo a moderado. Para escenarios de alto rendimiento o producción en los que la pérdida de datos sea un problema, utilice en su lugar el almacenamiento en búfer del sistema de archivos.
Para obtener más información, consulte [Buffering and Memory](https://docs.fluentbit.io/manual/administration/buffering-and-storage#buffering-and-memory) en la documentación de Fluent Bit y [Memory Buffering Only](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#case-1-memory-buffering-only-default-or-storagetype-memory) en el repositorio de ejemplos de AWS para Fluent Bit.
## Almacenamiento en búfer del sistema de archivos
Para escenarios de alto rendimiento, recomendamos utilizar el almacenamiento en búfer del sistema de archivos. Para obtener más información sobre cómo Fluent Bit gestiona el almacenamiento en búfer y el almacenamiento, consulte [Almacenamiento en búfer y almacenamiento en la documentación](https://docs.fluentbit.io/manual/administration/buffering-and-storage) de Fluent Bit.
El uso del almacenamiento en búfer del sistema de archivos proporciona los siguientes beneficios:
+ **Mayor capacidad de búfer**: el espacio en disco suele ser más abundante que la memoria.
+ **Persistencia**: los datos almacenados en búfer sobreviven a los reinicios de Fluent Bit.
+ **Degradación gradual**: durante los errores de salida, los datos se acumulan en el disco en lugar de agotar la memoria.
Para activar el almacenamiento en búfer del sistema de archivos, proporciona un archivo de configuración personalizado de Fluent Bit. A continuación se muestra un ejemplo de configuración recomendada:
```
[SERVICE]
# Flush logs every 1 second
Flush 1
# Wait 120 seconds during shutdown to flush remaining logs
Grace 120
# Directory for filesystem buffering
storage.path /var/log/flb-storage/
# Limit chunks stored 'up' in memory (reduce for memory-constrained environments)
storage.max_chunks_up 32
# Flush backlog chunks to destinations during shutdown (prevents log loss)
storage.backlog.flush_on_shutdown On
[INPUT]
Name forward
unix_path /var/run/fluent.sock
# Run input in separate thread to prevent blocking
threaded true
# Enable filesystem buffering for persistence
storage.type filesystem
[OUTPUT]
Name cloudwatch_logs
Match *
region {{us-west-2}}
log_group_name {{/aws/ecs/my-app}}
log_stream_name $(ecs_task_id)
# Use multiple workers for parallel processing
workers 2
# Retry failed flushes up to 15 times
retry_limit 15
# Maximum disk space for buffered data for this output
storage.total_limit_size 10G
```
Parámetros principales de configuración:
`storage.path`
El directorio donde Fluent Bit almacena los fragmentos almacenados en búfer en el disco.
`storage.backlog.flush_on_shutdown`
Cuando está activado, Fluent Bit intenta vaciar todos los fragmentos del sistema de archivos pendientes y llevarlos a sus destinos durante el apagado. Esto ayuda a garantizar la entrega de los datos antes de que Fluent Bit se detenga, pero puede aumentar el tiempo de apagado.
`storage.max_chunks_up`
El número de fragmentos que permanecen en la memoria. El valor predeterminado es de 128 fragmentos, que pueden consumir más de 500 MB de memoria, ya que cada bloque puede utilizar entre 4 y 5 MB. En entornos con limitaciones de memoria, reduzca este valor. Por ejemplo, si tiene 50 MB disponibles para almacenar en búfer, configúrelo entre 8 y 10 fragmentos.
`storage.type filesystem`
Active el almacenamiento en el sistema de archivos para el complemento de entrada. A pesar del nombre, Fluent Bit utiliza `mmap` para asignar fragmentos tanto en la memoria como en el disco, lo que proporciona persistencia sin sacrificar el rendimiento.
`storage.total_limit_size`
El espacio máximo en disco para los datos almacenados en búfer para un complemento OUTPUT específico. Cuando se alcanza este límite, se eliminan los registros más antiguos de esa salida. Para obtener más información acerca de los tamaños, consulte [Descripción de `storage.total_limit_size`](#firelens-storage-sizing).
`threaded true`
Ejecuta la entrada en su propio hilo, separado del bucle de eventos principal de Fluent Bit. Esto evita que las entradas lentas bloqueen toda la canalización.
Para obtener más información, consulte [Filesystem Buffering](https://docs.fluentbit.io/manual/administration/buffering-and-storage#filesystem-buffering) en la documentación de Fluent Bit y [Filesystem and Memory Buffering](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#case-2-filesystem-and-memory-buffering-storagetype-filesystem) en el repositorio de ejemplos de AWS para Fluent Bit.
## Descripción de `storage.total_limit_size`
El parámetro `storage.total_limit_size` de cada complemento OUTPUT controla el espacio máximo en disco para los datos almacenados en búfer para esa salida. Cuando se alcanza este límite, se eliminan los registros más antiguos de esa salida para tener espacio para los nuevos datos. Cuando el espacio en disco se agota por completo, Fluent Bit no puede poner en cola los registros y se pierden.
Utilice la siguiente fórmula para calcular el valor de `storage.total_limit_size` adecuado en función de la velocidad de registro y del periodo de recuperación deseado:
```
If log rate is in KB/s, convert to MB/s first:
log_rate (MB/s) = log_rate (KB/s) / 1000
storage.total_limit_size (GB) = log_rate (MB/s) × duration (hours) × 3600 (seconds/hour) / 1000 (MB to GB)
```
En la siguiente tabla se muestran ejemplos de cálculos para velocidades de registro y ventanas de recuperación comunes:
| Velocidad de registro | 1 hora | 6 horas | 12 horas | 24 horas |
| --- | --- | --- | --- | --- |
| 0,25 MB/s | 0,9 GB | 5,4 GB | 10,8 GB | 21,6 GB |
| 0,5 MB/s | 1,8 GB | 10,8 GB | 21,6 GB | 43,2 GB |
| 1 MB/s | 3,6 GB | 21,6 GB | 43,2 GB | 86,4 GB |
| 5 MB/s | 18 GB | 108 GB | 216 GB | 432 GB |
| 10 MB/s | 36 GB | 216 GB | 432 GB | 864 GB |
Para observar el rendimiento máximo y elegir los tamaños de búfer adecuados, utilice la [muestra measure-throughput de FireLens](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/measure-throughput).
Utilice la fórmula, los cálculos de ejemplo y la evaluación comparativa para elegir un valor de `storage.total_limit_size` adecuado que proporcione la mejor vía de recuperación durante una interrupción.
## Requisitos de almacenamiento de tareas de Amazon ECS
Sume todos los valores de `storage.total_limit_size` de las secciones OUTPUT y agregue un búfer para cubrir la sobrecarga. Este total determina el espacio de almacenamiento necesario en la definición de tareas de Amazon ECS. Por ejemplo, se necesitan 3 salidas de 10 GB cada una = 30 GB más búfer (5 a 10 GB) = 35 a 40 GB en total. Si el total supera el espacio de almacenamiento disponible, es posible que Fluent Bit no pueda poner en cola los registros y se pierdan.
Las opciones de almacenamiento siguientes están disponibles:
Montajes vinculados (almacenamiento efímero)
+ Para AWS Fargate, el valor predeterminado es de 20 GB de almacenamiento efímero (200 GB como máximo). Configúrelo con `ephemeralStorage` en la definición de tareas. Para obtener más información, consulte [EphemeralStorage](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-taskdefinition-ephemeralstorage.html) en la *Guía del usuario de AWS CloudFormation*.
+ Para EC2, el valor predeterminado es de 30 GB cuando se utiliza la AMI optimizada para Amazon ECS (compartida entre el sistema operativo y Docker). Aumente cambiando el tamaño del volumen raíz.
Volúmenes de Amazon EBS
+ Proporciona almacenamiento en bloques de alto rendimiento, duradero y de alta disponibilidad.
+ Requiere configurar el volumen y definir `mountPoint` en la definición de la tarea apuntando a `storage.path` (predeterminado: `/var/log/flb-storage/`).
+ Para obtener más información, consulte [Aplazamiento de la configuración del volumen a la hora de lanzamiento en la definición de la tarea de Amazon ECS](specify-ebs-config.md).
Volúmenes de Amazon EFS
+ Proporciona almacenamiento de archivos sencillo y escalable.
+ Requiere configurar el volumen y definir `mountPoint` en la definición de la tarea apuntando a `storage.path` (predeterminado: `/var/log/flb-storage/`).
+ Para obtener más información, consulte [Especificación de un sistema de archivos de Amazon EFS en la definición de tareas de Amazon ECS](specify-efs-config.md).
Para obtener más información sobre los volúmenes de datos, consulte [Opciones de almacenamiento para las tareas de Amazon ECS](using_data_volumes.md).
## Optimizar configuración de salida
Los problemas de red, las interrupciones del servicio y la limitación del destino pueden impedir que se entreguen los registros. La configuración de salida adecuada garantiza la resiliencia sin pérdida de datos.
Cuando se produce un error al vaciar la salida, Fluent Bit puede volver a intentar la operación. Los clústeres de la región pueden obtener los siguientes beneficios.
`retry_limit`
El número máximo de reintentos después del intento inicial antes de eliminar los registros. El valor predeterminado es 1. Por ejemplo, `retry_limit 3` significa 4 intentos en total (1 inicial más 3 reintentos). Para los entornos de producción, recomendamos 15 o más, lo que cubre varios minutos de interrupción con un retraso exponencial.
Establézcalo en `no_limits` o `False` para reintentos infinitos:
+ Con el almacenamiento en búfer de memoria, los reintentos infinitos hacen que el complemento de entrada se detenga cuando se alcanzan los límites de memoria.
+ Con el almacenamiento en búfer del sistema de archivos, los registros más antiguos se eliminan cuando se alcanza `storage.total_limit_size`.
Tras agotar todos los reintentos (1 reintento inicial y `retry_limit` reintentos), se eliminan los registros. Los complementos de AWS con `auto_retry_requests true` (predeterminado) proporcionan una capa de reintentos adicional antes del mecanismo de reintento de Fluent Bit. Para obtener más información, consulte [Configure retries](https://docs.fluentbit.io/manual/administration/scheduling-and-retries#configure-retries) en la documentación de Fluent Bit.
Por ejemplo, `retry_limit 3` con la configuración predeterminada, (`scheduler.base 5`, `scheduler.cap 2000`, `net.connect_timeout 10s`) proporciona aproximadamente 70 segundos de tiempo de espera del programador (10 s \+ 20 s \+ 40 s), 40 segundos de tiempo de espera de conexión a la red (4 intentos × 10 s), además de AWS reintentos del complemento, lo que supone un total de aproximadamente 2 a 10 minutos, según las condiciones de la red y los tiempos de espera de TCP del sistema operativo.
`scheduler.base`
Los segundos básicos entre reintentos (predeterminado: 5). Recomendamos 10 segundos.
`scheduler.cap`
Los segundos máximos entre reintentos (predeterminado: 2000). Recomendamos 60 segundos.
El tiempo de espera entre reintentos utiliza un retroceso exponencial con fluctuación:
```
wait_time = random(base, min(base × 2^retry_number, cap))
```
Por ejemplo, con `scheduler.base 10` y `scheduler.cap 60`:
+ Primer reintento: espera aleatoria de entre 10 y 20 segundos
+ Segundo reintento: espera aleatoria de entre 10 y 40 segundos
+ Tercer reintento y posteriores: espera aleatoria de entre 10 y 60 segundos (límite máximo)
Para obtener más información, consulte [Configure wait time for retry](https://docs.fluentbit.io/manual/administration/scheduling-and-retries#configure-wait-time-for-retry) y [Networking](https://docs.fluentbit.io/manual/administration/networking) en la documentación de Fluent Bit.
`workers`
El número de hilos para el procesamiento de salida en paralelo. Varios trabajos permiten vaciados concurrentes, lo que mejora el rendimiento al procesar muchos fragmentos.
`auto_retry_requests`
Opción específica del complemento de AWS que proporciona una capa de reintentos adicional antes del mecanismo de reintento integrado de Fluent Bit. El valor predeterminado es `true`. Cuando está activado, el complemento de salida de AWS reintenta internamente las solicitudes con error antes de que se considere que se ha producido un error en la solicitud y queda sujeta a la configuración `retry_limit`.
El parámetro `Grace` de la sección `[SERVICE]` establece el tiempo de espera de Fluent Bit durante el apagado para vaciar los datos almacenados en el búfer. El período de `Grace` debe coordinarse con el valor de `stopTimeout` del contenedor. Asegúrese de que el valor `stopTimeout` supere el período `Grace` para permitir que Fluent Bit complete la descarga antes de recibir `SIGKILL`. Por ejemplo, si el valor de `Grace` es de 120 segundos, establezca el de `stopTimeout` en 150 segundos.
El siguiente ejemplo muestra una configuración de Fluent Bit completa con todos los ajustes recomendados para escenarios de alto rendimiento:
```
[SERVICE]
# Flush logs every 1 second
Flush 1
# Wait 120 seconds during shutdown to flush remaining logs
Grace 120
# Directory for filesystem buffering
storage.path /var/log/flb-storage/
# Limit chunks stored 'up' in memory (reduce for memory-constrained environments)
storage.max_chunks_up 32
# Flush backlog chunks to destinations during shutdown (prevents log loss)
storage.backlog.flush_on_shutdown On
# Minimum seconds between retries
scheduler.base 10
# Maximum seconds between retries (exponential backoff cap)
scheduler.cap 60
[INPUT]
Name forward
unix_path /var/run/fluent.sock
# Run input in separate thread to prevent blocking
threaded true
# Enable filesystem buffering for persistence
storage.type filesystem
[OUTPUT]
Name cloudwatch_logs
Match *
region {{us-west-2}}
log_group_name {{/aws/ecs/my-app}}
log_stream_name $(ecs_task_id)
# Use multiple workers for parallel processing
workers 2
# Retry failed flushes up to 15 times
retry_limit 15
# Maximum disk space for buffered data for this output
storage.total_limit_size 10G
```
## Descripción de los escenarios de pérdida de datos
Los registros se pueden perder durante interrupciones prolongadas o problemas con los destinos de salida. Las recomendaciones de configuración de esta guía son los mejores enfoques para minimizar la pérdida de datos, pero no pueden garantizar una pérdida cero en caso de errores prolongados. Comprender estas situaciones lo ayuda a configurar Fluent Bit para maximizar la resiliencia.
Los registros se pueden perder de dos maneras: los registros más antiguos se eliminan cuando se llena el almacenamiento o los registros más nuevos se rechazan cuando el sistema no puede aceptar más datos.
### Se eliminan los registros más antiguos
Los registros almacenados en búfer más antiguos se eliminan cuando se agotan los reintentos o cuando se llena `storage.total_limit_size` y se tiene que dejar espacio para nuevos datos.
Límite de reintentos superado
Se produce después del reintento del complemento de AWS (si `auto_retry_requests true`) más 1 intento inicial de Fluent Bit más `retry_limit` reintentos. Para mitigarlo, configure `retry_limit no_limits` por complemento OUTPUT para reintentos infinitos:
```
[OUTPUT]
Name cloudwatch_logs
Match ApplicationLogs
retry_limit no_limits
auto_retry_requests true
```
Los reintentos infinitos evitan que se eliminen los registros debido al agotamiento de los reintentos, pero pueden provocar que `storage.total_limit_size` se llene.
Se alcanzó el límite de almacenamiento (almacenamiento en búfer del sistema de archivos)
Se produce cuando el destino de salida no está disponible durante más tiempo del que el valor de `storage.total_limit_size` configurado puede almacenar en búfer. Por ejemplo, un búfer de 10 GB a una velocidad de registro de 1 MB/s proporciona aproximadamente 2,7 horas de almacenamiento en búfer. Para mitigarlo, aumente `storage.total_limit_size` por cada complemento OUTPUT y aprovisione un almacenamiento de tareas de Amazon ECS adecuado:
```
[OUTPUT]
Name cloudwatch_logs
Match ApplicationLogs
storage.total_limit_size 10G
```
### Se rechazan los registros más recientes
Los registros más recientes se eliminan cuando se agota el espacio en disco o cuando la entrada se detiene debido a `Mem_Buf_Limit`.
Se ha agotado el espacio en disco (almacenamiento en búfer del sistema de archivos)
Se produce cuando el espacio en disco se agota por completo, Fluent Bit no puede poner en cola los nuevos registros y se pierden. Para mitigarlo, sume todos los valores de `storage.total_limit_size` y aprovisione un almacenamiento de tareas de Amazon ECS adecuado. Para obtener más información, consulte [Requisitos de almacenamiento de tareas de Amazon ECS](#firelens-storage-task-requirements).
Se alcanza el límite de memoria (almacenamiento en búfer de memoria)
Se produce cuando el destino de salida no está disponible y el búfer de memoria se llena. Los complementos de entrada pausados dejan de aceptar nuevos registros. Para mitigarlo, use `storage.type filesystem` para mejorar la resiliencia o aumente `Mem_Buf_Limit`.
### Prácticas recomendadas para reducir al mínimo la pérdida de datos
Tenga en cuenta las siguientes prácticas recomendadas para reducir al mínimo la pérdida de datos:
+ **Utilice el almacenamiento en búfer del sistema de archivos**: establezca `storage.type filesystem` para mejorar la resiliencia durante las interrupciones.
+ **Dimensione el almacenamiento de forma adecuada**: calcule `storage.total_limit_size` en función de la velocidad de registro y del intervalo de recuperación deseado.
+ **Aprovisione el disco adecuado**: asegúrese de que la tarea de Amazon ECS tenga suficiente almacenamiento efímero, Amazon EBS o Amazon EFS.
+ **Configure el comportamiento de los reintentos**: equilibre entre `retry_limit` (elimina los registros tras agotar los reintentos) y `no_limits` (lo reintenta indefinidamente, pero puede que se llene el espacio de almacenamiento).
## Utilice el registro multidestino para garantizar la fiabilidad
El envío de registros a varios destinos elimina los puntos únicos de error. Por ejemplo, si Registros de CloudWatch sufre una interrupción, los registros seguirán llegando a Amazon S3.
El registro multidestino ofrece los siguientes beneficios. El complemento de salida de Amazon S3 también admite opciones de compresión como los formatos .gzip y Parquet, lo que puede reducir los costos de almacenamiento. Para obtener más información, consulte [Compresión de S3](https://docs.fluentbit.io/manual/pipeline/outputs/s3#compression) en la documentación de Fluent Bit.
El registro multidestino puede ofrecer los siguientes beneficios:
+ **Redundancia**: si un destino falla, los registros siguen llegando al otro.
+ **Recuperación**: reconstruya las brechas en un sistema respecto al otro.
+ **Durabilidad**: archive registros en Amazon S3 para la retención a largo plazo.
+ **Optimización de costos**: guarde los registros recientes en un servicio de consultas rápido como Registros de CloudWatch con una retención más corta y, al mismo tiempo, archive todos los registros en un almacenamiento de Amazon S3 de menor costo para conservarlos a largo plazo.
La siguiente configuración de Fluent Bit envía registros tanto a Registros de CloudWatch como a Amazon S3:
```
[OUTPUT]
Name cloudwatch_logs
Match *
region {{us-west-2}}
log_group_name {{/aws/ecs/my-app}}
log_stream_name $(ecs_task_id)
workers 2
retry_limit 15
[OUTPUT]
Name s3
Match *
bucket {{my-logs-bucket}}
region {{us-west-2}}
total_file_size 100M
s3_key_format /fluent-bit-logs/$(ecs_task_id)/%Y%m%d/%H/%M/$UUID
upload_timeout 10m
# Maximum disk space for buffered data for this output
storage.total_limit_size 5G
```
Ambas salidas utilizan el mismo patrón de `Match *`, por lo que todos los registros se envían a ambos destinos de forma independiente. Durante una interrupción en un destino, los registros siguen fluyendo hacia el otro, mientras que las descargas fallidas se acumulan en el búfer del sistema de archivos para volver a intentarlo más adelante.
## Utilice el registro basado en archivos con el complemento de entrada trasera
Para escenarios de alto rendimiento en los que la pérdida de registros es un problema fundamental, puede utilizar un enfoque alternativo: haga que la aplicación escriba los registros en los archivos del disco y configure Fluent Bit para leerlos mediante el complemento de entrada `tail`. Este enfoque evita por completo la capa del controlador de registro de Docker.
El registro basado en archivos con el complemento de entrada trasera proporciona los siguientes beneficios:
+ **Seguimiento del desplazamiento**: el complemento de entrada trasera puede almacenar los desplazamientos de los archivos en un archivo de base de datos (mediante la opción `DB`), lo que proporciona durabilidad tras los reinicios de Fluent Bit. Esto ayuda a evitar la pérdida de registros al reiniciar el contenedor.
+ **Almacenamiento en búfer a nivel de entrada**: puede configurar los límites del búfer de memoria directamente en el complemento de entrada mediante `Mem_Buf_Limit`, lo que proporciona un control más detallado del uso de la memoria.
+ **Evita la sobrecarga de Docker**: los registros pasan directamente de un archivo a Fluent Bit, sin pasar por los búferes de registro de Docker.
Para utilizar este enfoque, la aplicación debe escribir los registros en los archivos en lugar de hacerlo `stdout`. Tanto el contenedor de aplicaciones como el contenedor de Fluent Bit montan un volumen compartido donde se almacenan los archivos de registro.
El siguiente ejemplo muestra una configuración de entrada secundaria con las mejores prácticas:
```
[INPUT]
Name tail
# File path or glob pattern to tail
Path {{/var/log/app.log}}
# Database file for storing file offsets (enables resuming after restart)
DB /var/log/flb_tail.db
# when true, controls that only fluent-bit will access the database (improves performance)
DB.locking true
# Skip long lines instead of skipping the entire file
Skip_Long_Lines On
# How often (in seconds) to check for new files matching the glob pattern
Refresh_Interval 10
# Extra seconds to monitor a file after rotation to account for pending flush
Rotate_Wait 30
# Maximum size of the buffer for a single line
Buffer_Max_Size 10MB
# Initial allocation size for reading file data
Buffer_Chunk_Size 1MB
# Maximum memory buffer size (tail pauses when full)
Mem_Buf_Limit 75MB
```
Cuando utilice el complemento de entrada trasera, tenga en cuenta lo siguiente:
+ Implemente la rotación de registros en los registros de sus aplicaciones para evitar que se agote el disco. Supervise las métricas de volumen subyacentes para medir el rendimiento.
+ Considere configuraciones como `Ignore_Older`, `Read_from_Head` y analizadores multilínea según el formato de registro.
Para obtener más información, consulte [Entrada trasera](https://docs.fluentbit.io/manual/pipeline/inputs/tail) en la documentación de Fluent Bit. Si desea conocer las prácticas recomendadas, consulte la sección [Configuración de entrada trasera con las prácticas recomendadas](https://github.com/aws/aws-for-fluent-bit/blob/mainline/troubleshooting/debugging.md#tail-config-with-best-practices) en la guía de solución de problemas de AWS para Fluent Bit.
## Iniciar sesión directamente en FireLens
Cuando se especifica el controlador de registros `awsfirelens` en una definición de tarea, el agente de contenedor de Amazon ECS introduce las siguientes variables de entorno en el contenedor:
`FLUENT_HOST`
La dirección IP que está asignada al contenedor FireLens.
Si utiliza EC2 con el modo de red `bridge`, la variable de entorno `FLUENT_HOST` del contenedor de aplicaciones puede dejar de ser precisa tras reiniciar el contenedor del router de registro de FireLens (el contenedor con el objeto `firelensConfiguration` en su definición de contenedor). Esto se debe a que `FLUENT_HOST` es una dirección IP dinámica y puede cambiar tras un reinicio. El registro directo desde el contenedor de la aplicación en la dirección IP `FLUENT_HOST` puede empezar a fallar después de que la dirección cambie. Para obtener más información acerca de cómo reiniciar contenedores individuales, consulte [Reinicio de contenedores individuales en tareas de Amazon ECS con políticas de reinicio de contenedores](container-restart-policy.md).
`FLUENT_PORT`
El puerto en el que se está escuchando el protocolo Fluent Forward.
Puede utilizar estas variables de entorno para enviar registros directamente al enrutador de registro de Fluent Bit desde el código de su aplicación mediante el protocolo Fluent Forward, en lugar de escribir en `stdout`. Este enfoque evita la capa de controladores de registro de Docker, lo que proporciona las siguientes ventajas:
+ **Menor latencia**: los registros se transfieren directamente a Fluent Bit sin pasar por la infraestructura de registro de Docker.
+ **Registro estructurado**: envíe datos de registro estructurados de forma nativa sin sobrecargas de codificación JSON.
+ **Mejor control**: su aplicación puede implementar su propia lógica de almacenamiento en búfer y gestión de errores.
Las siguientes bibliotecas de registradores de Fluent son compatibles con el protocolo Fluent Forward y se pueden utilizar para enviar los registros directamente a Fluent Bit:
+ **Go**: [fluent-logger-golang](https://github.com/fluent/fluent-logger-golang)
+ **Python**: [fluent-logger-python](https://github.com/fluent/fluent-logger-python)
+ **Java**: [fluent-logger-java](https://github.com/fluent/fluent-logger-java)
+ **Node.js**: [fluent-logger-node](https://github.com/fluent/fluent-logger-node)
+ **Ruby**: [fluent-logger-ruby](https://github.com/fluent/fluent-logger-ruby)
## Configurar el límite de búfer de Docker
Al crear una definición de tareas, puede indicar el número de líneas de registro que se almacenan en búfer en la memoria mediante la especificación del valor en `log-driver-buffer-limit`. Esto controla el búfer entre Docker y Fluent Bit. Para obtener más información, consulte [Controladores de registro Fluentd](https://docs.docker.com/engine/logging/drivers/fluentd/) en la documentación de Docker.
Utilice esta opción cuando haya un alto rendimiento, ya que Docker podría quedarse sin memoria de búfer y descartar mensajes de búfer para poder agregar nuevos mensajes.
Tenga en cuenta lo siguiente cuando utilice esta opción:
+ Esta opción se admite en el tipo de EC2 y de Fargate con la versión de la plataforma `1.4.0` o posterior.
+ La opción solo es válida cuando `logDriver` se establece en `awsfirelens`.
+ El límite de búfer predeterminado es de `1048576` líneas de registro.
+ El límite del búfer debe ser igual o mayor que `0` y menor que las líneas de registro `536870912`.
+ La cantidad máxima de memoria utilizada para este búfer es el producto del tamaño de cada línea de registro y el tamaño del búfer. Por ejemplo, si las líneas de registro de la aplicación tienen un promedio de `2` KiB, un límite de búfer de 4096 utilizaría como máximo `8` MiB. La cantidad total de memoria asignada a nivel de tarea debe ser superior a la cantidad de memoria asignada a todos los contenedores, además del búfer de memoria del controlador de registro.
La siguiente definición de tarea muestra cómo configurar `log-driver-buffer-limit`:
```
{
"containerDefinitions": [
{
"name": "{{my_service_}}log_router",
"image": "public.ecr.aws/aws-observability/aws-for-fluent-bit:3",
"cpu": 0,
"memoryReservation": 51,
"essential": true,
"firelensConfiguration": {
"type": "fluentbit"
}
},
{
"essential": true,
"image": "public.ecr.aws/docker/library/httpd:latest",
"name": "app",
"logConfiguration": {
"logDriver": "awsfirelens",
"options": {
"Name": "firehose",
"region": "us-west-2",
"delivery_stream": "my-stream",
"log-driver-buffer-limit": "52428800"
}
},
"dependsOn": [
{
"containerName": "{{my_service_}}log_router",
"condition": "START"
}
],
"memoryReservation": 100
}
]
}
```