Para garantizar que un clúster de Elasticsearch (ES) funcione de manera eficiente y estable, es fundamental implementar configuraciones que vayan más allá de los valores por defecto. A continuación, se detallan las mejores prácticas para gestionar el rendimiento, la escalabilidad y la fiabilidad de tus datos.

1. Planificación Estructural de Índices

El diseño de los índices es el pilar del rendimiento. Una mala configuración inicial puede degradar la velocidad de búsqueda y saturar los recursos del nodo.

• Dimensionamiento de Shards: Cada shard consume recursos de CPU y memoria. Se recomienda mantener el tamaño de los shards entre 20GB y 50GB. Un exceso de shards pequeños (over-shardign) fragmenta el clúster, mientras que shards demasiado grandes dificultan la recuperación ante fallos.
• Replicación Estratégica: En producción, se debe contar con al menos una réplica por shard para asegurar la alta disponibilidad. Sin embargo, un número excesivo de réplicas penaliza la velocidad de escritura.
• Mapping Estricto: Evite el mapeo dinámico global. Defina los tipos de datos explícitamente para optimizar el almacenamiento. Use keyword para identificadores y text solo para búsqueda de lenguaje natural.

PUT /catalogo_productos
{
  "mappings": {
    "dynamic": "strict",
    "properties": {
      "sku": { "type": "keyword" },
      "precio": { "type": "scaled_float", "scaling_factor": 100 },
      "fecha_registro": { "type": "date", "format": "strict_date_optional_time||epoch_second" },
      "descripcion": { "type": "text", "analyzer": "spanish" },
      "metadatos_internos": { "type": "object", "enabled": false }
    }
  }
}

2. Configuración Crítica de la JVM y Memoria

Elasticsearch depende profundamente de la Java Virtual Machine (JVM). Una gestión inadecuada de la memoria suele ser la causa principal de las caídas del servicio.

• Regla del 50%: Asigne a la JVM Heap exactamente la mitad de la memoria RAM disponible, sin exceder nunca los 31GB-32GB para aprovechar los punteros comprimidos (Compressed Oops).
• Bloqueo de Memoria: Evite que el sistema operativo mueva la memoria de ES al espacio de intercambio (swap), lo cual destruiría el rendimiento. Active bootstrap.memory_lock: true en elasticsearch.yml.
• Caché de Consultas: Supervise el uso de fielddata. Para campos de texto analizados, el uso de agregaciones puede agotar la memoria rápidamente; prefiera el uso de campos keyword con doc_values.

3. Optimización de Búsquedas y Paginación

Las consultas ineficientes pueden bloquear los hilos de ejecución del clúster.

• Evite Deep Paging: No use from y size para navegar por miles de resultados. Esto obliga a ES a coordinar datos de todos los shards en memoria. Use search_after para una paginación eficiente basada en cursores.
• Filtros vs. Consultas: Utilice el contexto de filter para criterios que no requieren puntuación de relevancia (como estados o rangos de fechas). Los filtros se pueden cachear y son mucho más rápidos que must.

GET /logs_sistema/_search
{
  "size": 50,
  "query": {
    "bool": {
      "filter": [
        { "term": { "nivel_log": "error" } },
        { "range": { "timestamp": { "gte": "now-24h" } } }
      ]
    }
  },
  "sort": [
    { "timestamp": "asc" },
    { "_id": "desc" }
  ],
  "search_after": [1715600000, "uuid_anterior_99"]
}

4. Estrategias de Ingesta Masiva

Para escenarios de alta carga de datos, como registros de logs o telemetría, se deben ajustar los parámetros de escritura.

• API Bulk: Nunca envíe documentos uno por uno. Agrupe las operaciones en lotes de 5MB a 15MB.
• Intervalo de Refresco: Aumente index.refresh_interval de 1s a 30s o más si no requiere visibilidad en tiempo real. Esto reduce la carga de creación de segmentos en disco.
• Translog Asíncrono: Para datos no críticos, puede configurar index.translog.durability como async para mejorar significativamente el rendimiento de escritura a cambio de un riesgo mínimo de pérdida de datos ante un fallo eléctrico.

5. Arquitectura de Nodos Especializados

No todos los nodos deben realizar todas las tareas. En clústeres medianos o grandes, la separación de roles es vital.

• Master Dedicated Nodes: Mantenga al menos 3 nodos maestros dedicados (sin datos) para gestionar el estado del clúster sin interrupciones por búsquedas pesadas.
• Data Nodes: Equipados con discos SSD NVMe para máxima velocidad de I/O.
• Coordinating Nodes: Nodos ligeros que actúan como balanceadores de carga internos, recibiendo las peticiones y reduciendo los resultados antes de entregarlos al cliente.

6. Gestión del Ciclo de Vida del Índice (ILM)

Implemente políticas automáticas para mover datos entre diferentes tiers de almacenamiento (Hot, Warm, Cold, Frozen).

• Hot Tier: Discos rápidos para ingesta y consultas frecuentes.
• Warm/Cold Tier: Discos más económicos para datos históricos. Los índices aquí suelen tener los segmentos fusionados (Force Merge) para liberar recursos.

PUT _ilm/policy/retencion_logs_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": { "max_primary_shard_size": "40gb", "max_age": "3d" }
        }
      },
      "delete": {
        "min_age": "90d",
        "actions": { "delete": {} }
      }
    }
  }
}

7. Seguridad y Control de Acceso

Un clúster expuesto sin seguridad es un riesgo crítico de pérdida o secuestro de datos.

• Autenticación y RBAC: Habilite las funciones de seguridad de X-Pack para definir roles de solo lectura, escritura o administración.
• Cifrado TLS: Configure certificados para la comunicación entre nodos (puerto 9300) y para el tráfico HTTP (puerto 9200).
• Audit Logs: Active el registro de auditoría para rastrear quién accedió a qué datos y desde dónde.

8. Backups Mediante Snapshots

La replicación no es un respaldo. Un borrado accidental se replica instantáneamente.

• Utilice la API de Snapshot para realizar copias de seguridad incrementales en sistemas de almacenamiento externos (S3, GCS, Azure Blob o sistemas de archivos compartidos).
• Valide sus backups periódicamente realizando restauraciones de prueba en entornos de staging.

9. Monitoreo Activo de Métricas Clave

Utilice herramientas como Elastic Stack Mointoring o soluciones externas (Prometheus/Grafana) para vigilar:

• Garbage Collection (GC): Si el tiempo de GC aumenta drásticamente, es señal de presión en la memoria heap.
• Pendiente de Tareas (Pending Tasks): Un número alto indica que el nodo maestro está saturado.
• Thread Pool Queues: Si las colas de search o write se llenan, el clúster empezará a rechazar peticiones con errores 429.

10. Diagnóstico y Resolución de Problemas

Cuando el clúster entra en estado "Red" o "Yellow", actúe metódicamente.

• Allocation Explain API: Use esta herramienta para saber exactamente por qué un shard no se está asignando.
• Hot Threads: Si un nodo tiene un uso de CPU al 100%, consulte _nodes/hot_threads para identificar la tarea específica (indexación, búsqueda o fusión de segmentos) que consume los recursos.
• Slow Logs: Configure umbrales de tiempo para registrar consultas lentas y optimizarlas a nivel de aplicación.