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. Para ver más ejemplos, consulte Ejemplos de FireLens en Amazon ECS en GitHub.

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 en la documentación de Fluent Bit y 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

[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 en la documentación de Fluent Bit y Memory Buffering Only 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 de Fluent Bit.

El uso del almacenamiento en búfer del sistema de archivos proporciona los siguientes beneficios:

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:

Para obtener más información, consulte Filesystem Buffering en la documentación de Fluent Bit y Filesystem and Memory Buffering 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:

Para observar el rendimiento máximo y elegir los tamaños de búfer adecuados, utilice la muestra measure-throughput de FireLens.

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:

Para obtener más información sobre los volúmenes de datos, consulte Opciones de almacenamiento para las tareas de Amazon ECS.

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.

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:

Para obtener más información, consulte Configure wait time for retry y Networking en la documentación de Fluent Bit.

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.

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.

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 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 en la documentación de Fluent Bit.

El registro multidestino puede ofrecer los siguientes beneficios:

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:

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:

Para obtener más información, consulte Entrada trasera 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 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:

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:

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:

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

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
        }
    ]
}