Optimización del Almacenamiento con la Gestión del Ciclo de Vida de Índices (ILM) en Elasticsearch

La gestión eficiente del almacenamiento y la automatización de la retención de datos son cruciales para mantener un clúster de Elasticsearch saludable y rentable. A medida que tus datos crecen, gestionar manualmente los índices, su tamaño, rendimiento y archivado puede convertirse en una tarea titánica y propensa a errores. Aquí es donde entra en juego la Gestión del Ciclo de Vida de Índices (ILM) en Elasticsearch, una característica poderosa que te permite definir y automatizar cómo los índices se mueven a través de diferentes fases, desde su creación hasta su eliminación.

ILM te ayuda a equilibrar el costo del almacenamiento con las necesidades de rendimiento y retención de datos. Por ejemplo, los datos más recientes suelen requerir un acceso rápido (fase hot), mientras que los datos más antiguos pueden moverse a un almacenamiento más barato y de menor rendimiento (fase cold) antes de ser eliminados.

🎯 ¿Qué es la Gestión del Ciclo de Vida de Índices (ILM)?

ILM es una característica de Elasticsearch que permite automatizar la administración de índices basándose en políticas predefinidas. Estas políticas guían a los índices a través de diferentes fases a lo largo de su vida útil, aplicando acciones específicas en cada fase para optimizar el almacenamiento y el rendimiento.

Imagina que tienes un flujo constante de logs de aplicaciones. Los logs de las últimas 24 horas son cruciales para el monitoreo en tiempo real, pero los logs de hace 3 meses solo se necesitan para auditorías ocasionales y los de hace más de un año pueden ser eliminados. ILM te permite definir esta lógica automáticamente.

Fases de una Política ILM 📊

Una política ILM típicamente consta de varias fases, cada una diseñada para un propósito específico:

• Hot (Cálida): Los índices en esta fase están activos y se están escribiendo y leyendo con frecuencia. El objetivo es maximizar el rendimiento de ingesta y búsqueda. Es común usar hardware de alto rendimiento (SSDs rápidos).
• Warm (Tibia): Los índices en esta fase ya no se están escribiendo, pero aún se leen con cierta frecuencia. El objetivo es optimizar el almacenamiento manteniendo un buen rendimiento de lectura. Se pueden aplicar operaciones como shrink (reducción) o force merge (fusión forzada).
• Cold (Fría): Los índices en esta fase son de solo lectura y rara vez se acceden. El objetivo principal es reducir los costos de almacenamiento. Se pueden mover a hardware más barato (HDDs) o a cold tiers dedicados.
• Frozen (Congelada): Esta fase, introducida en versiones más recientes, permite reducir aún más el uso de recursos del clúster "congelando" los índices para reducir el consumo de memoria, a costa de un tiempo de búsqueda más lento. Los datos se cargan bajo demanda.
• Delete (Eliminación): La fase final donde los índices se eliminan permanentemente del clúster. Esto ayuda a cumplir con las políticas de retención de datos.

🛠️ Componentes Clave de ILM

Para que ILM funcione, necesitamos entender sus componentes principales:

1. Políticas ILM: Son las reglas que definen cómo se gestionan los índices a lo largo de sus fases. Se crean y gestionan a través de la API de ILM o Kibana.
2. Index Templates (Plantillas de Índices): Asocian una política ILM a los nuevos índices que coinciden con un patrón. Por ejemplo, todos los índices que empiecen por logs- pueden usar una política ILM específica.
3. Aliases: Aunque no son exclusivos de ILM, los aliases son fundamentales para asegurar que tus aplicaciones siempre consulten el "índice correcto" sin necesidad de cambiar su configuración cuando ILM rota los índices.
4. Rollover: Una acción clave dentro de la fase hot. Cuando un índice cumple ciertos criterios (tamaño, número de documentos o edad), ILM automáticamente crea un nuevo índice, redirige las escrituras a este nuevo índice y mueve el índice "viejo" a la siguiente fase (usualmente warm).

🚀 Configurando una Política ILM: Paso a Paso

Vamos a crear una política ILM de ejemplo para gestionar logs. Nuestro objetivo será:

• Mantener los logs de los últimos 7 días en la fase hot (alta disponibilidad, ingesta y búsqueda).
• Mover los logs de 7 a 30 días a la fase warm (solo lectura, optimizados).
• Mover los logs de 30 a 90 días a la fase cold (almacenamiento barato).
• Eliminar los logs después de 90 días.

Paso 1: Crear la Política ILM

Usaremos la API de Elasticsearch para definir nuestra política. Podrías hacerlo también desde Kibana en Stack Management > Index Lifecycle Policies.

PUT _ilm/policy/my_logs_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_age": "7d",
            "max_docs": 100000000,
            "max_size": "50gb"
          },
          "set_priority": {
            "priority": 100
          }
        }
      },
      "warm": {
        "min_age": "7d",
        "actions": {
          "forcemerge": {
            "max_num_segments": 1
          },
          "shrink": {
            "number_of_shards": 1
          },
          "set_priority": {
            "priority": 50
          }
        }
      },
      "cold": {
        "min_age": "30d",
        "actions": {
          "freeze": {},
          "set_priority": {
            "priority": 0
          }
        }
      },
      "delete": {
        "min_age": "90d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

Explicación de la política:

• hot fase:
  • rollover: El índice pasará a la fase warm si tiene más de 7 días de antigüedad, 100 millones de documentos o un tamaño de 50GB, lo que ocurra primero. Se creará un nuevo índice logs-000002, logs-000003, etc.
  • set_priority: Asigna una prioridad alta para búsquedas en caliente.
• warm fase:
  • min_age: El índice entra en esta fase al cumplir 7 días (después del rollover).
  • forcemerge: Reduce el número de segmentos a 1 para optimizar el rendimiento de lectura y liberar recursos. Esto es intensivo en E/S, así que solo se hace en índices de solo lectura.
  • shrink: Reduce el número de shards a 1. Esto minimiza el overhead del clúster y el espacio en disco, agrupando los datos en menos shards.
  • set_priority: Una prioridad media para búsquedas en datos tibios.
• cold fase:
  • min_age: El índice entra en esta fase al cumplir 30 días.
  • freeze: Congela el índice para reducir el consumo de memoria del clúster.
  • set_priority: Prioridad baja, ya que se espera que el acceso sea raro.
• delete fase:
  • min_age: El índice se elimina automáticamente a los 90 días.

Paso 2: Crear una Plantilla de Índice (Index Template)

La plantilla de índice es la que asociará automáticamente nuestra política ILM a los nuevos índices que coincidan con un patrón. También configuraremos el alias para escrituras.

PUT _index_template/my_logs_template
{
  "index_patterns": ["logs-*"],
  "data_stream": {},
  "template": {
    "settings": {
      "index.lifecycle.name": "my_logs_policy",
      "index.lifecycle.rollover_alias": "my_logs_write",
      "index.number_of_shards": 3, 
      "index.number_of_replicas": 1
    },
    "mappings": {
      "properties": {
        "@timestamp": { "type": "date" },
        "message": { "type": "text" },
        "level": { "type": "keyword" }
      }
    }
  },
  "priority": 500,
  "composed_of": []
}

Explicación de la plantilla:

• index_patterns: Esta plantilla se aplicará a cualquier índice que empiece con logs-.
• data_stream: Indicamos que queremos usar data streams con esta plantilla. Los data streams son la forma recomendada de gestionar series temporales de datos, ya que automatizan gran parte de la gestión de índices individuales con ILM y rollover.
• index.lifecycle.name: Asocia la política ILM my_logs_policy que acabamos de crear.
• index.lifecycle.rollover_alias: Define el alias my_logs_write que las aplicaciones usarán para escribir nuevos documentos. ILM se encargará de apuntar este alias al índice hot actual.
• index.number_of_shards y index.number_of_replicas: Configuraciones iniciales para los shards y réplicas de los nuevos índices.
• mappings: Define el esquema de los campos para los documentos. Es crucial definir @timestamp como tipo date para que ILM pueda usarlo.

Paso 3: Configurar la ingesta de datos

Ahora, tus aplicaciones deben escribir en el alias de escritura definido en la plantilla: my_logs_write.

POST my_logs_write/_doc
{
  "@timestamp": "2023-10-26T10:00:00Z",
  "message": "Este es un mensaje de log de prueba",
  "level": "info"
}

Cuando ingeses el primer documento, Elasticsearch creará automáticamente el data stream logs- y el primer índice logs-000001 (o similar, siguiendo el patrón interno de data streams) y le aplicará la política my_logs_policy.

POST my_logs_write/_doc
{
  "@timestamp": "2023-10-26T10:05:00Z",
  "message": "Otro log importante",
  "level": "warn"
}

Paso 4: Monitorear ILM

Puedes monitorear el estado de tus políticas ILM y los índices asociados a través de la API o Kibana (Stack Management > Index Lifecycle Policies).

Para ver el estado de un índice específico:

GET logs-000001/_ilm/explain

Esto te mostrará en qué fase se encuentra, cuándo se espera la próxima acción, etc.

Para ver todas las políticas:

GET _ilm/policy

💡 Casos de Uso Avanzados y Mejores Prácticas

ILM es increíblemente flexible y puede adaptarse a casi cualquier estrategia de gestión de datos. Aquí algunas ideas y mejores prácticas:

1. Gestión por Tiers de Hardware (Hot-Warm-Cold Architecture)

Elasticsearch puede configurarse con node roles para que los nodos solo almacenen índices en ciertas fases. Por ejemplo:

• Nodos Hot: Con SSDs rápidos y mucha RAM para índices hot.
• Nodos Warm: Con HDDs de mayor capacidad para índices warm.
• Nodos Cold/Frozen: Con HDDs de muy alta capacidad y menor RAM para índices cold y frozen.

Esto se logra asignando node.roles en el elasticsearch.yml y luego usando index.routing.allocation.require._tier_preference en las acciones de la política ILM para mover índices entre tiers.

PUT _ilm/policy/my_tiered_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "set_priority": { "priority": 100 }
        }
      },
      "warm": {
        "min_age": "7d",
        "actions": {
          "allocate": {
            "require": { "data_tier": "warm" }
          },
          "set_priority": { "priority": 50 }
        }
      },
      "cold": {
        "min_age": "30d",
        "actions": {
          "allocate": {
            "require": { "data_tier": "cold" }
          },
          "freeze": {},
          "set_priority": { "priority": 0 }
        }
      },
      "delete": {
        "min_age": "90d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

2. Uso de Data Streams

Aunque ya los hemos mencionado, es crucial enfatizar que los data streams simplifican enormemente la gestión de series temporales de datos con ILM. Crean automáticamente índices de respaldo (backing indices) con nombres secuenciales y gestionan los aliases de lectura/escritura de forma transparente.

3. Consideraciones de Rendimiento

• Número de shards: Reducir el número de shards en la fase warm (shrink) es una excelente manera de optimizar recursos, ya que un menor número de shards significa menos overhead para el clúster. Hazlo solo en índices de solo lectura.
• forcemerge: La fusión forzada es intensiva. Úsala solo en la fase warm (o cold), cuando el índice ya no recibe escrituras. Fusionar a un solo segmento por shard es ideal para lecturas, pero hazlo con moderación y cuidado en clústeres muy ocupados.
• freeze: Congelar un índice reduce su huella de memoria en los nodos, pero la primera búsqueda en un índice congelado puede ser más lenta ya que necesita cargarse. Es útil para datos raramente accedidos.

4. Seguridad y Auditoría

ILM te ayuda a cumplir con políticas de retención de datos y normativas. Al automatizar la eliminación, reduces el riesgo de incumplimiento accidental. Asegúrate de que tus políticas de delete estén bien definidas y sean revisadas periódicamente.

Comparativa: ILM vs. Gestión Manual de Índices

📝 Resumen y Conclusión

La Gestión del Ciclo de Vida de Índices (ILM) es una característica indispensable para cualquier implementación de Elasticsearch que maneje volúmenes significativos de datos, especialmente series temporales como logs, métricas o eventos. Permite automatizar tareas tediosas y propensas a errores, garantizando que tus datos se almacenen de la manera más eficiente y rentable posible, mientras se mantiene el rendimiento adecuado para cada etapa de su vida.

Al invertir tiempo en diseñar políticas ILM robustas y combinarlas con index templates y data streams, simplificarás drásticamente la administración de tu clúster de Elasticsearch, liberarás a tu equipo de operaciones de tareas repetitivas y asegurarás la conformidad con las políticas de retención de datos. ¡Es una victoria para el rendimiento, el costo y la tranquilidad!