Introducción al Ciclo de Vida de Índices (ILM)

En entornos de producción, Elasticsearch se utiliza frecuentemente para el almacenamiento y análisis de registros (logs). Dado que estos datos suelen tener una utilidad temporal, es fundamental implementar mecanismos que automaticen su purga tras un periodo determinado. Esto evita el crecimiento descontrolado del clúster y optimiza el rendimiento de las consultas. La funcionalidad de Index Lifecycle Management (ILM) gestiona este proceso a través de cuatro fases principales: Hot, Warm, Cold y Delete.

Aunque la fase Hot es obligatoria para la ingesta activa, las demás son opcionales y se configuran según los requisitos de retención. En este tutorial, nos centraremos en una configuración simplificada que abarca únicamente las fases Hot (con rotación o rollover) y Delete.

Configuración del Flujo de ILM

Para que la automatización funcione correctamente, es necesario definir y enlazar tres componentes esenciales: una política (policy), una plantilla de índice (index template) y un índice inicial (bootstrap index).

1. Definición de la Política de Ciclo de Vida

Comenzamos creando la política que dictará las reglas de transición. Utilizaremos el endpoint \_ilm/policy mediante una petición HTTP PUT.

PUT _ilm/policy/app_logs_retention
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": {
            "max_docs": 5000,
            "max_size": "10gb"
          },
          "set_priority": {
            "priority": 100
          }
        }
      },
      "delete": {
        "min_age": "15d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

En este ejemplo, la política app_logs_retention establece que un índice en fase Hot sufrirá un rollover (creación de un nuevo índice de escritura) cuando alcance los 5000 documentos o los 10 GB de tamaño. Posteriormente, tras 15 días desde su creación, el índice pasará a la fase Delete y será eliminado automáticamente.

2. Configuración de la Plantilla de Índice

La plantilla asegura que cualquier índice nuevo creado bajo un patrón específico herede la configuración adecuada, incluyendo la asignación de la política ILM y el alias de escritura.

PUT _template/app_logs_template
{
  "index_patterns": ["app-logs-*"],
  "settings": {
    "number_of_shards": 2,
    "number_of_replicas": 1,
    "index.lifecycle.name": "app_logs_retention",
    "index.lifecycle.rollover_alias": "app-logs-write"
  },
  "mappings": {
    "properties": {
      "timestamp": { "type": "date" },
      "level": { "type": "keyword" },
      "message": { "type": "text" }
    }
  }
}

Aquí definimos que los índices que coincidan con app-logs-* aplicarán la política app_logs_retention y utilizarán el alias app-logs-write para las operaciones de rotación.

3. Creación del Índice Inicial (Bootstrap)

ILM requiere un índice inicial que actúe como punto de partida y esté vinculado al alias de escritura definido en la plantilla.

PUT app-logs-000001
{
  "aliases": {
    "app-logs-write": {
      "is_write_index": true
    }
  }
}

Este comando inicializa el primer índice de la secuencia y lo marca como el destino activo para la ingesta de datos.

4. Ajuste del Intervalo de Sondeo (Opcional para Pruebas)

Por defecto, Elasticsearch evalúa las políticas ILM cada 10 minutos. Para acelerar las pruebas en entornos de desarrollo, podemos reducir este intervalo a nivel de clúster.

PUT _cluster/settings
{
  "persistent": {
    "indices.lifecycle.poll_interval": "5s"
  }
}

Validación y Monitoreo del Proceso

Para verificar el comportamiento, insertamos algunos documentos utilizando el alias de escritura en lugar del nombre real del índice.

POST app-logs-write/_doc
{
  "timestamp": "2023-10-25T10:00:00Z",
  "level": "INFO",
  "message": "System started successfully"
}

A medida que se ingieren datos y se cumplen las condiciones de rollover, Elasticsearch generará nuevos índices (por ejemplo, app-logs-000002). Para inspeccionar el estado actual de los índices gestionados por ILM, ejecutamos:

GET app-logs-*/_ilm/explain

La respuesta mostrará métricas detalladas de cada índice, inclueyndo la fase actual, la acción en ejecución y el tiempo transcurrido:

{
  "indices": {
    "app-logs-000001": {
      "index": "app-logs-000001",
      "managed": true,
      "policy": "app_logs_retention",
      "lifecycle_date_millis": 1698228000000,
      "age": "15.5d",
      "phase": "delete",
      "phase_time_millis": 1698228900000,
      "action": "delete",
      "action_time_millis": 1698228900000,
      "step": "wait-for-shard-history-leases",
      "step_time_millis": 1698228900000
    },
    "app-logs-000002": {
      "index": "app-logs-000002",
      "managed": true,
      "policy": "app_logs_retention",
      "lifecycle_date_millis": 1698228600000,
      "age": "2h",
      "phase": "hot",
      "phase_time_millis": 1698228600000,
      "action": "rollover",
      "action_time_millis": 1698228600000,
      "step": "check-rollover-ready",
      "step_time_millis": 1698228600000
    }
  }
}

En este escenario, el índice original app-logs-000001 ha superado los 15 días y se encuentra en la fase de eliminación, mientras que el nuevo índice app-logs-000002 está activo en la fase Hot, esperando alcanzar los umbrales de rollover. Las aplicaciones cliente pueden seguir escribiedno y consultando datos a través del alias app-logs-write, abstrayéndose por completo de la creación y destrucción subyacente de los índices físicos.