Cuando TSDS se une a ILM: diseñar flujos de datos temporales que no rechazan los datos tardíos

Recientemente, migré el clúster de métricas de un cliente de “todo en el nivel caliente” a una arquitectura de caliente/frío/congelado. Fue un cambio que había realizado docenas de veces antes. En cuestión de minutos, Logstash dejó de avanzar los datos por completo.

Elasticsearch rechazaba métricas que llegaban con retraso. Esos rechazos hicieron que el pipeline se retrasara, lo que dio como resultado más datos tardíos, lo que desencadenó aún más rechazos. Finalmente, el pipeline se detuvo por completo.

Tuvimos que restaurar desde un snapshot, reindexar los datos y rediseñar el pipeline de ingesta para recuperarnos.

La causa raíz no era la gestión del ciclo de vida de los índices (ILM) en sí. Eran los flujos de datos temporales (TSDS) y cómo imponen índices de respaldo acotados en el tiempo.

TSDS puede reducir las necesidades de almacenamiento para las métricas en un 40–70 %, pero los cambios de arquitectura que hacen que TSDS sea eficiente también alteran el comportamiento de los índices con el tiempo. Esos cambios importan al diseñar políticas de ILM o cuando tus Pipelines de ingesta pueden generar datos que llegan con retraso.

TL;DR

Al usar TSDS:

• Los índices de respaldo solo aceptan documentos dentro de una ventana de tiempo específica.
• Si llegan datos tardíos después de que un índice pasa a frío o congelado, Elasticsearch rechaza esos documentos o los envía al almacén de fallas, si está configurado.

Regla de diseño:

¿Qué es un flujo de datos temporales?

Un flujo de datos temporales (TSDS) es un flujo de datos especializado optimizado para datos de métricas. Los datos se distribuyen de manera que los documentos relacionados se encuentren dentro de los mismos fragmentos, lo que optimiza su búsqueda y recuperación. Así es como lo hace Elasticsearch:

Cada documento contiene:

• Una marca de tiempo.
• Campos de dimensión que identifican las series temporales.
• Campos métricos que representan valores medidos.

Entre los ejemplos, se incluyen los siguientes:

• Uso de CPU por host.
• Latencia de las solicitudes por servicio.
• Lecturas de temperatura por sensor.

Las dimensiones identifican lo que queremos medir, mientras que las métricas representan valores que cambian con el tiempo.

Dimensiones

Las dimensiones describen la entidad medida.

Ejemplos:

Los definimos en mapeos con:

Métricas

Las métricas representan valores numéricos y se definen mediante:

Tipos comunes de métricas:

• Indicador: valores que suben y bajan.
• Contador: valores que aumentan hasta que se reinician.

Elastic Agent recopila principalmente métricas y datos de logs, por lo que, incluso si no has habilitado ningún índice TSDS manualmente, puedes tenerlos aún en tu clúster.

El campo _tsid

Elasticsearch genera internamente un valor _tsid a partir de campos dimensionales. Esto permite que los documentos con dimensiones idénticas se dirijan al mismo shard, lo que mejora:

• Compresión.
• Localidad de búsqueda.
• Rendimiento de agregación.

La diferencia clave: índices de respaldo limitados en el tiempo

Los flujos de datos tradicionales siempre escriben en el índice de respaldo más reciente, llamado índice de escritura, pero TSDS se comporta de manera diferente.

Cada índice de respaldo TSDS tiene una ventana de tiempo definida y solo acepta documentos con @timestamp valores que se encuentren en esa ventana:

Cuando se indexa un documento, Elasticsearch lo dirige al índice de respaldo responsable de esa marca de tiempo, lo que significa que, a diferencia de los índices tradicionales, un TSDS puede escribir en varios índices de respaldo al mismo tiempo.

Por ejemplo:

• Datos en tiempo real → índice más reciente.
• Datos tardíos → índice anterior que abarca ese intervalo de tiempo.

Diseño para datos con retraso

Las pipelines de ingesta reales rara vez entregan métricas perfectamente a tiempo. Las métricas pueden retrasarse por interrupciones de la red, retrasos en el camino, ingesta por batch y pérdida de dispositivos periféricos, que se vuelven a conectar y comienzan a ponerse al día.

Los índices tradicionales absorben silenciosamente esos retrasos. TSDS no lo hace.

Si la marca de tiempo de un documento queda fuera del intervalo de índices de respaldo con capacidad de escritura, Elasticsearch lo rechaza, lo que significa que tu política de ILM debe tener en cuenta los datos que llegan con retraso.

La restricción crítica

Los índices de respaldo deben mantenerse con permisos de escritura el tiempo suficiente para aceptar datos tardíos.

En términos prácticos:

Debido a que ILM mide las antigüedades desde el desplazamiento, la regla operativa se convierte en:

Por ejemplo, si las métricas pueden llegar con hasta seis horas de retraso, los índices deben permanecer editables al menos seis horas después de la transferencia.

No tener en cuenta esta restricción fue exactamente lo que causó la falla de ingesta descrita anteriormente. Los datos que llegaban tarde se dirigieron a un índice anterior, que ya estaba en el nivel frío y, por tanto, bloqueaba la escritura.

Gestión de documentos rechazados

Cuando TSDS rechaza un documento, Elasticsearch devuelve un error, lo que indica que la marca de tiempo no está dentro del rango de índices de escritura. La forma en que tu pipeline de ingesta maneja ese error determina si pierdes datos o si la ingesta se detiene.

El mecanismo principal para manejar documentos rechazados es el almacén de fallas.

Almacén de fallas (recomendado en Elasticsearch 9.1+)

Elasticsearch 9.1 introdujo el almacén de fallas, que captura automáticamente los documentos rechazados. En lugar de devolver errores a los clientes, Elasticsearch escribe los documentos rechazados en un índice de fallas dedicado dentro del flujo de datos.

Puedes inspeccionar las fallas usando:

Usar el almacén de fallas evita que los pipelines de ingesta se bloqueen por errores de rechazo, a la vez que conserva los datos fallidos para analizarlos o reindexarlos.

Monitoreo de problemas de rechazo

Los problemas de retraso suelen aparecer primero como anomalías de ingesta. Puedes notarlos primero como:

• Caídas repentinas en la tasa de indexación.
• Aumentos repentinos en el número de documentos rechazados.
• Una cantidad cada vez mayor de entradas del almacén de fallas.
• Discrepancias entre el número de entradas y salidas del pipeline.

Alertar sobre estas señales permite a los operadores detectar problemas antes de que los pipelines se detengan. Se pueden utilizar flujos de trabajo, tareas de machine learning y otros mecanismos para automatizar la detección y la notificación.

Lista de verificación de migración para TSDS + ILM

Si estás migrando un cluster de métricas a TSDS, introduciendo la organización en niveles con ILM o actualizando a una versión de Elasticsearch en la que las métricas son TSDS por defecto, revisa primero estos elementos.

1. Mide la latencia de la ingesta

Antes de cambiar las políticas de ILM, determina:

• Retraso normal de ingesta.
• Retraso en el peor de los casos durante incidentes.
• Retrasos causados por pipelines de batch.

Tu diseño de ILM debe contemplar el retraso máximo realista.

2. Verifica las ventanas de tiempo de indexación

Inspecciona tus índices de respaldo TSDS:

Busca:

• time_series.start_time
• time_series.end_time

Estos límites determinan qué índices pueden aceptar documentos. Entender estas ventanas puede ayudarte a determinar cuán tarde pueden llegar los datos antes de que se rechacen.

3. Dimensiona el nivel caliente para llegadas tardías

Garantiza que los índices de respaldo permanezcan con permisos de escritura el tiempo suficiente para los datos retrasados.

Regla operativa:

• warm_min_age > rollover_max_age + maximum_expected_lateness

Recuerda, los índices deben permanecer en modo de escritura durante al menos seis horas si las métricas pueden llegar con seis horas de retraso.

4. Decide cómo manejar los documentos rechazados

Elige una estrategia antes de habilitar TSDS:

• Almacén de fallas (recomendado en Elasticsearch 9.1+).
• Cola de mensajes no procesados de Logstash.
• Índice de respaldo para retrasos.
• Aceptar la pérdida de datos limitada.

5. Monitorea el estado de la ingesta

Agrega alertas para:

• La tasa de indexación disminuye.
• Documentos rechazados.
• Crecimiento del almacén de fallas.
• Desajustes de entrada/salida en la pipeline.

Los problemas de datos tardíos a menudo aparecen primero como anomalías de ingesta.

Resumen

Los flujos de datos temporales ofrecen importantes mejoras de almacenamiento y rendimiento para las cargas de trabajo de métricas, pero introducen un cambio arquitectónico importante: los índices de respaldo están acotados en el tiempo, lo que afecta el comportamiento de ILM.

Al usar TSDS:

• Los índices deben mantenerse con permisos de escritura el tiempo suficiente para aceptar datos tardíos.
• Los pipelines de ingesta deben gestionar los documentos rechazados de forma segura.

La regla clave a recordar es:

Si diseñas políticas de ILM teniendo en cuenta esa limitación, TSDS funciona muy bien para cargas de trabajo de métricas.

Sin embargo, si lo ignoras, tu pipeline de ingesta puede descubrir esos límites de tiempo de la manera difícil.