Troubleshooting: Wazuh no genera nuevos índices

Problema detectado

Se detectó que Wazuh dejó de generar nuevos índices y el dashboard dejó de mostrar eventos recientes.

Al ingresar a Explore, la visualización de alertas se había detenido y no se mostraba en tiempo real.

Diagnóstico inicial

Como primer paso, se verificó si Wazuh continuaba recopilando eventos localmente.

Se revisaron los archivos:

• /var/ossec/logs/alerts/alerts.json
• /var/ossec/logs/ossec.log

y se observó que ambos seguían registrando eventos con timestamps actualizados.

Esto indicaba que el manager continuaba procesando logs, por lo que el problema probablemente estaba relacionado con la indexación hacia OpenSearch/Wazuh Indexer.

Hallazgo

Se ejecutó el siguiente comando para revisar el estado de asignación del cluster:

curl -k -u user:TU_PASSWORD \
https://localhost:9200/_cat/allocation?v

Resultado observado:

shards disk.indices disk.used disk.avail disk.total disk.percent host      ip        node
1001   3.3gb        36.9gb    60.9gb     97.8gb     37           127.0.0.1 127.0.0.1 node-1

El dato relevante fue:

shards: 1001

Los shards son particiones lógicas utilizadas por OpenSearch para distribuir y organizar datos indexados.

En instalaciones estándar de Wazuh/OpenSearch existe un límite de shards por nodo configurado mediante:

cluster.max_shards_per_node

En muchos despliegues el valor por defecto es:

1000

Cuando el nodo alcanza ese límite, OpenSearch deja de poder crear índices adicionales. Como consecuencia, Wazuh puede continuar procesando eventos localmente, pero falla la creación de nuevos índices para almacenamiento y visualización.

Este comportamiento es consistente con los siguientes síntomas observados:

• alerts.json continúa creciendo
• filebeat test output responde correctamente
• el espacio en disco permanece disponible
• no aparecen índices nuevos en el dashboard
• la cantidad de shards supera el límite configurado

Confirmación

Para validar el límite configurado:

curl -k -u user:TU_PASSWORD \
https://localhost:9200/_cluster/settings?include_defaults=true&pretty

Buscar:

"cluster.max_shards_per_node": "1000"

Solución recomendada

La remediación recomendada consiste en reducir la cantidad de shards eliminando índices antiguos y posteriormente definir una política de retención.

1. Revisar índices existentes

curl -k -u user:TU_PASSWORD \
https://localhost:9200/_cat/indices?v

En instalaciones que llevan meses funcionando, suele haber una acumulación significativa de índices históricos como:

• wazuh-alerts-*
• wazuh-archives-*

2. Revisar índices de alertas

curl -k -u user:TU_PASSWORD \
https://localhost:9200/_cat/indices/wazuh-alerts-*?v

3. Eliminar índices antiguos

Por ejemplo, para eliminar índices anteriores a abril de 2026:

curl -k -u admin:user -X DELETE \
"https://localhost:9200/wazuh-alerts-4.x-2026.03*"

Para archivos históricos (archives):

curl -k -u admin:TU_PASSWORD -X DELETE \
"https://localhost:9200/wazuh-archives-4.x-2026.03*"

Importante: eliminar índices implica pérdida permanente de datos históricos. Antes de aplicar esta acción, validar requisitos de compliance, auditoría o retención.

Una vez reducida la cantidad de shards por debajo del límite configurado, OpenSearch debería volver a crear índices automáticamente.

En algunos casos puede acelerarse el reintento reiniciando Filebeat:

sudo systemctl restart filebeat

Solución temporal (workaround)

Como medida transitoria, puede aumentarse temporalmente el límite de shards para destrabar la indexación mientras se realiza la limpieza.

curl -k -u admin:TU_PASSWORD -X PUT \
https://localhost:9200/_cluster/settings \
-H 'Content-Type: application/json' \
-d '{
  "persistent": {
    "cluster.max_shards_per_node": 1200
  }
}'

Sin embargo, esto no corrige la causa raíz y únicamente posterga el problema.

En entornos de nodo único, una cantidad elevada de shards puede derivar en oversharding, afectando consumo de memoria, rendimiento y tiempos de operación del cluster.