Resolución del Estado del Clúster Rojo: Guía de Solución de Problemas de Elasticsearch Paso a Paso

El estado rojo del clúster de Elasticsearch significa que al menos un shard primario no está asignado. Eso es lo que importa. Algunos datos pueden no estar disponibles, las búsquedas en índices afectados pueden devolver resultados parciales o fallidos, y las escrituras en esos shards no pueden continuar normalmente.

El amarillo es diferente: los primarios están asignados, pero una o más réplicas no. El amarillo aún merece atención porque tienes menos redundancia, pero el rojo es el incidente. No comiences eliminando datos o reasignando shards manualmente. Primero encuentra qué primario no está asignado y por qué Elasticsearch se niega a asignarlo.

Comprendiendo la Salud del Clúster de Elasticsearch

Elasticsearch proporciona una API de Salud del Clúster que ofrece una instantánea del estado del clúster y la asignación de shards. Esta API es tu herramienta principal para diagnosticar problemas de salud.

GET _cluster/health

La salida de este comando incluirá un campo status, que puede ser green, yellow o red. También proporciona información sobre el número de shards activos y no asignados.

• Green: Todos los shards primarios y réplicas están asignados y funcionando correctamente.
• Yellow: Todos los shards primarios están asignados, pero algunos shards réplica no están asignados.
• Red: Uno o más shards primarios no están asignados, lo que lleva a la indisponibilidad de datos para esos shards.

Usa una llamada de salud más detallada cuando estés en un incidente:

GET _cluster/health?level=indices

Luego lista los shards no asignados:

GET _cat/shards?v&h=index,shard,prirep,state,unassigned.reason,node&s=state,index

Causas Comunes y Pasos de Solución de Problemas para Estado Rojo/Amarillo

Cuando tu clúster no está green, es hora de investigar. Aquí están las razones más comunes para shards no asignados y cómo abordarlas:

1. Espacio en Disco Insuficiente

Elasticsearch tiene salvaguardas para prevenir la corrupción de datos debido a discos llenos. Si un nodo se queda sin espacio en disco, evitará que se asignen nuevos shards o que se recuperen los existentes.

Diagnóstico:

• Verifica el uso del disco en cada nodo.
• Usa la API de Explicación de Asignación del Clúster para entender por qué los shards no están asignados.

GET _cluster/allocation/explain

Esta API proporcionará un razonamiento detallado, a menudo señalando las marcas de agua del disco.

Resolución:

• Libera espacio en disco: Elimina índices antiguos, mueve datos a otro nivel o agrega capacidad. Forzar la fusión de índices activos no es una solución rápida para el espacio en disco y puede agregar una E/S pesada durante un incidente.
• Agrega más espacio en disco: Aumenta la capacidad de almacenamiento de tus nodos.
• Configura las marcas de agua del disco: Ajusta cluster.routing.allocation.disk.watermark.low, high y flood_stage solo cuando los valores actuales sean incorrectos para tu entorno. Aumentar las marcas de agua puede ganar tiempo, pero también puede ocultar un problema real de capacidad.

2. Nodo Salió del Clúster (Expulsión de Nodo)

Los nodos pueden salir de un clúster debido a problemas de red, fallos o eliminación intencional. Si un nodo que contiene shards (especialmente shards primarios) sale, esos shards se vuelven no asignados.

Diagnóstico:

• Revisa los registros del clúster en busca de nodos que hayan salido recientemente.
• Monitorea la conectividad de red entre nodos.
• Asegúrate de que todos los nodos sean detectables entre sí. Verifica discovery.seed_hosts, la conectividad de transporte y los registros del clúster. No reintroduzcas cluster.initial_master_nodes en un clúster ya formado como una solución genérica.

Resolución:

• Reinicia el nodo: Si el nodo falló o se volvió no receptivo, intenta reiniciarlo.
• Aborda problemas de red: Resuelve cualquier problema de conectividad de red entre nodos.
• Vuelve a agregar el nodo: Si el nodo fue eliminado intencionalmente, asegúrate de que esté configurado correctamente antes de reincorporarse al clúster.

3. Filtrado y Conciencia de Asignación de Shards

Las reglas de asignación de shards configuradas incorrectamente pueden impedir que los shards se asignen a nodos disponibles.

Diagnóstico:

• Revisa tus configuraciones cluster.routing.allocation.*, particularmente los filtros cluster.routing.allocation.include, exclude y require.
• Verifica cluster.routing.allocation.awareness.attributes si estás usando conciencia de zona o rack.

Resolución:

• Ajusta los filtros de asignación: Modifica los filtros para permitir que los shards se asignen a los nodos apropiados.
• Corrige los atributos de conciencia: Asegúrate de que los nodos estén correctamente etiquetados con atributos de conciencia si se usan, y que tus reglas de asignación los respeten.

4. Espacio en Disco Insuficiente para Asignación (Post-Creación de Índice)

Incluso si un disco no está lleno, Elasticsearch puede evitar la asignación de shards si predice que el disco excederá las marcas de agua altas después de la asignación. Esto está relacionado con las marcas de agua del disco, pero afecta específicamente a nuevas asignaciones.

Diagnóstico:

• La API _cluster/allocation/explain es invaluable aquí.
• Verifica el espacio libre disponible versus el tamaño esperado de los shards.

Resolución:

• Similar al problema general de espacio en disco: libera espacio, agrega más almacenamiento o ajusta las marcas de agua con precaución.

5. Tamaño del Shard y Capacidad del Nodo

Shards muy grandes o un gran número de shards pueden tensar los recursos del nodo (CPU, memoria) y afectar la asignación. Además, si un nodo ha alcanzado su límite de shards (cluster.routing.allocation.total_shards_per_node), no se asignarán nuevos shards a él.

Diagnóstico:

• Verifica los tamaños de los shards (GET _cat/shards?v).
• Monitorea la utilización de recursos del nodo (CPU, memoria).
• Revisa la configuración cluster.routing.allocation.total_shards_per_node.

Resolución:

• Reduce la presión de shards: Para índices futuros, ajusta el rollover y el número de shards para que los shards estén en un rango de tamaño manejable. Para índices existentes, usa reindex, shrink o split solo después de que el clúster sea lo suficientemente estable para manejar el trabajo.
• Aumenta la capacidad del nodo: Agrega nodos más potentes o nodos con más memoria/CPU.
• Ajusta el límite de shards: Si es necesario y tienes suficientes recursos, aumenta cluster.routing.allocation.total_shards_per_node.

6. Problemas del Nodo Maestro

Un nodo maestro inestable puede provocar problemas de asignación de shards. Si el maestro no está disponible o no puede realizar sus funciones, los shards pueden quedar no asignados.

Diagnóstico:

• Revisa los registros del clúster en busca de errores o advertencias relacionados con el maestro.
• Asegúrate de tener un número impar de nodos elegibles como maestro (típicamente 3 o 5) para evitar escenarios de cerebro dividido.
• Verifica que los nodos elegibles como maestro puedan elegir un maestro.

Resolución:

• Estabiliza el maestro: Asegúrate de que los nodos elegibles como maestro estén saludables, tengan suficientes recursos y estén bien conectados.
• Verifica el historial de bootstrap: cluster.initial_master_nodes es solo para la formación inicial del clúster. Después del bootstrap, elimínalo de las configuraciones del nodo y soluciona la inestabilidad del maestro a través de registros, redes de transporte y configuración de votación.

Solución de Problemas Avanzada con _cluster/allocation/explain

La API _cluster/allocation/explain es tu herramienta más poderosa para entender por qué un shard específico no está asignado.

Ejemplo:

GET _cluster/allocation/explain
{
  "index": "my-index",
  "shard": 0,
  "primary": true
}

Esto devolverá una salida JSON detallada explicando por qué el shard primario 0 de my-index no puede ser asignado. Busca campos como deciders que enumeran las razones de la no asignación (por ejemplo, DISK_THRESHOLD, NODE_LEFT, NO_VALID_SHARD_COPY).

Resolución del Estado Amarillo del Clúster

Un estado amarillo significa que los shards primarios están asignados, pero las réplicas no. Esto afecta principalmente la redundancia de datos y la tolerancia a fallos.

Causas Comunes:

• Nodos insuficientes: No tienes suficientes nodos para acomodar el número requerido de réplicas para tus índices.
• Filtrado de asignación de shards: Similar al estado rojo, los filtros pueden estar impidiendo que se asignen réplicas.
• Restricciones de espacio en disco: Los nodos pueden tener suficiente espacio para los shards primarios pero no para las réplicas, especialmente si las marcas de agua del disco están activas.

Resolución:

• Agrega más nodos: Aumenta el número de nodos en tu clúster.
• Ajusta el número de réplicas: Reduce el número de réplicas por índice (index.number_of_replicas) si la tolerancia a fallos no es crítica para todos los índices.
• Verifica la configuración de asignación: Asegúrate de que los shards réplica puedan asignarse a los nodos disponibles.

Mejores Prácticas para Mantener la Salud del Clúster

• Monitorea el Uso del Disco: Monitorea proactivamente el espacio en disco en todos los nodos y configura alertas.
• Dimensiona Correctamente tu Clúster: Asegúrate de tener suficientes nodos y recursos para tu volumen de datos y carga de consultas.
• Gestión de Shards: Mantén los tamaños de los shards dentro de los rangos recomendados y evita el exceso de sharding.
• Revisa Regularmente la Salud del Clúster: Usa GET _cluster/health y GET _cluster/allocation/explain como parte de tu monitoreo rutinario.
• Prueba los Cambios: Antes de hacer cambios significativos en la configuración de asignación o las marcas de agua del disco, pruébalos en un entorno de prueba.

Una vez que conoces el decisor de asignación, el camino suele estar claro. El umbral de disco significa capacidad. NODE_LEFT significa recuperar o reemplazar el nodo faltante. NO_VALID_SHARD_COPY significa que puedes necesitar una restauración de instantánea o una decisión deliberada de pérdida de datos utilizando los procedimientos de recuperación insegura documentados de Elasticsearch. Ese último caso debe manejarse lentamente, verificando primero las copias de seguridad, porque el comando que saca al clúster del rojo también puede confirmar la pérdida permanente de los datos más recientes del primario faltante.