Por qué los ingenieros dejan ELK por stacks propios
El stack que dominó la gestión de logs durante una década
Durante años, el stack ELK fue la respuesta por defecto a una pregunta recurrente: ¿cómo gestionar los registros de logs?
Elasticsearch se encargaba de la indexación, Logstash procesaba los datos entrantes y Kibana lo visualizaba todo en paneles. Juntos conformaron una de las plataformas de observabilidad más extendidas en la infraestructura moderna.
Sin embargo, algo está cambiando. En multitud de equipos de ingeniería, los desarrolladores están probando alternativas articuladas en torno a OpenTelemetry, OpenSearch y sistemas especializados de trazas distribuidas. Buscan canalizaciones de observabilidad que escalen mejor y cuesten menos, y sustituir ELK es solo una parte de esa transición.
Un ingeniero explicaba cómo opera un sistema de estas características en producción ingiriendo casi mil millones de registros y trazas al día, asegurando que el coste global de infraestructura se mantiene sorprendentemente bajo. Esa afirmación basta para entender el interés generado, sobre todo cuando la factura de la observabilidad se ha convertido en un quebradero de cabeza para muchas empresas.
Por qué ELK se convirtió en un problema para muchos equipos
El stack ELK original era potente, pero no fue concebido para la escala de los sistemas distribuidos actuales, y los microservicios transformaron el panorama por completo.
En lugar de un puñado de aplicaciones emitiendo logs, las compañías ejecutan hoy cientos de servicios que generan registros, trazas, métricas y eventos de forma simultánea. Las canalizaciones de observabilidad tienen que absorber de golpe volúmenes masivos de telemetría.
En esos entornos, mantener despliegues de ELK suele resultar caro y pesado desde el punto de vista operativo. Los clústeres de Elasticsearch crecen rápidamente, los pipelines de Logstash se complican y los costes de almacenamiento se disparan con el crecimiento de la telemetría.
Muchos ingenieros terminan llegando a la misma conclusión: ELK funciona, pero su mantenimiento puede transformarse en un proyecto de infraestructura a tiempo completo. Por esa razón distintos equipos empezaron a probar arquitecturas diferentes.
El stack alternativo que no deja de ganar adeptos
Una arquitectura de reemplazo cada vez más habitual combina tres piezas principales: OpenTelemetry para la recolección de telemetría, OpenSearch para el almacenamiento y la indexación, y Jaeger para el trazado distribuido.
OpenTelemetry actúa como la canalización central. Las aplicaciones envían métricas, logs y trazas a través del colector de OpenTelemetry, y desde allí el colector enruta la información a sistemas de almacenamiento como OpenSearch. Los datos de trazas viajan hacia Jaeger, especializado en visualizar las rutas de las peticiones a través de sistemas distribuidos.
Esto cambia la operativa de la observabilidad. En lugar de depender de Logstash como capa de procesamiento intermedia, los colectores de OpenTelemetry asumen la ingesta y el enrutamiento de forma directa, lo que simplifica la arquitectura notablemente.
Por qué OpenTelemetry cambió las reglas del juego
OpenTelemetry es una de las razones principales por las que los nuevos stacks de observabilidad se diferencian tanto de los tradicionales. En vez de recurrir a agentes de logs independientes, recolectores de métricas separados y librerías de trazas específicas, OpenTelemetry ofrece un marco de instrumentación unificado.
Las aplicaciones emiten telemetría con un formato uniforme, y los colectores procesan esas señales y las reenvían a diferentes destinos. En la práctica, esto implica que un único sistema puede gestionar logs, métricas y trazas.
Un ingeniero destacaba que los colectores de OpenTelemetry son lo bastante ligeros como para funcionar en modo agente, reenviando logs y telemetría allí donde hagan falta. Esa flexibilidad facilita el diseño de canalizaciones de observabilidad a medida sin atarse a herramientas pesadas de ingesta.
El debate en torno a OpenSearch
OpenSearch aparece a menudo en estos stacks alternativos porque ofrece un motor de búsqueda de código abierto similar a Elasticsearch. Con todo, la relación entre ambas tecnologías sigue siendo objeto de discusión.
Hay ingenieros que sostienen que OpenSearch ofrece un rendimiento excelente con cargas de trabajo de observabilidad, incluso procesando volúmenes enormes de telemetría. Otros insisten en que Elasticsearch sigue siendo más rápido y capaz a la luz de bancos de pruebas independientes.
Muchos analistas recuerdan que procesar miles de millones de trazas no demuestra por sí solo la superioridad de OpenSearch. El rendimiento depende en gran medida de la configuración del clúster, los patrones de consulta y las estrategias de indexación.
El debate sigue abierto, y precisamente por eso los ingenieros continúan experimentando con diferentes combinaciones.
El problema del coste oculto
El motivo que empuja a muchos equipos a buscar alternativas a ELK no siempre responde al rendimiento: a menudo es una cuestión económica. Los datos de observabilidad crecen a gran velocidad. Cada petición, entrada de log y traza genera telemetría, y al escalar los sistemas, los costes de almacenamiento pueden multiplicarse.
Algunos ingenieros afirman que han logrado ingerir volúmenes ingentes de telemetría con OpenSearch a un coste moderado, especialmente cuando gestionan clústeres autogestionados en lugar de servicios en la nube totalmente administrados.
Conviene hacer una advertencia importante: el mismo profesional que elogiaba OpenSearch desaconsejaba recurrir al servicio gestionado de OpenSearch en AWS, calificándolo de muy costoso. La diferencia de precio entre gestionar tu propio stack y contratar servicios administrados puede alterar el presupuesto de forma drástica.
Las otras herramientas que entran en escena
Los stacks de observabilidad rara vez se quedan en su diseño más simple, y conforme los equipos prueban opciones, entran nuevas herramientas en la cadena.
Un ingeniero explicaba que utiliza Vector, un procesador de logs ligero escrito en Rust, como reemplazo de herramientas como Filebeat o Logstash. En su entorno, Vector asumió la normalización de logs de unas 250 aplicaciones manteniendo un consumo de recursos muy bajo y una alta velocidad de proceso.
Otros profesionales señalaban sistemas de trazas basados en VictoriaMetrics o diferentes backends de almacenamiento de telemetría.
Toda esta experimentación demuestra la rapidez con la que evoluciona el ecosistema. Los equipos ya no se sienten atados a plataformas monolíticas y prefieren ensamblar canalizaciones combinando componentes especializados.
Las reticencias de la comunidad
Siempre que alguien propone sustituir herramientas consolidadas de observabilidad, las objeciones no tardan en aparecer.
En el caso del stack alternativo basado en OpenSearch, varios ingenieros cuestionaron algunas afirmaciones. Argumentaban que Elastic sigue siendo uno de los mayores contribuidores al ecosistema de OpenTelemetry y que proporciona una integración nativa muy sólida con las canalizaciones de telemetría OTLP. Otros recordaban que las pruebas comparativas independientes sitúan a menudo a Elasticsearch por delante de OpenSearch en determinadas cargas de trabajo.
Estas discrepancias demuestran que la observabilidad no es un asunto zanjado. Hay múltiples formas de construir canalizaciones de telemetría, y cada enfoque conlleva sus propios compromisos técnicos.
Una transformación más profunda
Más allá de los debates sobre productos concretos, se está produciendo un cambio de mayor calado en los equipos de ingeniería: la observabilidad se está volviendo modular.
En lugar de desplegar una única plataforma monolítica, los equipos construyen canalizaciones a partir de piezas especializadas. OpenTelemetry se ocupa de la instrumentación, los colectores enrutan las señales y distintos motores de almacenamiento gestionan logs, métricas y trazas.
Esta arquitectura otorga a los equipos mayor control sobre los costes y la escalabilidad, pero también demanda un conocimiento técnico más profundo. En cuanto abandonas los stacks cerrados, la responsabilidad de diseñar y mantener la canalización recae sobre ti.
El futuro de los stacks de observabilidad
El auge de OpenTelemetry indica que las plataformas de observabilidad del futuro serán muy diferentes a las del pasado.
Los estándares de instrumentación están separando la recolección de datos de los sistemas de almacenamiento. Los logs, las métricas y las trazas se están convirtiendo en señales portables en lugar de formatos cerrados de un proveedor concreto, y los equipos de infraestructura prefieren combinar herramientas antes que comprometerse con un único ecosistema.
Esa evolución puede transformar con el tiempo todo el mercado de la observabilidad. Cuando las canalizaciones de telemetría pasan a ser modulares, la duda deja de ser qué plataforma cerrada elegir y pasa a ser cómo diseñar la canalización que mejor se adapte a tus necesidades.