El problema fundamental que aborda este benchmark es la gestión eficiente y escalable de datos de logs semiestructurados, como los generados por entornos de Kubernetes, en sistemas de observabilidad. La variabilidad inherente en los esquemas de logs de Kubernetes, donde un mismo campo puede tener tipos de datos inconsistentes a lo largo del tiempo o entre diferentes fuentes, representa un desafío significativo para los sistemas de indexación tradicionales con esquemas rígidos.
Históricamente, soluciones como Elasticsearch, basadas en una arquitectura de búsqueda de texto completo con indexación invertida y un modelo de datos orientado a documentos (row-oriented), han sido la opción predominante. Sin embargo, su dependencia de esquemas predefinidos y la necesidad de gestionar mappings explícitamente se convierten en un cuello de botella operacional y de rendimiento a medida que el volumen y la heterogeneidad de los datos aumentan. Este análisis busca validar si arquitecturas alternativas, como las que emplean almacenamiento columnar y manejo automático de esquemas, pueden ofrecer una solución más robusta y eficiente para este tipo de cargas de trabajo a escala de terabytes.
Arquitectura del Sistema
El benchmark compara dos arquitecturas de sistemas de observabilidad: Elasticsearch y OpenObserve. Elasticsearch, como parte del stack ELK, utiliza un modelo de datos basado en documentos JSON, indexación invertida para búsquedas de texto completo y un esquema estricto que se infiere o se define manualmente mediante 'mappings'. Los datos se almacenan en 'shards' distribuidos y se replican para alta disponibilidad. La gestión de tipos de campo y la reindexación son operaciones comunes para manejar la evolución del esquema.
OpenObserve, por otro lado, está diseñado con una arquitectura columnar. Esto significa que los datos se almacenan por columnas en lugar de por filas, lo que es inherentemente eficiente para operaciones analíticas como agregaciones (GROUP BY) y filtrado en campos específicos. Su diseño incorpora un manejo automático de esquemas, lo que le permite ingerir datos con tipos de campo inconsistentes sin requerir configuración manual ni rechazar documentos. La compresión de datos es un pilar fundamental, logrando ratios significativamente más altos. Además, OpenObserve utiliza almacenamiento de objetos como S3 de forma nativa, lo que contribuye a una mayor eficiencia de costos y escalabilidad horizontal, aprovechando la replicación y durabilidad inherentes de estos servicios.
Flujo de Ingestión de Logs de Kubernetes
- 1 Generador de Logs Script Python genera logs sintéticos con formato Kubernetes.
- 2 Fluent Bit Reenvía logs a ambos sistemas simultáneamente con configuración dual-output.
- 3 Elasticsearch Intenta ingerir logs, aplica 'mappings', rechaza documentos con conflictos de...
- 4 OpenObserve Ingiere logs con manejo automático de esquema, comprime y almacena.
| Capa | Tecnología | Justificación |
|---|---|---|
| storage | Elasticsearch | Almacenamiento e indexación de logs. Utiliza un modelo de datos orientado a documentos con indexación invertida. Requiere 'mappings' explícitos para campos con tipos inconsistentes (ej. 'flattened' type). |
| storage | OpenObserve | Almacenamiento e indexación de logs. Utiliza un modelo de datos columnar con manejo automático de esquema y alta compresión. |
| compute | Elasticsearch | Procesamiento de ingesta y consultas. Alto consumo de CPU y RAM debido a la indexación y gestión de JVM. JVM heap tuning, shard rebalancing. |
| compute | OpenObserve | Procesamiento de ingesta y consultas. Bajo consumo de CPU y RAM debido a la eficiencia del formato columnar y diseño optimizado. |
| data-processing | Fluent Bit | Agente de recolección y reenvío de logs, configurado con salida dual para ambos sistemas. vs Logstash, Vector Dual-output configuration. |
| storage | AWS S3 | Almacenamiento de objetos de bajo costo y alta durabilidad para OpenObserve. Replicación nativa en 3 AZs. |
| storage | AWS EBS | Almacenamiento de bloques para Elasticsearch (en modo HA con 3x replicación). |
Trade-offs
Ganancias
- ▲▲ Eficiencia de almacenamiento (compresión)
- ▲▲ Consumo de CPU en ingesta
- ▲▲ Consumo de RAM en ingesta
- ▲ Flexibilidad de esquema
- ▲▲ Rendimiento de consultas (FTS y agregaciones)
- ▲▲ Costo de almacenamiento
Costes
- △ Rendimiento de consultas COUNT(*)
Fundamentos Teóricos
El problema de la gestión de esquemas en datos semiestructurados se conecta con el concepto de 'schema-on-read' versus 'schema-on-write'. Elasticsearch, con su enfoque en 'mappings' explícitos, tiende hacia un modelo 'schema-on-write', donde la estructura de los datos se define y valida en el momento de la ingesta. Esto es eficiente para datos con esquemas estables, pero falla cuando se enfrenta a la variabilidad inherente de los logs de Kubernetes, como se observa en el 62% de documentos rechazados debido a conflictos de tipo de campo. Este comportamiento es una manifestación directa de las limitaciones de un sistema que impone una estructura rígida a datos inherentemente flexibles.
En contraste, OpenObserve adopta un enfoque más cercano al 'schema-on-read', donde la interpretación del esquema se realiza en el momento de la consulta, o al menos es mucho más flexible durante la ingesta. Esto se alinea con los principios de bases de datos NoSQL y sistemas de procesamiento de datos como Apache Parquet o Apache ORC, que utilizan formatos columnares y manejan la evolución del esquema de manera más tolerante. La eficiencia en agregaciones y búsquedas de texto completo en OpenObserve se debe a su arquitectura columnar y el uso de índices invertidos optimizados para este formato, un principio bien establecido en la literatura de bases de datos analíticas y sistemas de data warehousing, donde los formatos columnares han demostrado ser superiores para cargas de trabajo OLAP (Online Analytical Processing).