Resolución de problemas: Comprobación e interpretación del estado de salud del clúster de Elasticsearch

Solución de Problemas: Comprobación e Interpretación del Estado de Salud del Clúster Elasticsearch

Elasticsearch es un motor de búsqueda y análisis distribuido y robusto, pero su naturaleza distribuida requiere una monitorización constante para garantizar la integridad de los datos y la alta disponibilidad. El primer y más crucial paso en la administración es comprobar el estado de salud del clúster. Un estado saludable garantiza que todos los segmentos de datos primarios y de réplica (shards) se asignan correctamente a los nodos y están operativos.

Esta guía proporciona un enfoque práctico para comprobar el estado del clúster utilizando la API esencial _cat/health. Detallaremos cómo interpretar los estados codificados por colores (Verde, Amarillo, Rojo) y proporcionaremos pasos accionables para diagnosticar y resolver problemas comunes de inestabilidad, ayudando a los administradores a restaurar rápidamente un rendimiento óptimo del clúster.

Comprensión del Estado de Salud de Elasticsearch

Elasticsearch utiliza un sistema simple de semáforo codificado por colores para comunicar el estado operativo de los índices y shards del clúster. Este estado refleja el estado de asignación de los shards primarios y de réplica.

Los Tres Estados de Salud Principales

Estado	Significado	Disponibilidad de Datos	Redundancia	Acción Requerida
Verde	Todos los shards primarios y de réplica están asignados y operativos.	100% Disponible	Completa	Solo Monitorización
Amarillo	Todos los shards primarios están asignados, pero uno o más shards de réplica no están asignados.	100% Disponible	Comprometida	Investigar/Resolver Asignación de Réplicas
Rojo	Uno o más shards primarios no están asignados.	Pérdida/Indisponibilidad Parcial o Total de Datos	Severamente Comprometida	Intervención Inmediata

Comprobación del Estado del Clúster con `_cat/health`

Las APIs _cat están diseñadas para diagnósticos rápidos y legibles por humanos. El endpoint _cat/health es la forma más rápida de obtener una visión general del estado actual del clúster.

Comando Básico

Puede ejecutar este comando utilizando cURL, la consola de Kibana Dev Tools o cualquier cliente HTTP.

# Usando cURL (Formato legible por humanos)
curl -X GET "localhost:9200/_cat/health?v&pretty"

Interpretación de la Salida de `_cat/health`

Una consulta exitosa devuelve una tabla con métricas clave:

Columna	Descripción
`epoch`	El tiempo (timestamp de Unix) en que se ejecutó la solicitud.
`timestamp`	La hora en formato HH:MM:SS.
`cluster`	El nombre del clúster.
`status`	El indicador de color crucial (Verde, Amarillo o Rojo).
`node.total`	Número total de nodos actualmente unidos al clúster.
`node.data`	Número de nodos de datos en el clúster.
`shards`	Número total de shards (primarios + réplica) que deberían estar activos.
`pri`	Número total de shards primarios.
`relo`	Número de shards que se están reubicando actualmente entre nodos.
`init`	Número de shards que se están inicializando actualmente.
`unassign`	Número de shards que no están asignados actualmente.

Ejemplo de un Clúster Saludable (Verde):

epoch      timestamp cluster       status node.total node.data shards pri relo init unassign
1678886400 10:30:00  my-cluster-dev green         3         3     30  15    0    0        0

Diagnóstico de Estado: Amarillo

Cuando un clúster informa un estado Amarillo, significa que si bien todos sus datos están técnicamente disponibles (todos los shards primarios están asignados), el nivel de redundancia definido no se cumple. Uno o más shards de réplica no pudieron ser asignados.

Causas Comunes del Estado Amarillo

Pérdida de Nodo (Temporal): Un nodo de datos que alojaba shards de réplica se desconectó. Elasticsearch está esperando que ese nodo regrese o que un nuevo nodo se una antes de intentar una reasignación.
Nodos Insuficientes: Si requiere 2 réplicas (3 copias de los datos en total) pero solo tiene 2 nodos de datos, la tercera copia no se puede colocar, lo que lleva a un estado Amarillo permanente hasta que se agregue otro nodo.
Retraso en la Asignación: El clúster está configurado para retrasar la asignación de réplicas después de una falla de nodo para evitar un reequilibrio inmediato y costoso si el nodo regresa rápidamente.
Restricciones de Espacio en Disco: Los nodos pueden tener espacio en disco insuficiente para alojar los shards de réplica.

Pasos Accionables para el Estado Amarillo

Comprobar Shards No Asignados: Utilice la API _cat/shards para identificar exactamente qué shards no están asignados (u) y por qué están esperando.

bash curl -X GET "localhost:9200/_cat/shards?v"
Usar la API de Explicación de Asignación: Para diagnósticos detallados sobre por qué un shard específico no está asignado, utilice la API de Explicación de Asignación. Reemplace index_name y shard_id abajo con los valores reales encontrados a través de _cat/shards.

bash curl -X GET "localhost:9200/_cluster/allocation/explain?pretty" -H 'Content-Type: application/json' -d' { "index": "nombre_del_indice", "shard": 0, "primary": false } '

Busque específicamente en los campos unassigned_info y decisions razones como CLUSTER_REBALANCE_ALLOCATION_DELAY o NO_VALID_TARGET_NODE.
Verificar el Número y Configuración de Nodos: Asegúrese de que el número de nodos de datos cumpla o supere el número requerido de réplicas más uno (N réplicas + 1 primario).

Consejo: Si el clúster está Amarillo debido a un mantenimiento conocido y a corto plazo en un nodo, a menudo puede ignorarlo temporalmente, pero tenga en cuenta que está funcionando sin redundancia.

Diagnóstico de Estado: Rojo

Un estado Rojo es crítico y significa que uno o más shards primarios no están asignados. Esto significa que los datos almacenados en ese shard no están disponibles para indexación o búsqueda.

Causas Comunes del Estado Rojo

Fallo Masivo de Nodos: Un nodo primario falló y ningún otro nodo pudo asumir el rol primario porque los datos estaban corruptos o completamente indisponibles en el clúster restante.
Corrupción/Fallo del Disco: El dispositivo de almacenamiento que contenía el shard primario falló y no existe réplica para promocionar.
Problemas de Configuración de Índice: Mala configuración o eliminación incorrecta de archivos de índice a nivel del sistema de archivos.

Intervención Inmediata para el Estado Rojo

Siempre haga una copia de seguridad de su clúster (mediante snapshots) antes de intentar acciones de recuperación manual cuando el clúster esté Rojo.

Comprobar Registros Inmediatamente: Revise los registros del nodo maestro y del(los) nodo(s) que alojan el shard primario fallido para identificar la excepción exacta o la razón del bloqueo (a menudo relacionada con fallos de disco o errores de falta de memoria).
Identificar el Índice Fallido: Use _cat/shards para encontrar el índice asociado con el primario no asignado (p).

```bash

Busque filas donde el estado sea 'UNASSIGNED' y el primario sea 'p'

curl -X GET "localhost:9200/_cat/shards?h=index,shard,prirep,state,unassigned.reason"
```
Intentar Fuerza de Reenrutamiento (Peligroso - Usar como Último Recurso): Si está seguro de que los datos existen en uno de los nodos (por ejemplo, un nodo volvió a estar en línea pero el enrutamiento no se ha corregido), puede intentar un reenrutamiento manual. Esto se usa a menudo cuando un shard primario se pierde permanentemente y usted decide descartar los datos perdidos y forzar un nuevo primario vacío en un nodo saludable.

```bash

PRECAUCIÓN: Este comando puede provocar pérdida de datos si se usa incorrectamente.

Asigna un shard primario vacío a un nodo, marcando el índice como saludable.

curl -X POST "localhost:9200/_cluster/reroute?pretty" -H 'Content-Type: application/json' -d'
{
"commands" : [
{
"allocate_empty_primary" : {
"index" : "nombre_del_indice_fallido",
"shard" : 0,
"node" : "nombre_del_nodo_destino",
"accept_data_loss" : true
}
}
]
}
'
```
Restaurar desde Snapshot: Si el shard primario fallido no se puede recuperar, la única forma segura de restaurar la integridad de los datos es restaurar el índice afectado desde el snapshot exitoso más reciente.

Diagnóstico Avanzado: Configuración del Clúster

A veces, el estado del clúster es Rojo o Amarillo debido a acciones administrativas o salvaguardias operativas preconfiguradas.

Comprobación de la Asignación de Enrutamiento del Clúster

La API _cluster/settings le permite comprobar si la asignación automática de shards se ha deshabilitado explícitamente, lo que impediría que el clúster se recupere por sí solo.

# Recuperar la configuración actual del clúster
curl -X GET "localhost:9200/_cluster/settings?include_defaults=true&pretty"

Busque específicamente la siguiente configuración:

{
  "persistent": {
    "cluster": {
      "routing": {
        "allocation": {
          "enable": "none" 
        }
      }
    }
  }
}

Si cluster.routing.allocation.enable está configurado en none (o primaries), Elasticsearch no asignará shards, bloqueando el clúster en su estado actual (probablemente Amarillo o Rojo).

Reactivación de la Asignación

Para restaurar la asignación normal de shards, actualice la configuración a all:

curl -X PUT "localhost:9200/_cluster/settings?pretty" -H 'Content-Type: application/json' -d'
{
  "persistent": {
    "cluster.routing.allocation.enable": "all"
  }
}
'

Conclusión

Interpretar el estado de salud del clúster Elasticsearch es la habilidad fundamental para cualquier administrador. La API _cat/health proporciona información inmediata sobre la integridad operativa de sus datos. Si bien un estado Verde es el objetivo, comprender que Amarillo significa redundancia reducida y Rojo significa datos no disponibles permite una solución de problemas precisa e inmediata utilizando herramientas secundarias como _cat/shards y la API de Explicación de Asignación. La monitorización regular y los snapshots proactivos siguen siendo las mejores defensas contra fallos críticos del clúster.