¿Cómo funciona de extremo a extremo una arquitectura de agregación de logs como ELK o Grafana Loki?
Sigue el recorrido de una línea de log desde el stdout de un contenedor hasta un dashboard consultable, y entiende por qué cada etapa —envío, buffer, parseo, indexado— se gana su lugar en el pipeline.
APRENDE HACIENDOPon a prueba tu intuición3 pasos
¿Cómo funciona de extremo a extremo una arquitectura de agregación de logs como ELK o Grafana Loki?
Usa los ejemplos y la explicación de la lección para comprobar tu idea.
Reflexión personal. No se envía a ningún servicio de IA.#Por qué los logs ya no pueden vivir solo en la máquina
En un sistema distribuido, una sola petición de usuario puede pasar por seis servicios corriendo en contenedores que se reprograman, reinician o destruyen en minutos. Si cada servicio solo escribe logs en su propio disco local, depurar se convierte en arqueología: hay que averiguar en qué nodo cayó el contenedor, esperar que todavía no lo hayan desalojado, y entrar con exec antes de que la evidencia desaparezca. La agregación centralizada de logs resuelve esto enviando cada línea fuera del host en tiempo real, de modo que los logs de toda la flota quedan buscables desde un solo lugar, correlacionados por ID de petición, nombre de servicio o trace ID.
Esta es una de las preguntas de entrevista más comunes en roles de backend y plataforma, porque evalúa si entiendes por qué existe cada etapa de un pipeline de logging — no solo que "Kibana muestra logs".
#Las cinco etapas que comparte toda arquitectura
Ya sea que uses el clásico stack ELK (Elasticsearch, Logstash, Kibana) o el más moderno stack de Grafana Loki (Promtail o Fluent Bit, Loki, Grafana), el pipeline se descompone en las mismas cinco etapas conceptuales:
- Recolección. Un agente ligero corre en cada host — normalmente como un DaemonSet de Kubernetes, uno por nodo — y sigue el stdout/stderr de los contenedores o archivos de log en disco. Agentes comunes: Filebeat, Fluentd, Fluent Bit, Promtail. El agente enriquece cada línea con metadatos que la aplicación nunca tuvo que pensar: nombre del pod, namespace, ID del contenedor, nombre del nodo, labels.
- Transporte / buffer. Los logs enviados caen en un buffer — a menudo Kafka, a veces Redis — antes de llegar al nivel de procesamiento. Esto absorbe picos de tráfico y protege el pipeline: si Elasticsearch o Loki se caen por mantenimiento, los logs se encolan en Kafka en lugar de perderse o saturar la propia aplicación.
- Procesamiento. Aquí es donde las dos arquitecturas más divergen (ver abajo). Logstash aplica patrones grok y filtros para convertir texto no estructurado en campos estructurados. Loki, en cambio, extrae solo un pequeño conjunto de labels y deja el cuerpo de la línea de log intacto.
- Almacenamiento e indexado. Los datos procesados caen en un almacén diseñado para el propósito: el índice invertido de Elasticsearch para ELK, o el almacén de chunks de Loki (normalmente respaldado por S3/GCS) más un índice de labels liviano.
- Consulta y visualización. Kibana o Grafana permiten filtrar por campo/label, ejecutar consultas de texto completo o LogQL/DSL, construir dashboards y — algo crítico — saltar de un pico en una métrica directamente a los logs que lo explican.
#ELK vs. Loki: dos apuestas fundamentalmente distintas
La parte más interesante de esta pregunta es explicar por qué existe Loki si Elasticsearch ya hace búsqueda de texto completo en logs. La respuesta es el costo y el peso operativo a escala.
| Dimensión | ELK (Elasticsearch) | Grafana Loki |
|---|---|---|
| Qué se indexa | Todos los campos de cada línea de log (índice invertido completo) | Solo un pequeño conjunto de labels (servicio, entorno, pod) |
| Almacenamiento del cuerpo del log | Indexado y almacenado en Elasticsearch | Comprimido en chunks, normalmente en almacenamiento de objetos (S3/GCS) |
| Poder de consulta | Búsqueda rica de texto completo en cualquier campo | Filtrar por label primero, luego grep/regex sobre los chunks encontrados (LogQL) |
| Costo de recursos a escala | Alto — CPU y disco crecen con cada campo indexado | Mucho más bajo — el overhead de indexado se mantiene plano sin importar el volumen |
| Mejor uso | Investigación ad hoc sobre campos no estructurados e impredecibles | Sistemas de alto volumen que ya usan Prometheus/Grafana, sensibles al costo |
La filosofía de diseño de Loki es explícitamente "indexa como Prometheus, almacena como S3": sacrifica deliberadamente algo de flexibilidad de consulta para mantener el índice diminuto, lo cual es justo lo que le permite escalar a terabytes de logs por día sin una factura de clúster del tamaño de Elasticsearch.
#Patrones de recolección en Kubernetes
Dominan dos patrones. Un DaemonSet corre un agente de logs por nodo y lee el stdout/stderr de todos los contenedores desde el directorio de logs del runtime del nodo — este es el enfoque por defecto y más eficiente en recursos para el caso común. Un sidecar corre un agente por pod, útil cuando una aplicación escribe a un archivo en lugar de stdout, o necesita parseo específico antes de que algo salga del pod. Los sidecars cuestan más (un contenedor extra por pod), así que son la excepción, no la regla.
#Retención, niveles de almacenamiento y por qué importa el logging estructurado
Nadie mantiene cada línea de log "caliente" para siempre — es demasiado costoso. El Index Lifecycle Management (ILM) de Elasticsearch hace rotar los índices por niveles hot (SSD rápido, escritura activa), warm (más barato, solo lectura) y cold/frozen, hasta finalmente borrarlos o archivarlos. Loki aplica retención por stream de logs directamente sobre sus chunks respaldados en almacenamiento de objetos, lo cual es naturalmente más barato porque los datos fríos ya están en almacenamiento tipo S3.
La decisión de mayor impacto que un equipo toma aquí ocurre incluso antes de esta infraestructura: si la aplicación emite logs JSON estructurados en lugar de texto libre. Una línea de log en JSON con campos explícitos de timestamp, level, service, trace_id y message no necesita ninguna etapa frágil de parseo con grok/regex — la etapa de procesamiento se convierte en un mapeo directo de campos. Los logs de texto libre obligan a Logstash (o a una etapa del pipeline de Loki) a adivinar los límites de los campos con expresiones regulares que se rompen en cuanto alguien cambia la redacción de un mensaje de log.
#Qué significa esto en una entrevista
Si te hacen esta pregunta, no te limites a nombrar herramientas — narra el pipeline: agente de recolección, buffer, procesamiento/parseo, índice/almacenamiento, capa de consulta, y explica el trade-off entre ELK y Loki en términos de qué se indexa, porque esa única decisión de diseño explica casi toda la diferencia posterior en costo, poder de consulta y complejidad operativa.