Una sola aplicación que escribe en un archivo de log es fácil de leer. Un sistema real, varios servicios, una base de datos, un message broker, un proxy de entrada, cada uno registrando en su propio formato en su propia ubicación, no lo es. Esta guía cubre por qué eso se convierte en un problema real a escala y el modelo de pipeline que usa Fluentd para resolverlo.

Para qué sirven realmente los logs

Los logs no son solo una ocurrencia tardía de depuración. Los mismos datos de log suelen servir a varios propósitos distintos a la vez:

• Depuración, rastrear lo ocurrido en torno al momento de un error.
• Seguridad, detectar actividad sospechosa, como inicios de sesión fallidos repetidos desde una misma dirección, que solo aparece al correlacionar eventos a lo largo del tiempo o entre fuentes.
• Cumplimiento normativo, donde algunos sectores exigen conservar registros específicos durante un periodo definido.
• Auditoría, responder a “quién accedió a qué y cuándo” a posteriori.

Cada uno de estos necesita los datos en un solo lugar, con capacidad de búsqueda, no dispersos por máquinas individuales.

Dónde falla el logging ingenuo

Dos puntos de partida comunes chocan con el mismo muro a medida que crece un sistema:

Escribir en archivos locales. Es simple, y es exactamente como la mayoría del software registra por defecto, pero un archivo de texto en bruto no está hecho para el análisis. Comparar marcas de tiempo entre los archivos de log de cinco aplicaciones distintas, cada una con un formato diferente, para reconstruir el recorrido de una petición por un sistema es tedioso en el mejor de los casos y a menudo impracticable a mano.

Registrar directamente en una base de datos. Si envías todo directamente a Elasticsearch o un almacén similar, ahora cada aplicación necesita su propia librería cliente, su propia gestión de conexiones y su propio acuerdo sobre qué campos y formatos usar. Cada desarrollador resuelve en la práctica el mismo problema de integración, y nada garantiza que lo resuelvan de la misma manera dos veces.

Ninguno de los dos enfoques gestiona los componentes de terceros cuyo código no controlas, una base de datos, un message broker, un ingress controller, o los logs de sistema sin más, que producen logs en el formato con el que fueron construidos, no en el que acordaron tus propias aplicaciones.

El modelo de pipeline: recopilar, transformar, enviar

El enfoque de Fluentd es situarse como su propia capa entre el lugar donde se producen los logs y donde terminan, estructurada como un pipeline de tres etapas:

   fuentes                      Fluentd                     destinos
┌─────────────┐          ┌───────────────────┐          ┌──────────────────┐
│ logs de app  │          │                   │          │ Elasticsearch     │
│ logs de      │ ───────▶ │  recopilar →      │ ───────▶ │ S3                │
│  sistema     │          │  analizar →       │          │ Kafka             │
│ stdout de    │          │  filtrar/enriquecer│         │ una base de datos │
│  contenedores│          │                   │          │  etc.             │
└─────────────┘          └───────────────────┘          └──────────────────┘

Fluentd recopila logs dondequiera que se produzcan, sin importar la fuente ni el formato original. Analiza y transforma los datos para darles una estructura coherente, convirtiendo texto no estructurado en datos clave-valor. Por el camino, puede enriquecer las entradas con contexto útil (qué pod, qué host, qué contenedor produjo esta línea) o filtrarlas, descartando lo que no hace falta o redactando campos sensibles. Por último, envía el resultado a uno o más destinos, una plataforma de análisis, un almacén de datos, almacenamiento en frío, sin que cada aplicación de origen necesite saber o preocuparse por dónde terminan finalmente sus logs.

Tags: cómo enruta Fluentd los datos por el pipeline

Cada entrada de log que recopila Fluentd recibe un tag, una cadena que asignas al configurar de dónde procede la entrada. Los tags son lo que las etapas posteriores del pipeline usan para decidir qué se aplica a qué: “analiza las entradas con el tag apache.access con el formato de log de Apache”, “filtra las entradas con tag app.* para eliminar un campo”, “envía las entradas con tag *.errors a este destino y todo lo demás a aquel”. Los detalles de escribir esa configuración son la siguiente guía de esta serie; lo que importa aquí es el concepto: un tag es el hilo que conecta un dato con la fuente de la que procede, hasta el lugar donde finalmente se envía.

Por qué vale la pena una capa dedicada

La alternativa a un pipeline como este no es “sin trabajo”, sino la misma lógica de análisis, enriquecimiento y enrutamiento reimplementada dentro de cada aplicación que registra algo, de forma inconsistente, cada una un poco distinta. Centralizarla en una sola capa configurable significa que esa lógica se escribe una vez, y cada aplicación nueva solo necesita producir logs en el formato que le resulte más fácil, texto plano, JSON, lo que ya escriba una herramienta de terceros, y Fluentd se encarga de hacerlo coherente a partir de ahí.