Aunque Elasticsearch se hizo famoso como un potente motor de búsqueda , hoy en día es el corazón de innumerables arquitecturas para la monitorización de métricas, logs y trazas. Pero, ¿alguna vez te has preguntado qué ocurre exactamente bajo el capó desde que un dato se genera hasta que lo visualizas en un dashboard?
En este artículo dejamos atrás las presentaciones y vamos directos al grano para entender los conceptos fundamentales que hacen magia en Elasticsearch. Descubriremos cómo se diseñan las pipelines de ingestión para sobrevivir a picos masivos de información , cómo se estructuran los documentos e índices , y por qué estrategias como la división en shards o la gestión del ciclo de vida (ILM) son vitales para mantener un clúster sano, rápido y escalable. Si quieres entender la verdadera arquitectura de los datos, sigue leyendo.
¿Cómo llegan los datos a Elastic?
Hay muchas maneras de enviar métricas logs y trazas a Elastic, pero la más simple es directamente desde uno de sus “beats”: agentes que recopilan información de diferentes fuentes y la envían a Elastic para almacenarla.
En este caso, por ejemplo, podríamos utilizar Filebeat para recopilar logs de nuestra aplicación y enviarlos a Elastic (ya veremos más adelante qué pasa con estos logs). Como capa de visualización, tendríamos Kibana para poder consultarlos, montar visualizaciones gráficas, etc.
Esta arquitectura, si bien es funcional, en un entorno productivo grande no se suele dar, ya que no tienen ningún tipo de medidas para sobrevivir a avalanchas de datos, ni una gestión centralizada de la ingesta y, muchas veces, no solo basamos la recolección de datos en los “beats” de Elastic, sino que podemos tener diferentes fuentes de datos.
Esta otra arquitectura, un poco más compleja, se acercaría más a la realidad de la que hablamos.
Seguiríamos teniendo los mismos componentes que antes (Filebeat, Elastic y Kibana), pero ahora los acompañamos de un sistema de colas (Redis) para poder hacer frente a avalanchas, una pipeline de ingestión de Logstash desde la que poder procesar y transformar los datos que consumimos de la cola y múltiples fuentes de datos, como podría ser una base de datos o una API, a los que hacemos consultas directamente, o jaeger, una herramienta de monitorización de trazas que tiene la capacidad de usar Elastic como su base de datos.
¿Cómo se almacenan los datos?
Todo lo que llega a Elastic se va a acabar guardando como un documento. Esta es la unidad mínima de medida que nos vamos a encontrar en Elastic.
A efectos prácticos, un documento es un JSON en el que se guarda la información que nosotros recogemos (de la manera que sea) y que finalmente ingestamos en Elastic. Además, Elastic también añade unos pocos campos propios de metadata.
En aras de organizar todos los documentos que se van generando, Elastic guarda estos dentro de índices. Un documento, por lo general, suele estar en un solo índice, pero nada impide que esté en varios de ellos.
Podemos pensar en un índice como una tabla de una base de datos en la que cada una de las filas es uno de nuestros documentos
Los índices nos permiten agrupar datos que tienen algún tipo de relación entre sí (los logs de los contenedores de kubernetes, por ejemplo) y que, en principio, tienen la misma estructura. Decimos, de que “en principio tienen la misma estructura” porque ciertamente los índices, aunque los podemos equiparar a una tabla de una base de datos, no son exactamente iguales, y tienen la capacidad, entre otras cosas, de
Divide y vencerás
Seguro que, si has trabajado alguna vez con bases de datos, esto que te voy a contar te suena: tener muchas cosas en un mismo sitio, no es buena idea. Esto mismo pasa en Elastic con los índices.
Guardar toda la información junta puede provocar búsquedas lentas, un mantenimiento caro y un mayor riesgo de perder datos o sufrir caídas del sistema. Para evitar esto, Elasticsearch utiliza los shards, que nos permiten dividir la información en fragmentos mucho más pequeños y manejables.
Los shards nos permiten dividir un índice (que al final es una agrupación lógica de documentos) en tantos pedazos como queramos. Además, nos permiten también gestionar la replicación de estos datos, ya que cada shard puede tener su shard réplica.
Con esta funcionalidad añadida, agilizamos las tareas diarias (ingesta, consulta, modificaciones, etc.) que se realizan sobre los índices y, además, tenemos una arquitectura capaz de balancear mucho mejor la carga, de ofrecer alta disponibilidad y, como decíamos antes, nos da todas esas ventajas que tiene el dividir grandes cantidades de datos en trozos más pequeños.
Y, siguiendo esta filosofía, de igual manera que los índices se dividen en shards más pequeños, podemos tener también nuestro Elasticsearch dividido (ahora tendremos un cluster) en varios nodos. De esta manera, todas las ventajas que comentamos del uso de shards, se multiplican. Al final, nos quedaríamos con una arquitectura similar a esta:
Este es un modelo altamente escalable horizontalmente que nos ofrece alto rendimiento junto con gran resiliencia ante la pérdida de datos. En este aspecto, lo ideal sería tener un cluster de Elasticsearch con tres nodos para poder soportar la caída repentina de uno de ellos y evitar al completo la pérdida de información y la disponibilidad, ¡pero eso para otro momento!
Flujo constante de datos temporales
En sus inicios, Elasticsearch nació como una que con el tiempo ha evolucionado y a día de hoy utilizamos para almacenar datos de un ámbito muy diferente: métricas, logs y trazas. La mayor diferencia que encontramos en este tipo de datos, es que están estrechamente vinculados con el tiempo.
Una línea de “ERROR” en un log no significa lo mismo si está antes o después de haber aplicado un cambio; al igual que un “restart” de un servicio puede tener sentido a una hora, pero representar un problema crítico a otra. Con esto, el punto que quiero transmitir es que estos datos no significan demasiado sin el contexto del tiempo, del momento en el que sucedieron.
Es por ello, que estos datos no deben nunca ser modificados ni eliminados. No es una receta para hacer tarta de queso, que vamos retocando a lo largo del tiempo según aprendemos cosas nuevas. No, en este caso un log, métrica o traza, ocurre cuando tiene que ocurrir y nosotros así lo tenemos que registrar y preservar.
Del mismo modo, estos datos generan una cantidad infinitamente más grande de registros (documentos) de los que todas las recetas de tarta de queso podrían generar, y esto puede ser un problema si no somos capaces de gestionarlos como se merecen (ya hemos hablado un poco de lo mala idea que es tener muchos datos en un mismo sitio).
Para tratar con este tipo de datos, comúnmente conocidos como “series temporales”, en Elastic contamos con los datastreams que, en resumidas cuentas, es una capa por encima de los índices y que nos permite, de manera dinámica y transparente para el usuario, gestionar la ingesta de series temporales (datos estrechamente relacionados con el tiempo que no van a ser modificados).
Los datastreams en cierto modo sustituyen una función que anteriormente se llevaba a cabo mediante
Los datastreams se ponen una capa por encima de los índices y crean un único punto de entrada a múltiples índices más “pequeños” que se irán creando y eliminando en base al tiempo de vida o a su tamaño. Cuando hacemos una consulta sobre este datastream, esta consulta los índices que hay por debajo y devuelve el resultado.
La escritura en un datastream funciona un poco diferente.
Los nuevos datos no se escriben en todos los índices, sino que se determina un “write index” (que viene siendo el último índice en crearse) y es en este dónde se van indexando nuevos registros.
El ciclo de la vida
Finalmente, para manejar el ciclo de vida de todo este conjunto de índices, datastreams y datos, Elastic cuenta con ILM (index lifecycle management). Estas se basan en la idea de que podemos tener múltiples nodos dentro de nuestro clúster que desenvuelven roles diferentes a la hora de almacenar los datos.
Podríamos tener un nodo con hardware más potente para almacenar los datos más recientes, ya que estos serán los más consultados, y otro nodo con hardware no tan potente pero mucho más espacio de almacenamiento, que podríamos utilizar para almacenar los datos a largo plazo.
Mediante las ILMs podemos definir diferentes fases por las que nuestros índices pasarán.
Estas políticas se basan en la edad del índice y/o el tamaño. De tal manera que, por ejemplo, podríamos tener las siguientes fases para nuestro índice “logs”:
- En el momento de la creación del índice, estará en fase “hot”.
- Tras 7 días, pasará a “cold”.
- Finalmente, 23 días después (30 días tras su creación), se eliminará.
La idea aquí es la siguiente:
Como hablamos en particular de logs, lo más probable es que los usuarios quieran revisar los de los últimos días, así que vamos a mantener esos en un nodo hot, con hardware potente, que puede contestar rápidamente a las peticiones. Tras la primera semana, es más raro que se consulten, así que los vamos a pasar a un nodo cold, dónde es más barato mantener el dato ya que el hardware de este no es tan potente. Además, estamos liberando de carga al nodo hot, consiguiendo un mayor rendimiento donde realmente importa.
Finalmente, al cabo de un mes, eliminamos todos los logs para liberar espacio.
Bye bye
Dicho todo esto, solo hemos rascado un poco la superficie de Elasticsearch y todo lo que nos ofrece su ecosistema. Si te apetece profundizar más, mi recomendación es que te montes un cluster sencillito en casa con Docker y sigas la que está repleta de buenas explicaciones y ejemplos.
Y, si de aquí a unos meses te conviertes en un absoluto pro, prueba a llamar a nuestra puerta, ¡que posiblemente tengamos hueco para ti!
