En este artículo exploramos la importancia de tratar los logs como flujos de datos (streams) en lugar de archivos estáticos en el contexto de aplicaciones modernas. Los logs son fundamentales para tener visibilidad sobre el comportamiento de las aplicaciones, detectar y resolver problemas, y operar plataformas en producción con confianza.

Veremos cómo funcionan STDOUT y STDERR en Linux — especialmente en entornos de contenedores — y cómo Fluent Bit se configura para recopilar, transformar y enviar registros a destinos como Elasticsearch o AWS CloudWatch.

Logs como streams

En aplicaciones modernas, la recomendación es tratar los logs como un stream de datos, no como archivos estáticos. Los logs se generan de manera continua y se transmiten a un lugar central donde pueden ser recopilados, analizados y almacenados. En contenedores, las aplicaciones envían los logs al STDOUT y al STDERR.

Para entender el patrón conviene recordar que en Linux cada proceso tiene tres descriptores de archivo estándar:

  • STDIN — entrada estándar, desde donde un proceso lee su input.
  • STDOUT — salida estándar, donde un proceso escribe su salida.
  • STDERR — salida de error estándar, donde un proceso escribe sus mensajes de error.

En un entorno de contenedores, cada contenedor tiene su propio STDOUT y STDERR. La aplicación se codifica para que los logs generados se envíen al STDOUT o al STDERR. Muchas veces esto se logra configurando el driver de logs del framework de desarrollo. Si la aplicación no se puede modificar, una solución alternativa es crear un symbolic link entre los archivos de log y /dev/stdout o /dev/stderr. Esta técnica se ve, por ejemplo, en el Dockerfile oficial de nginx.

Al gestionar logs como streams, podemos aprovechar diversas estrategias para recopilarlos, transformarlos y enrutarlos. Este enfoque libera a las aplicaciones de la responsabilidad de determinar el destino final de almacenamiento, fomentando aplicaciones modulares en línea con la arquitectura de microservicios.

Fluent Bit y EKS

Fluent Bit es un procesador y enrutador de logs ligero. Permite tomar los logs generados por contenedores, transformarlos y llevarlos a su destino final.

En el contexto de Amazon EKS, la ubicación predeterminada para los registros de los contenedores es el directorio /var/log/containers. Los registros de cada contenedor se almacenan en un archivo separado con un nombre que incluye el ID del contenedor y un timestamp.

Fluent Bit puede configurarse para leer registros de este directorio, enriquecerlos con metadata de Kubernetes (namespace, pod, labels) y llevarlos a diferentes destinos.

Instalación de Fluent Bit en EKS

Vamos a instalar y configurar Fluent Bit en Amazon EKS mediante Helm.

Primero, agregamos el repositorio Helm de Fluent Bit:

helm repo add fluent https://fluent.github.io/helm-charts

Luego instalamos Fluent Bit:

helm upgrade --install fluent-bit fluent/fluent-bit

Este comando inicia el proceso de instalación de Fluent Bit en el clúster EKS. Helm permite personalizar la configuración mediante un archivo de valores personalizado, lo cual es útil para sobrescribir los valores por defecto del chart y adaptarlos a necesidades específicas.

Ruteo de logs a OpenSearch

Una acción muy común es configurar hacia dónde queremos enrutar los logs. Por ejemplo, podemos enrutarlos a un cluster de Amazon OpenSearch. Para eso creamos un archivo values.yaml que sobrescribe el values.yaml por defecto del chart:

config:
  outputs: |
    [OUTPUT]
        Name            es
        Match           *
        Host            ${ES_ENDPOINT}
        Port            443
        TLS             On
        AWS_Auth        On
        AWS_Region      ${AWS_REGION}
        Retry_Limit     6

Una vez creado el archivo, ejecutamos:

helm upgrade --install fluent-bit fluent/fluent-bit -f /ruta/al/values.yaml

Con esta configuración, Fluent Bit enruta los registros de los contenedores hacia el cluster de Amazon OpenSearch, habilitando búsqueda y análisis centralizado de logs.

Otras opciones de output

Fluent Bit soporta muchos destinos comunes en arquitecturas AWS:

  • Amazon CloudWatch Logs — output cloudwatch_logs
  • Amazon Kinesis Data Firehose — para streaming a S3, Redshift o destinos custom
  • Amazon S3 — para archivado de larga duración a bajo costo
  • OpenSearch / Elasticsearch — para búsqueda y análisis (mostrado arriba)
  • Datadog, New Relic, Splunk — outputs nativos para observabilidad multi-cloud

La elección depende del costo de almacenamiento y del SLO de búsqueda que el negocio requiera.

Buenas prácticas para production

  • Filtrado y parsing temprano — usa filtros (kubernetes, parser, modify) para enriquecer y reducir el volumen de logs antes de enviarlo al destino. Reduce factura significativamente.
  • Multi-output con buffering — escribe simultáneamente a CloudWatch (operacional) y a S3 (long-term archive). El buffer en disco previene pérdida ante caídas del destino.
  • Sample logs verbosos — para logs de nivel DEBUG o INFO de muy alto volumen, considera sampling para reducir costo sin perder visibilidad de patrones.
  • Configura límites de memoria del DaemonSet de Fluent Bit acorde al volumen de logs por nodo.

Cómo lo aplicamos en Caleidos

En clientes con plataformas EKS de tamaño mediano y grande, Fluent Bit suele ser la pieza más eficiente para gestionar logs como streams hacia OpenSearch o CloudWatch. Combinado con Edge Delta para procesamiento en el edge, frecuentemente reducimos el volumen de logs facturado entre 40% y 60% sin perder visibilidad operacional. Combinándolo con Feature Flags en AWS AppConfig tienes la capacidad de cambiar comportamientos en runtime y observar el impacto inmediatamente.

Caleidos diseña, implementa y opera plataformas de observabilidad full-stack como parte de nuestro servicio Observabilidad cloud end-to-end, incluyendo dashboards ejecutivos, alertas predictivas y operación 24×7 con Caleidos Lens©.

¿Quieres mejor visibilidad sobre tu plataforma EKS? Hablemos →