Al cerrar la lección anterior quedó planteada una pregunta que las métricas no pueden responder. Cuando ApiReservasTasaErrorAlta dispara a las 03:14, sabemos que el 7 % de las peticiones falla, en qué ruta y con qué latencia. Lo que no sabemos es por qué: la excepción concreta, el mensaje que devolvió PostgreSQL, la línea de código que reventó. Eso no vive en una métrica. Vive en los logs.

Y hoy, en Rutas Norte, los logs son un desastre organizado: están repartidos por los nodos, se pierden cuando un pod se recrea, no hay forma de buscar entre componentes y desaparecen del todo si el nodo muere. En esta lección montamos la pila completa que anunciamos en 06-02 al desplegar el recolector como DaemonSet: Elasticsearch, Fluentd y Kibana. Veremos cómo funciona el registro en Kubernetes por debajo, cómo se recolectan y enriquecen los logs, por qué el JSON estructurado es la decisión que más mejora todo el sistema, y —crítico para una plataforma que guarda el DNI y el teléfono de sus clientes— qué no debe acabar nunca escrito en un log.

1. Por qué kubectl logs no basta
2. Cómo funciona el registro en Kubernetes por debajo
3. kubectl logs a fondo: la herramienta de primera línea y sus límites
4. La arquitectura del patrón de recolección por nodo
5. Fluentd frente a Fluent Bit
6. La configuración real del recolector
7. Elasticsearch: índices, plantillas y ciclo de vida
8. Kibana: patrón de índice, KQL y cuadro de mando de errores
9. Logs estructurados en JSON: la decisión que más rentabilidad da
10. Correlación entre logs y métricas
11. Qué NO se debe registrar nunca
12. Alternativas más ligeras y el coste real de una pila de registro
13. Errores comunes y consejos
14. Ejercicios

kubectl logs es la primera herramienta que aprendimos en 01-05 y sigue siendo utilísima. Pero tiene cuatro límites estructurales que la hacen insuficiente en cuanto la plataforma crece.

Se pierde al recrear el pod. Los logs de un contenedor viven en el sistema de ficheros del nodo, asociados al pod. Cuando el pod se borra —un despliegue, un desalojo, un escalado— los ficheros se borran con él. Si api-reservas entró en CrashLoopBackOff a las 03:14 y a las 08:00 alguien ya lo había reiniciado a mano, la evidencia ha desaparecido.

No busca entre componentes. Un cliente reporta que su compra falló. La petición pasó por tienda-web, luego por api-reservas, que consultó redis-cache y postgres-reservas, llamó a la pasarela externa y encoló un mensaje para worker-notificaciones. Eso son seis kubectl logs distintos, en pods distintos, cada uno con su propio formato y sin ninguna forma de saber qué línea de uno corresponde a qué línea del otro.

No correlaciona. Aunque abras las seis terminales, tendrás que cuadrar marcas de tiempo a ojo. Con seis réplicas de api-reservas ni siquiera sabes en cuál cayó la petición.

Desaparece con el nodo. Si rutas-norte-worker-2 muere, todos sus logs mueren con él. Y precisamente cuando un nodo muere es cuando más falta hacen.

A esos cuatro se suma uno de gobernanza: no hay retención definida ni control de acceso granular. Cualquiera con permiso pods/log ve todo lo que escriben las aplicaciones, incluidos los datos que no deberían estar ahí. Volveremos a esto en el apartado 11.

Antes de recolectar nada hay que entender dónde están físicamente los logs. Sin esto, la configuración del recolector es magia.

Kubernetes no define ningún API de logs para las aplicaciones. El contrato es el de Docker y el de los doce factores:

La aplicación escribe sus logs a la salida estándar (stdout) y a la de error (stderr). No gestiona ficheros, ni rotación, ni destinos.

Una aplicación que escribe en /var/log/miapp.log dentro del contenedor está haciéndolo mal: ese fichero es invisible para Kubernetes, crece sin control dentro del contenedor y desaparece al reiniciarse.

1. El proceso escribe una línea en stdout.
2. El runtime de contenedores (containerd o CRI-O) captura esa salida.
3. El runtime la escribe en un fichero del nodo, en formato CRI.
4. El kubelet gestiona ese fichero: lo rota y crea enlaces simbólicos con nombre parlante.
5. kubectl logs pide al kubelet que lea ese fichero y lo devuelve.

Entremos en un nodo de nuestro minikube a mirarlos:

El nombre del fichero es la clave de todo. Su estructura es:

De ahí el recolector extrae, sin consultar a nadie, el pod, el namespace y el contenedor de cada línea. Es lo que hace posible el enriquecimiento del apartado 6.

Fíjate también en que postgres-reservas-0 tiene dos ficheros: uno por el contenedor postgres y otro por el sidecar exportador-pg que añadimos en 06-04. Cada contenedor tiene su propio flujo de logs.

Cada línea tiene cuatro campos separados por espacios:

La etiqueta P aparece cuando una línea supera los 16 KB: el runtime la parte. Un recolector mal configurado tratará cada trozo como una línea distinta. Fluentd y Fluent Bit saben reensamblarlas, pero hay que activarlo.

Sin rotación, un contenedor charlatán llenaría el disco del nodo y provocaría desalojos de pods. El kubelet la gestiona con dos parámetros de su configuración:

Con los valores por defecto, cada contenedor conserva como máximo 50 MB de logs en el nodo. api-reservas bajo carga genera unos 200 MB al día por réplica: eso significa que conserva menos de seis horas de historia.

Consecuencia directa y muy concreta: si el incidente ocurrió a las 03:14 y lo miras a las 11:00, los logs ya se han rotado y ya no existen, aunque el pod no se haya reiniciado. Es una razón adicional, junto a las cuatro del apartado 1, para centralizar.

Aunque montemos EFK, kubectl logs sigue siendo lo primero que se ejecuta ante un problema. Merece dominarse.

El flag --prefix antepone el nombre del pod a cada línea, imprescindible al usar -l:

Combinaciones útiles en el día a día:

Regla de uso: kubectl logs para lo que está pasando ahora; la pila centralizada para lo que pasó.

Hay tres formas de recolectar logs en Kubernetes. Solo una es la buena para el caso general.

Elegimos el primero, y ya lo tenemos desplegado: en 06-02, al estudiar DaemonSets, desplegamos un recolector de logs con un pod por nodo, tolerations para el plano de control y un hostPath montado sobre /var/log/containers, anunciando que la pila completa se montaría aquí. Ha llegado el momento.

Las cuatro responsabilidades del recolector:

1. Leer los ficheros de /var/log/containers/, siguiendo las escrituras nuevas y recordando por dónde iba tras un reinicio.
2. Parsear el formato CRI y, si el contenido es JSON, expandirlo en campos.
3. Enriquecer con los metadatos de Kubernetes: namespace, pod, contenedor, nodo, etiquetas y anotaciones del pod. Estos no están en el fichero: se obtienen consultando la API a partir del nombre del fichero.
4. Enviar al almacén, con buffer y reintentos para no perder nada si el destino se cae.

El enriquecimiento es lo que convierte una línea de texto en un documento consultable:

Ahora sí se puede buscar "todos los errores de api-reservas en pro entre las 03:00 y las 04:00", que es lo que necesitábamos.

Hemos puesto un agregador entre los agentes y Elasticsearch. No es obligatorio, pero en producción se justifica:

• Los agentes de nodo (Fluent Bit) se quedan ligerísimos: solo leer y reenviar.
• El parseo pesado, el enmascarado de datos sensibles y el enrutado se hacen en un solo sitio, más fácil de auditar y de cambiar.
• Elasticsearch recibe conexiones de 3 agregadores en vez de 30 agentes, lo que reduce mucho la presión.
• El agregador hace de amortiguador: si Elasticsearch se cae media hora, el buffer del agregador retiene los datos.

Los dos son proyectos de la CNCF y de la misma familia. La confusión sobre cuál usar es constante.

La regla práctica que sigue la industria:

Fluent Bit como agente en cada nodo (DaemonSet): consume casi nada, y multiplicado por 30 nodos esa diferencia importa mucho.

Fluentd como agregador central (Deployment): donde hace falta la flexibilidad de los mil plugins, el enrutado complejo y las transformaciones caras.

Para Rutas Norte con tres nodos, honestamente, Fluent Bit solo bastaría. Montamos los dos niveles porque el enmascarado de datos personales del apartado 11 se beneficia mucho de centralizarse, y porque es la arquitectura que encontrarás en cualquier clúster serio.

Comparación de coste en nuestro clúster:

Recuperamos y completamos el DaemonSet de 06-02:

Nota de seguridad, que retomaremos en el módulo 8. Este DaemonSet monta hostPath sobre el sistema de ficheros del nodo. Aunque sea en solo lectura, cualquiera que pueda ejecutar un exec en este pod puede leer los logs de todos los contenedores del nodo, incluidos los de otros namespaces. El recolector es un objetivo de alto valor: debe tener su propio namespace, RBAC mínimo y acceso muy restringido.

Este es el detalle que más frustración causa y que más se agradece resolver.

Una excepción de Node.js llega al log así:

Para el runtime son cinco líneas independientes. Sin el filtro multilínea, Elasticsearch recibe cinco documentos:

• Uno con Error: connection pool exhausted, sin ninguna traza.
• Cuatro con fragmentos de traza, sin ningún contexto de qué error los produjo.

Y en Kibana, ordenados por fecha entre los logs de otros cinco pods, resulta imposible reconstruir la excepción. Con veinte líneas de traza, el problema se multiplica.

El filtro multiline reconoce que las líneas que empiezan por espacios y at son continuación de la anterior y las une en un solo documento con la traza completa en un campo. Es la diferencia entre poder depurar y no poder.

El parámetro retry_forever true en producción y false fuera de ella es una decisión de diseño consciente: perder logs de rutas-norte-dev durante una caída de Elasticsearch es aceptable; perder los de producción, no.

El recolector es infraestructura crítica: si falla en silencio, te quedas sin logs sin enterarte.

Y la alerta correspondiente, con el criterio de 07-04:

Elasticsearch es un motor de búsqueda distribuido que indexa documentos JSON. Para nuestro caso, cada línea de log enriquecida es un documento.

Los logs son datos temporales que envejecen: los de hoy se consultan constantemente, los de hace tres semanas casi nunca, y los de hace un año probablemente nunca. Por eso no se guardan todos en un índice, sino en índices por día:

Ventajas decisivas de esta división:

• Borrar es instantáneo. Eliminar un índice entero es una operación de metadatos. Borrar documentos sueltos dentro de un índice grande es lentísimo y costoso.
• Las consultas por fecha solo tocan los índices necesarios. Buscar en las últimas 24 horas no recorre 30 días de datos.
• Cada índice puede tener configuración distinta: los recientes en discos rápidos, los antiguos comprimidos.

Una plantilla define cómo se configura cualquier índice nuevo que coincida con un patrón. Sin ella, Elasticsearch adivina los tipos de cada campo, y adivina mal.

La distinción entre keyword y text es fundamental y confunde a todo el mundo:

Si nivel fuera text, no podrías hacer una agregación "cuántos logs por nivel", que es exactamente lo que quieres en un cuadro de mando. Si mensaje fuera keyword, no podrías buscar "pool" dentro de "connection pool exhausted".

refresh_interval: 30s es un ajuste de rendimiento importante: por defecto es 1 segundo, lo que obliga a Elasticsearch a hacer visible cada documento casi al instante, a un coste alto. Para logs, 30 segundos de retraso es perfectamente aceptable y multiplica el rendimiento de escritura.

La gestión del ciclo de vida de índices automatiza el envejecimiento. Sin ella, alguien tiene que acordarse de borrar índices antiguos, y nadie se acuerda hasta que el disco se llena.

El punto crítico: la fase de borrado. Los 30 días no son un número técnico, es una decisión de negocio y de cumplimiento normativo. Si los logs contienen datos personales (que no deberían, pero es lo que ocurre en la práctica), la retención debe ajustarse a lo que exija la normativa aplicable y a lo que haya definido el responsable de protección de datos de la empresa. Volvemos a ello en el apartado 11.

Esta es la parte que se subestima siempre.

Y el mínimo de recursos de cómputo:

Elasticsearch necesita tres nodos, no uno. Con un solo nodo no hay tolerancia a fallos y la pila de logs se cae entera cuando ese pod se reinicia. Con dos hay riesgo de cerebro dividido (split-brain). Tres es el mínimo real.

Regla de oro del heap: asigna como máximo el 50 % de la memoria del contenedor y nunca más de 31 GB (por encima de ese umbral la JVM pierde la compresión de punteros y rinde peor con más memoria).

Total aproximado: 24 GB de RAM y 300 GB de disco rápido solo para poder leer logs. Esa cifra es la que hay que poner sobre la mesa antes de decidir, y la que motiva el apartado 12.

Antes de buscar nada hay que decirle a Kibana qué índices consultar. En Stack Management → Data Views → Create data view:

El campo de tiempo es lo que permite el selector de rango temporal y los histogramas. Sin él, Kibana no puede ordenar cronológicamente.

KQL (Kibana Query Language) es el lenguaje de la barra de búsqueda. Es mucho más simple que PromQL y se aprende en diez minutos.

Comparación rápida con lo que ya sabemos:

Volvamos al escenario del apartado 1: la alerta ApiReservasTasaErrorAlta dispara a las 03:14.

Paso 1 — Acotar en el tiempo. Selector de rango: 2026-08-06 03:00 a 2026-08-06 04:00.

Paso 2 — Ver la forma del problema. Consulta amplia y mirar el histograma:

El histograma muestra de un vistazo si los errores empezaron de golpe (un despliegue, una caída) o crecieron progresivamente (agotamiento de un recurso).

Paso 3 — Identificar el componente. En el panel de campos, hacer clic en kubernetes.labels.app para ver la distribución:

Paso 4 — Encontrar el mensaje dominante. Clic en mensaje.keyword:

Paso 5 — Abrir un documento y leer la traza completa. Gracias al filtro multilínea del apartado 6, la excepción está entera en un solo documento.

Paso 6 — Correlacionar hacia atrás. ¿Qué pasó justo antes del primer error? Quitar el filtro de nivel y mirar los cinco minutos anteriores:

Ahí suele aparecer la causa: un despliegue, un CronJob que arrancó, una consulta lenta de PostgreSQL.

Diagnóstico completo en cinco minutos. Con kubectl logs en seis pods, esto habría llevado una hora, y probablemente los logs ya no existirían.

En Dashboards → Create dashboard, con estas visualizaciones:

El mapa de calor por pod es especialmente revelador: si los errores se concentran en un solo pod de seis, el problema es de ese pod (un nodo con problemas, una réplica con estado corrupto). Si están repartidos uniformemente, el problema es sistémico (la base de datos, una dependencia externa). Esa distinción, que en kubectl logs es casi imposible de ver, aquí salta a la vista en un segundo.

Todo lo anterior funciona muchísimo mejor si las aplicaciones escriben JSON en lugar de texto libre. Es, con diferencia, el cambio de menor coste y mayor impacto de toda la lección.

Problemas de esta línea, que parece perfectamente razonable:

• Para filtrar por nivel hay que buscar la subcadena [ERROR], lo que también encuentra un mensaje que diga "el usuario vio un [ERROR] en pantalla".
• La duración 4821ms es texto: no se puede consultar duracion_ms > 1000 ni calcular percentiles.
• El identificador de usuario está incrustado en la frase: no se puede filtrar por él.
• No hay identificador de traza: no se puede seguir esta petición por los demás componentes.
• Si mañana alguien cambia el formato del mensaje, todos los filtros guardados dejan de funcionar.

Ahora sí:

Y agregaciones: la duración media de las peticiones fallidas, los diez trayectos con más errores, la evolución de error_tipo en el tiempo.

Nota crítica sobre lo que no está en ese JSON: no aparece el nombre del cliente, ni su DNI, ni su teléfono, ni su correo. Aparece traza_id, que es un identificador opaco. Si hace falta saber qué cliente era, se cruza el traza_id con la base de datos, en un sistema con control de acceso. Es una decisión deliberada, y el apartado 11 explica por qué es obligatoria.

Todo componente de la plataforma debe emitir estos campos:

Regla sobre mensaje: debe ser constante para el mismo tipo de evento, con los valores variables en campos aparte. "Fallo al crear reserva" con duracion_ms: 4821 es mucho más útil que "Fallo al crear reserva tras 4821ms", porque permite agregar por mensaje.

Y su uso, con el identificador de traza propagado:

Fíjate en el último detalle: devolvemos el traza_id al cliente en el cuerpo del error. Cuando alguien llame al servicio de atención diciendo "no he podido comprar", con ese identificador se localiza en Kibana la petición exacta y todo su recorrido:

Sin filtrar por componente: todos los logs de todos los componentes que participaron en esa petición, en orden. Eso es correlación de verdad.

En 06-04 añadimos a worker-notificaciones un contenedor adaptador que convierte su log propietario a JSON. Aquí es donde se explica del todo por qué.

worker-notificaciones usa una biblioteca antigua de envío de correo que escribe así, y no se puede modificar sin reescribir el componente:

Dos problemas: no es JSON, y contiene la dirección de correo de un cliente, que es un dato personal.

El adaptador, un sidecar que lee ese log y emite JSON limpio:

Su salida:

Dos transformaciones clave: el formato pasa a JSON consultable, y la dirección de correo se sustituye por un hash. El hash permite responder a "¿cuántos correos han fallado para el mismo destinatario?" sin que la dirección aparezca en ningún índice.

Los logs y las métricas son dos vistas del mismo sistema, y su valor se multiplica cuando se pueden cruzar. La clave es usar las mismas etiquetas en ambos.

Con esa correspondencia, el flujo de investigación es directo:

Tres formas prácticas de enlazar ambos mundos:

1. Enlace desde el panel de Grafana. En las opciones del panel, un Data link que abre Kibana con los filtros ya aplicados:

Con eso, un clic en el pico del gráfico lleva a los logs de ese pod en esa ventana exacta. Ahorra muchísimo tiempo bajo presión.

2. Métricas derivadas de logs. Fluentd puede contar eventos y exponerlos a Prometheus, lo que permite alertar sobre patrones de log:

Cuidado con la cardinalidad, exactamente igual que en 07-03: nunca uses el mensaje completo como etiqueta.

3. Grafana como visor unificado. Grafana puede añadir Elasticsearch como fuente de datos adicional y mostrar en el mismo cuadro de mando un panel de métricas y otro de logs. Con la fuente Loki (apartado 12) la integración es aún más estrecha.

Lo que falta para cerrar el círculo por completo son las trazas distribuidas (OpenTelemetry, Jaeger, Tempo): la tercera pata de la observabilidad, que registra el recorrido completo de una petición con los tiempos de cada salto. Nuestro traza_id es una versión artesanal y muy útil de esa idea, pero las trazas quedan fuera del alcance de este curso.

Este apartado es el más importante de la lección, y el que más consecuencias tiene fuera del ámbito técnico.

postgres-reservas guarda datos personales de los clientes de Rutas Norte: nombre, DNI, teléfono y correo electrónico. Y en cuanto montas una pila de registro centralizado, todo lo que las aplicaciones escriban se copia, se indexa y se conserva durante 30 días en un sistema al que accede mucha más gente que a la base de datos.

Ese es el riesgo real, y es fácil de subestimar. Un log tan inocente como este:

acaba de convertir tu sistema de logs en un fichero de datos personales con todas las obligaciones que eso conlleva.

Un caso que se escapa siempre: los logs de acceso del Ingress y de tienda-web. Registran la URL completa de cada petición. Si alguna ruta lleva datos en la cadena de consulta, quedan registrados sin que la aplicación intervenga. Solución: no poner datos sensibles en URLs, jamás.

Ninguna es suficiente por sí sola. Se aplican todas.

Capa 1 — En el código (la más eficaz). Que el dato no se escriba nunca. Es la única defensa que no tiene fugas, porque si nunca sale del proceso no hay nada que filtrar. Requiere revisión en los pull requests.

Capa 2 — Redacción en la librería de logging. Como el redact de pino del apartado 9: una red de seguridad para los descuidos.

Capa 3 — Enmascarado en el recolector. La última defensa técnica antes de que el dato se persista.

Ese campo _enmascarado es más valioso de lo que parece. Con una consulta en Kibana:

y agregando por componente, obtienes la lista de componentes que están escribiendo datos personales y que hay que corregir en el código. Convierte una medida defensiva en una herramienta de mejora.

Advertencia honesta sobre las expresiones regulares: no son fiables. Un DNI escrito como 12.345.678-Z no lo detecta el patrón anterior. Un nombre y apellidos no tiene ningún patrón detectable. La única defensa real es la capa 1.

Capa 4 — Control de acceso y retención. Aunque no haya fugas, restringe quién puede ver los logs de producción, con índices separados por entorno (como hicimos en el agregador) y roles de Elasticsearch que solo den acceso a lo necesario.

La retención de 30 días del apartado 7 es una decisión que combina tres criterios:

Y una regla que a menudo sorprende: si los logs contienen datos personales, conservarlos "por si acaso" no es aceptable. La normativa de protección de datos exige que los datos personales se conserven solo el tiempo necesario para la finalidad que justificó su recogida, y "por si algún día hace falta depurar" no suele ser una finalidad válida.

Este es un punto que no puede resolverse solo con criterio técnico.

La configuración de esta lección —qué se registra, cuánto tiempo se conserva, quién puede consultarlo y desde dónde— debe ser revisada y aprobada por el responsable de cumplimiento normativo y protección de datos de la organización antes de ponerse en producción.

Rutas Norte trata datos personales de sus clientes (nombre, DNI, teléfono y correo electrónico), lo que sitúa a la plataforma dentro del ámbito de aplicación del RGPD y de la normativa nacional de protección de datos. Un sistema de registro centralizado que capture, aunque sea accidentalmente, esos datos, tiene consecuencias concretas:

• Pasa a ser un tratamiento de datos personales que debe figurar en el registro de actividades de tratamiento, con su base legal y su finalidad documentadas.
• Exige un plazo de conservación justificado y aplicado técnicamente, no una retención indefinida "por si acaso".
• Obliga a controlar y registrar los accesos: quién consulta los logs de producción y con qué finalidad.
• Puede requerir una evaluación de impacto si el volumen o la naturaleza del tratamiento lo justifican.
• Complica notablemente el ejercicio de los derechos de supresión y de acceso: si el DNI de un cliente aparece en veinte índices distribuidos, atender una solicitud de supresión se vuelve técnicamente muy costoso.
• Si Elasticsearch está alojado fuera del Espacio Económico Europeo, activa las obligaciones sobre transferencias internacionales de datos.

Qué hacer, en la práctica:

1. Documentar por escrito qué campos se registran de cada componente y presentarlo a la persona responsable de cumplimiento.
2. Acordar con ella el plazo de retención de cada índice, y aplicarlo en la política ILM.
3. Definir quién tiene acceso a los índices de producción, y revisarlo periódicamente.
4. Auditar con la consulta _enmascarado: true qué componentes siguen emitiendo datos sensibles y corregirlos en el código.
5. Incluir la revisión de logs en la lista de comprobación de cualquier funcionalidad nueva que trate datos de clientes.

El equipo técnico proporciona los mecanismos —enmascarado, retención, control de acceso, separación por entornos—, pero la decisión sobre qué es aceptable registrar y durante cuánto tiempo no es una decisión técnica.

Recapitulando el apartado 7, la pila EFK mínima para Rutas Norte:

Más el coste humano: alguien tiene que mantener Elasticsearch, dimensionar los fragmentos, vigilar el estado del clúster, gestionar las actualizaciones y responder cuando se pone en rojo. Elasticsearch no es un componente que se instale y se olvide.

Para una plataforma con seis componentes y tres nodos, es un coste considerable. Merece la pena preguntarse si hay algo más ligero.

Loki es el sistema de logs de Grafana Labs, con una idea de diseño radicalmente distinta:

Loki no indexa el contenido de los logs. Solo indexa las etiquetas.

Es "Prometheus para logs": el mismo modelo de etiquetas, el mismo lenguaje de consulta (LogQL, muy parecido a PromQL) y almacenamiento en objetos baratos (S3) en lugar de discos rápidos.

Cuándo elegir cada uno:

Recomendación honesta para Rutas Norte: con seis componentes, tres nodos y un equipo pequeño, Loki sería la elección más sensata. Hemos montado EFK porque es lo que encontrarás en la mayoría de empresas establecidas y porque enseña los conceptos (índices, plantillas, ILM, mapeos) que después se aplican en cualquier sistema. Pero si mañana empezaras de cero, empieza por Loki.

La tercera vía es no operar nada:

Ventaja: cero operación. Inconvenientes: coste por GB ingerido que se dispara con el volumen, y —importante para el apartado 11— los datos salen de tu infraestructura, lo que hay que revisar con el responsable de cumplimiento normativo, especialmente si el proveedor almacena fuera del EEE.

Antes de dimensionar nada, reduce el volumen. Es gratis y siempre funciona:

Medidas complementarias:

• Nivel info en producción, debug solo en rutas-norte-dev.
• access_log off; para el endpoint de salud de nginx, como ya hicimos en 07-01.
• Retención más corta para dev y pre (7 días) que para pro (30 días).
• Revisar periódicamente qué componente genera más volumen:

1. La aplicación escribe a fichero en vez de a stdout. Rompe el contrato de Kubernetes: el recolector no lo ve, el fichero crece dentro del contenedor y desaparece al reiniciarse. Si no puedes cambiar la aplicación, usa un sidecar adaptador como el de worker-notificaciones.

2. No configurar el reensamblado multilínea. Cada traza de excepción se convierte en veinte documentos inconexos, justo lo que más falta hace leer entero durante un incidente.

3. El recolector lee sus propios logs. Bucle infinito: cada log generado produce otro log. El Exclude_Path del apartado 6 no es opcional.

4. Elasticsearch con un solo nodo. Sin quórum, sin tolerancia a fallos, y la pila de logs entera cae cuando ese pod se reinicia. Tres nodos es el mínimo real.

5. Heap de Elasticsearch mal dimensionado. Máximo el 50 % de la memoria del contenedor, y nunca más de 31 GB. Por encima de ese umbral la JVM pierde la compresión de punteros y rinde peor con más memoria.

6. Sin política ILM. Los índices se acumulan hasta llenar el disco. Cuando eso pasa, Elasticsearch pasa a solo lectura y dejas de recibir logs justo cuando más falta hacen.

7. Mapear como text lo que debería ser keyword. Sin keyword no puedes agregar por ese campo, y las agregaciones son la mitad del valor de Kibana.

8. Registrar datos personales. El error con más consecuencias fuera de lo técnico. Aplica las cuatro capas de defensa y, sobre todo, no lo escribas en el código.

9. No definir un estándar de campos. Si cada componente usa level, severity y nivel para lo mismo, no hay ninguna consulta que funcione para todos. Acuerda el estándar antes de instrumentar.

10. No propagar el traza_id. Sin él, correlacionar una petición entre seis componentes es imposible por mucha pila de logs que tengas.

11. Sin buffer en el recolector. Si Elasticsearch se cae diez minutos y no hay buffer, se pierden diez minutos de logs de producción, probablemente los más interesantes.

12. No monitorizar la pila de logs. El recolector puede estar descartando registros en silencio. Usa el PodMonitor y la alerta del apartado 6: aplica lo aprendido en 07-03 y 07-04 a la propia infraestructura de observabilidad.

13. Registrar demasiado. El nivel debug en producción multiplica por diez el volumen y el coste, y hace más difícil encontrar lo importante entre el ruido.

tienda-web (nginx) genera logs de acceso en formato combinado:

1. Enumera todos los problemas de esta línea, incluidos los de protección de datos.
2. Escribe la configuración de nginx que emita el mismo evento en JSON, conforme al estándar de campos de Rutas Norte.
3. Escribe el parser de Fluent Bit necesario si no pudieras cambiar la configuración de nginx.
4. ¿Qué harías con el parámetro dni de la URL?

Una auditoría interna revela que el índice rutasnorte-pro-2026.08.* contiene 47 000 documentos con direcciones de correo de clientes en texto claro. Los logs provienen de worker-notificaciones y de api-reservas.

1. Escribe la consulta KQL que localiza los documentos afectados.
2. Enumera, por orden de prioridad, las acciones a tomar en las próximas 24 horas.
3. Escribe el filtro de enmascarado que evita que vuelva a ocurrir, y explica por qué no es suficiente.
4. ¿Qué papel tiene el responsable de cumplimiento normativo en este incidente y en qué momento hay que involucrarlo?

Rutas Norte se expande: pasa de 3 a 12 nodos, de 6 a 15 componentes, y el volumen de logs se multiplica por 5 respecto a la estimación del apartado 7. El presupuesto de infraestructura no se multiplica por 5.

1. Recalcula el volumen diario y el almacenamiento necesario para 30 días.
2. Propón tres medidas para reducir el volumen sin perder capacidad de diagnóstico, con una estimación del ahorro de cada una.
3. Compara EFK y Loki para este escenario concreto, con números.
4. Recomienda una arquitectura final y justifícala.

Solución 1

1. Problemas de la línea.

De formato:

• No es JSON: cada campo hay que extraerlo con expresiones regulares, frágiles ante cualquier cambio.
• La fecha usa formato nginx (06/Aug/2026:03:14:22 +0000), no ISO 8601: requiere un parser específico.
• La duración 4.821 está en segundos, no en milisegundos, e incumple el estándar de Rutas Norte (duracion_ms).
• No hay traza_id: imposible correlacionar esta petición con la de api-reservas.
• No hay componente ni nivel: no se puede filtrar por severidad.

De protección de datos (los graves):

• La URL contiene un DNI: ?dni=12345678Z. Queda registrado en el log de nginx, en el del Ingress y en cualquier proxy intermedio. Este es el problema más grave.
• La IP del cliente (83.45.12.99) es un dato personal según el RGPD. Debe tratarse como tal: anonimizarla o justificar su conservación.
• El User-Agent contribuye a la huella digital del navegador y, combinado con otros datos, puede ser identificativo.

2. Configuración de nginx en JSON.

Puntos clave de esta configuración:

• $uri en vez de $request: $uri es la ruta sin la cadena de consulta, así que el ?dni=... nunca llega al log. Es la solución al problema más grave.
• escape=json es obligatorio: sin él, un User-Agent con comillas rompe el JSON y Fluent Bit no puede parsearlo.
• access_log off en la sonda de salud, coherente con lo que hicimos en 07-01.

3. Parser si no se puede cambiar nginx.

Y un filtro Lua que normalice al estándar y limpie la cadena de consulta:

4. Qué hacer con el dni de la URL.

La respuesta correcta tiene tres niveles, y solo el primero resuelve el problema de raíz:

Nivel 1 (la solución real): cambiar la aplicación. Un DNI no debe viajar nunca en la cadena de consulta de una URL. Las URLs quedan registradas en el navegador, en el historial, en el Referer que se envía a terceros, en los logs de nginx, del Ingress y de cualquier proxy. La consulta debe ser POST con el dato en el cuerpo, o usar un identificador opaco.

Nivel 2 (mitigación inmediata): no registrar la cadena de consulta. Usar $uri en lugar de $request, como en la solución 2. Se implementa en minutos y corta la fuga hacia los logs.

Nivel 3 (red de seguridad): enmascarar en el recolector. El filtro Lua del apartado 11 detecta el patrón de DNI y lo sustituye. Es la última defensa, y no es fiable por sí sola: un DNI escrito como 12.345.678-Z se le escapa.

Aplicar los tres. Y muy importante: los logs que ya contienen el DNI siguen ahí. Hay que borrarlos, y eso nos lleva al ejercicio siguiente.

Solución 2

1. Consulta KQL para localizar los documentos.

Más precisa, aprovechando el marcador del enmascarado:

Y para cuantificar y localizar el origen, una agregación en Elasticsearch:

Esa agregación te da exactamente qué componente, cuántos documentos y desde qué día: los tres datos que necesitas para el informe.

2. Acciones en 24 horas, por prioridad.

Hora 0-1 — Contener y notificar.

1. Notificar al responsable de cumplimiento normativo inmediatamente. No es una decisión técnica que se pueda diferir: los plazos de notificación de brechas son cortos y el reloj empieza a correr desde que se tiene conocimiento.
2. Restringir el acceso a los índices afectados solo al equipo que gestiona el incidente, mediante roles de Elasticsearch.
3. Documentar el alcance: qué componentes, qué campos, cuántos documentos, desde qué fecha, quién ha accedido a esos índices (los logs de auditoría de Elasticsearch).

Hora 1-4 — Cortar la fuga.

4. Desplegar el filtro de enmascarado en Fluent Bit (punto 3) para que dejen de entrar documentos nuevos. Es rápido y no requiere tocar las aplicaciones.
5. Verificar que los documentos nuevos ya llegan enmascarados, comprobando el índice del día.

Hora 4-12 — Corregir el origen.

6. Localizar en el código las llamadas al logger que emiten el correo. En worker-notificaciones está en el log SMTP heredado; en api-reservas, probablemente en un log.info(reserva) que vuelca el objeto entero.
7. Corregir el código: sustituir la dirección por un hash, como hace el adaptador del apartado 9.
8. Añadir redact en la configuración del logger como red de seguridad de capa 2.
9. Desplegar a pre y luego a pro.

Hora 12-24 — Sanear y prevenir.

10. Eliminar o depurar los documentos afectados, según lo que decida el responsable de cumplimiento:

Advertencia: _delete_by_query sobre 47 000 documentos es una operación pesada. Si los índices son diarios y están muy contaminados, borrar el índice entero es mucho más rápido y más seguro, al coste de perder también los logs limpios de ese día.

11. Añadir una comprobación automática en la integración continua que rechace un pull request si detecta patrones de datos personales en llamadas al logger.
12. Escribir un informe para el responsable de cumplimiento con cronología, alcance, causa raíz y medidas.

3. El filtro de enmascarado y por qué no basta.

Por qué no es suficiente, en cuatro razones:

1. Las expresiones regulares se escapan. marta.ruiz [arroba] ejemplo.example, un correo partido entre dos campos, o uno con caracteres poco habituales no coinciden con el patrón. El enmascarado da una falsa sensación de seguridad.
2. Solo cubre lo que ya sabes buscar. Un nombre y apellidos no tiene patrón detectable. Una dirección postal tampoco. El filtro protege contra correos, DNIs y tarjetas; contra el resto, nada.
3. El dato existe hasta el filtro. Sale del proceso, se escribe en el fichero del nodo, viaja hasta el recolector. Cualquiera con acceso al nodo (o al pod del recolector, que monta hostPath) lo ve sin enmascarar.
4. Es una capa de mitigación, no de prevención. La única defensa real es que el dato no se escriba nunca. Todo lo demás son redes que atrapan lo que se escapa.

Por eso el paso 7 (corregir el código) es el importante, y el filtro solo compra tiempo mientras se despliega.

4. El papel del responsable de cumplimiento normativo.

Cuándo involucrarlo: en la primera hora, antes de tomar ninguna acción de saneamiento. Es un error frecuente "arreglarlo primero y avisar después": borrar los documentos antes de que él documente el alcance puede destruir la evidencia que necesita para evaluar la brecha, y los plazos de notificación corren desde que se tiene conocimiento del hecho, no desde que se termina de arreglar.

Sus responsabilidades en este incidente:

• Calificar el incidente: determinar si constituye una violación de seguridad de datos personales según el RGPD.
• Decidir sobre la notificación: si procede notificar a la autoridad de control (en España, la AEPD) en el plazo legal de 72 horas, y si procede comunicarlo a los afectados.
• Evaluar el riesgo para los derechos y libertades de las personas afectadas, teniendo en cuenta el volumen, la naturaleza del dato y quién ha podido acceder.
• Decidir el saneamiento: qué se borra, qué se conserva como evidencia y durante cuánto tiempo.
• Registrar el incidente en el registro interno de violaciones de seguridad, obligatorio incluso cuando no procede notificar.
• Aprobar las medidas correctoras y verificar que se han implantado.

Y hacia adelante, su papel es preventivo: revisar y aprobar qué campos se registran, los plazos de retención y la política de acceso, tal como establece la advertencia del apartado 11. El equipo técnico proporciona los mecanismos; la decisión sobre qué es aceptable registrar no es técnica.

Solución 3

1. Recálculo del volumen.

Un incremento de aproximadamente tres veces el coste original, además de un salto cualitativo en complejidad operativa: con 5 nodos de datos hay que gestionar fragmentos, reequilibrado y actualizaciones continuas.

2. Tres medidas de reducción.

Medida A — Muestreo de logs de éxito. Ahorro estimado: 45 %.

El 90 % de los logs son peticiones que fueron bien y que nadie mirará jamás. Conservar el 10 % de ellas es estadísticamente suficiente para ver tendencias, y el 100 % de los errores.

El campo _muestreado permite multiplicar por 10 los recuentos al hacer agregaciones y obtener cifras correctas.

Medida B — Retención escalonada por entorno y por nivel. Ahorro estimado: 30 %.

Se implementa con dos flujos de datos distintos, enrutados en el agregador Fluentd por el campo nivel, cada uno con su política ILM.

Medida C — Descartar ruido en el origen. Ahorro estimado: 20 %.

Efecto combinado (las medidas no son puramente aditivas porque se solapan):

Y lo importante: sin perder capacidad de diagnóstico, porque se conserva el 100 % de los errores, el 100 % de lo lento y el 100 % de lo que toca reservas.

3. Comparación EFK frente a Loki con números.

Sobre el volumen ya optimizado de 15,8 GB/día:

El dato decisivo está en la comparación de las dos filas de búsqueda: Loki es lento en búsquedas de texto libre sobre todo el histórico, pero igual de rápido en el caso que representa el 95 % del uso real, que es "logs de este componente, en esta ventana de tiempo, filtrando por nivel". Y eso es exactamente cómo se investiga un incidente: nunca buscas una cadena en 30 días de todos los componentes; siempre acotas por componente y por ventana, porque la alerta ya te dio ambos.

4. Arquitectura recomendada.

Recomendación: migrar a Loki, con las tres medidas de reducción aplicadas.

Justificación, en cinco puntos:

1. Coste: 190 € frente a 750 € al mes. La diferencia (6 700 € al año) es difícil de justificar cuando el caso de uso predominante rinde igual en ambos.
2. Complejidad operativa. Elasticsearch con 5 nodos de datos requiere alguien que sepa gestionar fragmentos, reequilibrados y actualizaciones. Loki, mucho menos. Con un equipo pequeño, ese tiempo vale más que la diferencia de coste.
3. Integración con lo que ya tenemos. Grafana ya está desplegada desde 07-04. Loki aparece como una fuente de datos más, y el mismo cuadro de mando puede tener un panel de métricas encima y uno de logs debajo, con la misma ventana temporal. Ese salto de contexto ahorrado en un incidente vale mucho.
4. El modelo de etiquetas es el que ya conocemos. LogQL es tan parecido a PromQL que el equipo lo aprende en una tarde, mientras que KQL y las agregaciones de Elasticsearch son un cuerpo de conocimiento aparte.
5. Se conserva la arquitectura de recolección. Fluent Bit sigue siendo el agente por nodo, con la misma configuración de parseo, multilínea y enmascarado. La migración solo cambia el destino de la salida, lo cual la hace de bajo riesgo.

Cuándo NO seguir esta recomendación:

• Si el equipo ya opera Elasticsearch para otras cosas (buscador de la web, análisis), el coste marginal de añadir logs es mucho menor.
• Si hay requisitos de auditoría que exigen búsqueda de texto libre en todo el histórico con tiempos de respuesta garantizados.
• Si se necesitan agregaciones complejas sobre campos de log de forma habitual.

Plan de migración de bajo riesgo:

1. Desplegar Loki en paralelo, sin tocar EFK.
2. Configurar Fluent Bit con dos salidas simultáneas durante dos semanas.
3. Reconstruir en Grafana los cuadros de mando de errores que estaban en Kibana.
4. Validar con un incidente real que Loki responde a las preguntas necesarias.
5. Retirar EFK, conservando una copia de los índices de producción hasta agotar la retención acordada con el responsable de cumplimiento normativo.

Ese último punto no es un detalle: no se puede borrar EFK antes de tiempo si su retención está comprometida con cumplimiento.

Rutas Norte ya no pierde su historia. En esta lección hemos:

• Entendido por qué kubectl logs no basta: se pierde al recrear el pod, no busca entre componentes, no correlaciona y desaparece con el nodo. Y hemos visto un límite adicional poco conocido: con la rotación por defecto del kubelet, un componente verboso conserva menos de seis horas de logs en el nodo.
• Visto cómo funciona el registro por debajo: la aplicación escribe a stdout, el runtime lo guarda en /var/log/containers/ con un nombre parlante del que se extraen pod, namespace y contenedor, y el kubelet lo rota.
• Dominado kubectl logs como herramienta de primera línea, con --previous como el flag decisivo ante un CrashLoopBackOff.
• Montado la arquitectura de recolección por nodo sobre el DaemonSet que desplegamos en 06-02: Fluent Bit como agente ligero en cada nodo y Fluentd como agregador central, con el filtro kubernetes que enriquece cada línea y el reensamblado multilínea que evita que una excepción se convierta en veinte documentos inconexos.
• Configurado Elasticsearch con índices por día, plantillas que distinguen keyword de text, y una política ILM con fases caliente, templada, fría y borrado; y hemos dimensionado la pila con números realistas: unos 24 GB de RAM y 300 GB de disco solo para poder leer logs.
• Usado Kibana con KQL para pasar de una alerta a la causa raíz en cinco minutos, siguiendo un flujo de trabajo concreto: acotar, ver la forma, identificar el componente, encontrar el mensaje dominante, leer la traza y correlacionar hacia atrás.
• Adoptado los logs estructurados en JSON como la decisión de mayor rentabilidad, con el estándar de campos de Rutas Norte y el traza_id que permite seguir una petición por los seis componentes; y hemos cerrado el círculo del adaptador de logs de worker-notificaciones que introdujimos en 06-04.
• Y, sobre todo, hemos establecido qué no debe registrarse nunca: credenciales, datos de pago y datos personales de los clientes. Con cuatro capas de defensa —el código, la librería, el recolector y el control de acceso— sabiendo que solo la primera es realmente fiable, y con la advertencia expresa de que la configuración de registro debe ser revisada y aprobada por el responsable de cumplimiento normativo antes de llegar a producción.
• Comparado el coste real de EFK con las alternativas más ligeras, con la conclusión honesta de que para una plataforma del tamaño de Rutas Norte, Loki sería hoy la elección más sensata.

Ya tenemos las tres señales: las sondas dicen si un componente está sano, las métricas dicen cuánto y cómo funciona, y los logs dicen exactamente qué pasó. Lo que aún no tenemos es un método para usarlas juntas.

Porque cuando a las 03:14 la tienda web devuelve 502 y suena el teléfono, saber usar Grafana y Kibana no basta: hace falta un procedimiento que vaya del síntoma a la causa sin dar vueltas, saber que los eventos de Kubernetes caducan en una hora y hay que capturarlos antes, y conocer una tabla mental de síntoma → causa probable → comando que lo confirma. En 07-06, la última lección del módulo, construiremos esa metodología y la aplicaremos, paso a paso, a un incidente real de Rutas Norte.