

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

# Solución de problemas de Amazon OpenSearch Service
<a name="handling-errors"></a>

En este tema se describe cómo identificar y resolver problemas comunes OpenSearch de Amazon Service. Consulte la información de esta sección antes de ponerse en contacto con el [Soporte de AWS](https://aws.amazon.com/premiumsupport/).

## ¿No puedes acceder a los OpenSearch paneles de control
<a name="troubleshooting-dashboards-configure-anonymous-access"></a>

El punto final OpenSearch de los paneles no admite solicitudes firmadas. Si la política de control de acceso del dominio solo concede acceso a determinados roles de IAM y no se ha configurado la [autenticación de Amazon Cognito](cognito-auth.md), es posible que aparezca el siguiente error cuando se intente acceder a Dashboards:

```
"User: anonymous is not authorized to perform: es:ESHttpGet"
```

Si tu dominio de OpenSearch servicio usa el acceso a una VPC, es posible que no recibas este error, pero es posible que se agote el tiempo de espera de la solicitud. Para obtener más información acerca de cómo solucionar este problema y las distintas opciones de configuración disponibles [Control del acceso a Dashboards](dashboards.md#dashboards-access), consulte [Acerca de las políticas de acceso en los dominios de VPC](vpc.md#vpc-security) y [Identity and Access Management en Amazon OpenSearch Service](ac.md).

Para obtener una lista más amplia de los problemas que pueden hacer que los OpenSearch paneles no estén disponibles, junto con los pasos para resolverlos, consulte. [OpenSearch Paneles de resolución de problemas](dashboards-troubleshooting.md)

## No se puede obtener acceso al dominio de VPC
<a name="troubleshooting-vpc-domain"></a>

Consulte [Acerca de las políticas de acceso en los dominios de VPC](vpc.md#vpc-security) y [Probar los dominios de VPC](vpc.md#vpc-test).

## Tráfico de salida de un dominio de VPC
<a name="troubleshooting-vpc-egress"></a>

Si has habilitado la salida a través de tu VPC en un dominio y las integraciones salientes comienzan a fallar, comprueba lo siguiente:
+ Una integración de salida falla después de habilitar la salida. Comprueba el enrutamiento de la VPC hacia el destino y el estado de la resolución de la VPC. Consulte [Resolución de problemas](vpc-egress.md#vpc-egress-troubleshoot).
+ La resolución del nombre de host falla. Compruebe la configuración de DNS de la VPC, las zonas alojadas privadas y las reglas de resolución de Route 53.
+ No hay suficientes direcciones IP en la subred. Amplíe la subred o utilice una subred dedicada. Consulte [Requisitos previos](vpc-egress.md#vpc-egress-prereqs).
+ Faltan los permisos del rol vinculado al servicio. Vuelva a crear el rol vinculado al servicio o adjunte la política actualizada. Consulte [Uso de roles vinculados a servicios para Amazon Service OpenSearch](slr.md).

## Clúster en estado de solo lectura
<a name="troubleshooting-read-only-cluster"></a>

En comparación con las versiones anteriores de Elasticsearch y Elasticsearch 7. OpenSearch *x * utilizan un sistema diferente para la coordinación de clústeres. En este nuevo sistema, cuando el clúster pierde quórum, el clúster no estará disponible hasta que realice alguna acción. La pérdida de quórum puede adoptar dos formas:
+ Si el clúster utiliza nodos principales dedicados, la pérdida de cuórum se produce cuando la mitad o más no están disponibles.
+ Si el clúster no utiliza nodos principales dedicados, la pérdida de cuórum se produce cuando la mitad o más de los nodos de datos no están disponibles.

Si se pierde el quórum y el clúster tiene más de un nodo, el OpenSearch servicio restaura el quórum y coloca el clúster en un estado de solo lectura. Tiene dos opciones:
+ Elimine el estado de solo lectura y utilice el clúster tal y como está.
+ [Restaure el clúster o los índices individuales a partir de una instantánea](managedomains-snapshot-restore.md).

Si prefiere utilizar el clúster tal y como está, verifique que el estado del clúster sea verde mediante la siguiente solicitud:

```
GET _cat/health?v
```

Si el estado del clúster es rojo, le recomendamos que restaure el clúster a partir de una instantánea. También puede consultar [Estado rojo del clúster](#handling-errors-red-cluster-status) para ver los pasos de solución de problemas. Si el estado del clúster es verde, compruebe que todos los índices esperados estén presentes utilizando la siguiente solicitud:

```
GET _cat/indices?v
```

A continuación, ejecute algunas búsquedas para verificar que los datos esperados están presentes. Si es, puede eliminar el estado de solo lectura utilizando la siguiente solicitud:

```
PUT _cluster/settings
{
  "persistent": {
    "cluster.blocks.read_only": false
  }
}
```

Si se pierde el quórum y el clúster solo tiene un nodo, el OpenSearch servicio reemplaza el nodo y * no lo * coloca en un estado de solo lectura. De lo contrario, las opciones son las mismas: utilice el clúster tal y como está o restaure a partir de una instantánea.

En ambas situaciones, el OpenSearch servicio le envía dos eventos. [Panel de estado](https://phd.aws.amazon.com/phd/home#/) El primero le informa de la pérdida de cuórum. El segundo ocurre después de que el OpenSearch Servicio restablezca correctamente el quórum. Para obtener más información sobre el uso del Panel de estado, consulte la Guía [ del ](https://docs.aws.amazon.com/health/latest/ug/)AWS Health usuario.

## Estado rojo del clúster
<a name="handling-errors-red-cluster-status"></a>

Un estado de clúster rojo significa que al menos un fragmento principal y sus réplicas no están asignados a un nodo. OpenSearch El servicio sigue intentando tomar instantáneas automatizadas de todos los índices, independientemente de su estado, pero las instantáneas fallan mientras persiste el estado del clúster en rojo.

Las causas más comunes de un estado rojo del clúster son que los [nodos del clúster han fallado](#handling-errors-failed-cluster-nodes) y que el proceso OpenSearch se ha bloqueado debido a una carga de procesamiento elevada continua.

**nota**  
OpenSearch El servicio almacena las instantáneas automatizadas durante 14 días, independientemente del estado del clúster. Por lo tanto, si el estado del clúster rojo persiste durante más de dos semanas, se eliminará la última instantánea automatizada correcta y podría perder permanentemente los datos del clúster. Si su dominio de OpenSearch servicio pasa a tener un estado de clúster rojo, Soporte puede ponerse en contacto con usted para preguntarle si quiere solucionar el problema usted mismo o si desea que el equipo de soporte le ayude. Puedes [ configurar una CloudWatch alarma ](cloudwatch-alarms.md) para que te notifique cuando aparezca el estado de un clúster rojo.

En última instancia, las particiones rojas causan clústeres rojos y los índices rojos causan particiones rojas. OpenSearch Cuenta con algunas API útiles para identificar los índices que causan el estado del clúster en rojo.
+ `GET /_cluster/allocation/explain` elige la primera partición no asignada que encuentra y explica por qué no se puede asignar a un nodo:

  ```
  {
      "index": "test4",
      "shard": 0,
      "primary": true,
      "current_state": "unassigned",
      "can_allocate": "no",
      "allocate_explanation": "cannot allocate because allocation is not permitted to any of the nodes"
  }
  ```
+ `GET /_cat/indices?v` muestra el estado, el número de documentos y el uso de disco de cada índice:

  ```
  health status index            uuid                   pri rep docs.count docs.deleted store.size pri.store.size
  green  open   test1            30h1EiMvS5uAFr2t5CEVoQ   5   0        820            0       14mb           14mb
  green  open   test2            sdIxs_WDT56afFGu5KPbFQ   1   0          0            0       233b           233b
  green  open   test3            GGRZp_TBRZuSaZpAGk2pmw   1   1          2            0     14.7kb          7.3kb
  red    open   test4            BJxfAErbTtu5HBjIXJV_7A   1   0
  green  open   test5            _8C6MIXOSxCqVYicH3jsEA   1   0          7            0     24.3kb         24.3kb
  ```

Eliminar los índices rojos es la forma más rápida de solucionar el estado rojo del clúster. Según el motivo del estado del clúster en rojo, puedes escalar tu dominio de OpenSearch servicio para usar tipos de instancias más grandes, más instancias o más EBS-based almacenamiento e intentar recrear los índices problemáticos.

Si eliminar un índice problemático no es factible, puede [restaurar una instantánea](managedomains-snapshot-restore.md), eliminar documentos del índice, cambiar la configuración del índice, reducir el número de réplicas o eliminar otros índices para liberar espacio en el disco. El paso importante es resolver el estado del clúster en rojo * antes de * reconfigurar el dominio de servicio. OpenSearch Volver a configurar un dominio con un estado rojo del clúster puede agravar el problema y el dominio podría quedarse bloqueado en el estado de configuración **Processing (Procesando)** hasta que se resuelva el estado.

### Corrección automática de clústeres en rojo
<a name="handling-errors-red-cluster-status-auto-recovery"></a>

Si el estado del clúster permanece en rojo de forma continua durante más de una hora, el OpenSearch servicio intentará corregirlo automáticamente redirigiendo los fragmentos no asignados o restaurándolos a partir de instantáneas anteriores.

Si no corrige uno o más índices rojos y el estado del clúster permanece en rojo durante un total de 14 días, el OpenSearch Servicio solo tomará medidas adicionales si el clúster cumple al * menos uno * de los siguientes criterios:
+ Tiene solo una zona de disponibilidad
+ No tiene nodos maestros dedicados
+ Contiene tipos de instancias de ráfaga (T2 o T3)

En este momento, si tu clúster cumple uno de estos criterios, OpenSearch Service te enviará [ notificaciones diarias ](managedomains-notifications.md) durante los próximos 7 días en las que te explicará que, si no corriges estos índices, se eliminarán todos los fragmentos no asignados. Si el estado del clúster sigue en rojo después de 21 días, el OpenSearch servicio elimina los fragmentos no asignados (almacenamiento y procesamiento) de todos los índices rojos. Recibirás notificaciones en el ** panel de ** notificaciones de la consola de OpenSearch servicio para cada uno de estos eventos. Para obtener más información, consulte [Eventos del estado del clúster](monitoring-events.md#monitoring-events-cluster-health).

### Recuperación de una carga de procesamiento elevada continua
<a name="handling-errors-red-cluster-status-heavy-processing-load"></a>

Para determinar si el estado rojo de un clúster se debe a una carga de procesamiento elevada continua en un nodo de datos, monitorice las siguientes métricas de clúster.


| Métrica relevante | Description (Descripción) | Recuperación | 
| --- | --- | --- | 
| JVMMemoryPressure | Especifica el porcentaje del montón de Java que se emplea para todos los nodos de datos de un clúster. Vea la estadística **Máximo** de esta métrica y busque caídas cada vez más pequeñas en la presión de memoria a medida que el recolector de elementos no utilizados de Java no consigue reclamar suficiente memoria. Probablemente, este patrón se deba a consultas complejas o a campos de datos de gran tamaño.<br />Los tipos de instancias x86 utilizan el recolector de basura Concurrent Mark Sweep (CMS), que se ejecuta junto a subprocesos de aplicaciones para que las pausas sigan siendo breves. Si CMS no puede obtener memoria suficiente durante sus recolecciones normales, desencadena una recolección de basura completa, lo que puede provocar pausas prolongadas de las aplicaciones y afectar a la estabilidad del clúster.<br />ARM-based Los tipos de instancia de Graviton utilizan el recolector de basura Garbage-First (G1), que es similar al CMS, pero usa pausas breves adicionales y desfragmentación por pilas para reducir aún más la necesidad de recolectar basura por completo.<br />En cualquier caso, si el uso de la memoria sigue aumentando más de lo que el recolector de basura puede recuperar durante las recolecciones de basura completas, OpenSearch se bloquea y se produce un error de falta de memoria. En todos los tipos de instancias, una buena regla es mantener el uso por debajo del 80 %.<br />La API `_nodes/stats/jvm` ofrece un resumen útil sobre estadísticas de JVM, el uso del grupo de memoria e información de recopilación de elementos no utilizados:<pre>GET {{domain-endpoint}}/_nodes/stats/jvm?pretty</pre> | Establezca interruptores de memoria para la JVM. Para obtener más información, consulte [JVM OutOfMemoryError](#handling-errors-jvm_out_of_memory_error).<br />Si el problema persiste, elimine los índices innecesarios, reduzca el número o la complejidad de las solicitudes al dominio, agregue instancias o utilice tipos de instancia más grandes. | 
| CPUUtilization | Especifica el porcentaje de recursos de CPU usados para los nodos de datos de un clúster. Consulte la estadística Máximo para esta métrica y busque un patrón continuo de uso elevado. | Agregue nodos de datos o aumente el tamaño de los tipos de instancia de los nodos de datos existentes. | 
| Nodos | Especifica el número de nodos de un clúster. Vea la estadística Mínimo para esta métrica. Este valor fluctúa cuando el servicio implementa una nueva flota de instancias para un clúster. | Agregue nodos de datos. | 

## Estado amarillo del clúster
<a name="handling-errors-yellow-cluster-status"></a>

El estado de clúster de color amarillo significa que los fragmentos principales de todos los índices están asignados a los nodos de un clúster, pero los fragmentos de réplica de al menos un índice no lo están. Single-nodelos clústeres siempre se inicializan con un estado amarillo porque no hay ningún otro nodo al que OpenSearch Service pueda asignar una réplica. Para conseguir el estado verde del clúster, aumente el número de nodos. Para obtener más información, consulte [Dimensionamiento de los dominios de Amazon Service OpenSearch](sizing-domains.md).

Multi-node los clústeres pueden tener un estado amarillo durante un breve período de tiempo después de crear un nuevo índice o después de un error en un nodo. Este estado se resuelve automáticamente a medida que se OpenSearch replican los datos en todo el clúster. La [falta de espacio en disco](#handling-errors-watermark) también puede causar el estado de clúster amarillo; el clúster sólo puede distribuir fragmentos de réplica si los nodos tienen espacio en disco para acomodarlos.

## ClusterBlockException
<a name="troubleshooting-cluster-block"></a>

Puede que reciba un error `ClusterBlockException` por los siguientes motivos.

### Falta de espacio de almacenamiento disponible
<a name="handling-errors-watermark"></a>

Si uno o más nodos del clúster tienen un espacio de almacenamiento inferior al valor mínimo de 1) el 20% del espacio de almacenamiento disponible o 2) 20 GiB de espacio de almacenamiento, las operaciones básicas de escritura, como agregar documentos y crear índices, pueden empezar a fallar. [Cálculo de requisitos de almacenamiento](bp-storage.md)proporciona un resumen de cómo el OpenSearch servicio utiliza el espacio en disco.

Para evitar problemas, supervise la `FreeStorageSpace` métrica en la consola de OpenSearch servicio y [ cree CloudWatch alarmas ](cloudwatch-alarms.md) para que se activen cuando se `FreeStorageSpace` caiga por debajo de un determinado umbral. `GET /_cat/allocation?v`también proporciona un resumen útil sobre la asignación de particiones y el uso del disco. Para resolver los problemas relacionados con la falta de espacio de almacenamiento, escale su dominio de OpenSearch servicio para usar tipos de instancias más grandes, más instancias o más EBS-based almacenamiento.

### Presión alta de memoria de JVM
<a name="handling-errors-block-disks"></a>

Cuando la ** JVMMemoryPressure ** métrica supera el 92% durante 30 minutos, el OpenSearch servicio activa un mecanismo de protección y bloquea todas las operaciones de escritura para evitar que el clúster pase al estado rojo. Cuando la protección está activada, se produce un error `ClusterBlockException` en las operaciones de escritura, los nuevos índices no se pueden crear y se genera el error `IndexCreateBlockException`.

Cuando la ** JVMMemoryPressure ** métrica vuelve al 88% o menos durante cinco minutos, la protección se desactiva y las operaciones de escritura en el clúster se desbloquean.

La presión alta de memoria de JVM puede deberse a picos en el número de solicitudes al clúster, asignaciones de particiones desequilibradas en los nodos, demasiadas particiones en un clúster, explosiones de mapeo de índices o datos de campo, o tipos de instancias que no pueden gestionar las cargas entrantes. También puede deberse al uso de agregaciones, comodines o intervalos de tiempo amplios en las consultas.

Para reducir el tráfico al clúster y resolver problemas de presión alta de memoria de JVM, pruebe una o más de las siguientes acciones:
+ Escale el dominio para que el tamaño máximo de la pila por nodo sea de 32 GB.
+ Reduzca el número de particiones mediante la eliminación de los índices antiguos o no utilizados.
+ Borre la memoria caché de datos con la Operación de la API de `POST {{index-name}}/_cache/clear?fielddata=true`. Tenga en cuenta que borrar la memoria caché puede interrumpir las consultas en curso.

En general, para evitar una presión alta de memoria de JVM en el futuro, siga estas prácticas recomendadas:
+ Evite la agregación en los campos de texto o cambie el [tipo de mapeo](https://opensearch.org/docs/latest/opensearch/mappings/#dynamic-mapping) para sus índices `keyword`.
+ Optimice las solicitudes de búsqueda e indexación mediante la [selección del número correcto de particiones](bp-sharding.md).
+ Configure políticas de Index State Management (ISM) para[eliminar los índices que no se utilizan](bp.md#bp-stability-remove) periódicamente.

## Error al migrar a modo de espera Multi-AZ
<a name="troubleshooting-multi-az-standby"></a>

Al migrar un dominio existente a un dominio en espera, pueden producirse los Multi-AZ siguientes problemas.

### Creación de un índice, una plantilla de índice o una política de ISM durante la migración de dominios sin modo de espera a dominios con modo de espera
<a name="index"></a>

Si creas un índice mientras migras un dominio de un dominio Multi-AZ sin modo de espera a uno en modo de espera y la plantilla de índice o la política de ISM no siguen las directrices de copia de datos recomendadas, esto puede provocar una incoherencia en los datos y la migración puede fallar. Para evitar esta situación, cree el nuevo índice con un recuento de copias de datos (incluidos los nodos principales y las réplicas) que sea múltiplo de tres. Puede comprobar el progreso de la migración mediante la API de `DescribeDomainChangeProgress`. Si encuentra un error en el recuento de réplicas, corrija el error y, a continuación, póngase en contacto con [Soporte de AWS](https://aws.amazon.com/premiumsupport/) para volver a intentar la migración.

### Número incorrecto de copias de datos
<a name="data-copy"></a>

Si no tienes el número correcto de copias de datos en tu dominio, la migración a la versión en espera Multi-AZ fallará.

## JVM OutOfMemoryError
<a name="handling-errors-jvm_out_of_memory_error"></a>

`OutOfMemoryError` de una JVM significa normalmente que se ha alcanzado uno de los siguientes interruptores de la JVM.


| Interruptor | Description (Descripción) | Propiedad de configuración del clúster | 
| --- | --- | --- | 
| Interruptor principal | Porcentaje total de memoria del montón de la JVM permitido para todos los interruptores. El valor predeterminado es 95 %. | indices.breaker.total.limit | 
| Interruptor de datos de campo | Porcentaje de memoria del montón de la JVM permitido para cargar en memoria un único campo de datos. El valor predeterminado es 40 %. Si carga datos con campos de gran tamaño, probablemente deba aumentar este límite. | indices.breaker.fielddata.limit | 
| Interruptor de solicitud | Porcentaje de memoria del montón de la JVM permitido para las estructuras de datos que se usan para responder a una solicitud de servicio. El valor predeterminado es 60 %. Si sus solicitudes de servicio implican el cálculo de agregaciones, es posible que deba aumentar este límite. | indices.breaker.request.limit | 

## Nodos de clúster defectuosos
<a name="handling-errors-failed-cluster-nodes"></a>

Las instancias de Amazon EC2 pueden experimentar terminaciones y reinicios inesperados. Normalmente, el OpenSearch servicio reinicia los nodos automáticamente. Sin embargo, es posible que uno o varios nodos de un clúster de OpenSearch permanezcan en una condición de error.

Para comprobar esta condición, abre el panel de control de tu dominio en la consola OpenSearch de servicio. Vaya a la pestaña **Estado del clúster** y busque la métrica **Nodos totales**. Compruebe si el número de nodos que aparece es menor que el número que configuró para el clúster. Si la métrica indica que uno o varios nodos no funcionan durante más de un día, contacte con [AWS Support](https://aws.amazon.com/premiumsupport/).

También puedes [ configurar una CloudWatch alarma ](cloudwatch-alarms.md) para que te notifique cuando se produzca este problema.

**nota**  
La métrica **Nodos totales** no es precisa durante los cambios en la configuración del clúster y durante el mantenimiento rutinario del servicio. Este es el comportamiento esperado. La métrica informará en breve del número correcto de nodos del clúster. Para obtener más información, consulte [Realizar cambios de configuración en Amazon Service OpenSearch](managedomains-configuration-changes.md).

Para proteger los clústeres de los reinicios y terminaciones inesperadas de los nodos, crea al menos una réplica para cada índice de tu dominio de OpenSearch servicio.

## Límite máximo de fragmentos superado
<a name="troubleshooting-shard-limit"></a>

OpenSearch así como 7. **Las versiones x de Elasticsearch tienen una configuración predeterminada de no más de 1000 fragmentos por nodo. OpenSearch/Elasticsearcharroja un error si una solicitud, como la creación de un nuevo índice, hace que supere este límite. Si detecta este error, dispone de varias opciones:
+ Agregue más nodos de datos al clúster.
+ Aumente la configuración `_cluster/settings/cluster.max_shards_per_node`.
+ Utilice la [API \_shrink](supported-operations.md#version_api_notes-shrink) para reducir el número de particiones en el nodo.

## Dominio atascado en estado de procesamiento
<a name="stuck-in-processing"></a>

Su dominio de OpenSearch servicio pasa al estado de «Procesamiento» cuando se encuentra en medio de un cambio de [ configuración](managedomains-configuration-changes.md). Cuando inicias un cambio de configuración, el estado del dominio cambia a «En procesamiento» mientras el OpenSearch Servicio crea un nuevo entorno. En el nuevo entorno, el OpenSearch Servicio lanza un nuevo conjunto de nodos aplicables (como los de datos, los nodos maestros o UltraWarm). Una vez que finaliza la migración, se terminan los nodos más antiguos.

El clúster puede quedarse atascado en el estado “Processing” (Procesando) si se produce una de estas situaciones:
+ No se lanza un nuevo conjunto de nodos de datos.
+ La migración de particiones al nuevo conjunto de nodos de datos no se realiza correctamente.
+ La comprobación de validación ha fallado con errores.

Para ver los pasos detallados para resolver cada una de estas situaciones, consulta [ ¿Por qué mi dominio de Amazon OpenSearch Service permanece en estado de «Procesamiento»? ](https://aws.amazon.com/premiumsupport/knowledge-center/opensearch-domain-stuck-processing/). 

## Bajo balance de ráfaga EBS
<a name="handling-errors-low-ebs-burst"></a>

OpenSearch El servicio le envía una notificación de consola cuando el saldo de ráfagas de EBS de uno de sus volúmenes de uso general (SSD) es inferior al 70%, y una notificación de seguimiento si el saldo cae por debajo del 20%. Para solucionar este problema, puede escalar verticalmente el clúster o reducir las IOPS de lectura y escritura para que se pueda acreditar el balance de ráfaga. El balance de ráfagas se mantiene en 0 para los dominios con tipos de volúmenes gp3, así como para los dominios con volúmenes gp2 que tengan un tamaño de volumen superior a 1000 GiB. Para obtener más información, consulte [Volúmenes de SSD de uso general (gp2)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html#EBSVolumeTypes_gp2). Puede supervisar el balance de ráfagas de EBS con la `BurstBalance` CloudWatch métrica.

## La métrica de EBS aumenta durante el redimensionamiento del volumen
<a name="troubleshooting-ebs-volume-update-spikes"></a>

Al modificar los tamaños de volumen de Amazon Elastic Block Store, es posible que observe aumentos temporales en varias métricas de EBS como `Write Throughput`, `Write Throughput Micro bursting`, `Disk Queue Depth` y `IOPS`. Este es el comportamiento esperado durante la operación de cambio de tamaño y, por lo general, dura unos segundos. Sin embargo, la duración puede variar en función del tamaño del volumen que se modifique.

Para evitar problemas de latencia y rechazos de solicitudes, realice cambios de tamaño del volumen de EBS solo cuando el clúster esté en buen estado y el tráfico de red sea bajo.

## No se pueden habilitar los registros de auditoría
<a name="troubleshooting-audit-logs-error"></a>

Es posible que aparezca el siguiente error al intentar habilitar la publicación del registro de auditoría mediante la consola de OpenSearch servicio:

La política de acceso a los recursos especificada para el grupo de CloudWatch registros no otorga permisos suficientes para que Amazon OpenSearch Service cree una secuencia de registros. Compruebe la política de acceso a recursos.

Si detecta este error, compruebe que el `resource`elemento de su política incluye el ARN del grupo de registro correcto. Si lo hace, siga estos pasos:

1. Espere varios minutos.

1. Actualice la página en el navegador web.

1. Seleccione **Seleccionar grupo existente**.

1. Para **Grupo de registros existente**, seleccione el grupo de registro que ha creado antes de recibir el mensaje de error.

1. En la sección de políticas de acceso, seleccione **Seleccionar política existente**.

1. Para **Política existente**, elija la política que ha creado antes de recibir el mensaje de error.

1. Seleccione **Habilitar**.

Si el error persiste después de repetir el proceso varias veces, póngase en contacto con el servicio de [Soporte de AWS](https://aws.amazon.com/premiumsupport/).

## No se puede cerrar el índice
<a name="troubleshooting-close-api"></a>

OpenSearch El servicio solo admite la [`_close`](https://opensearch.org/docs/latest/api-reference/index-apis/close-index/) API para las versiones 7.4 OpenSearch y posteriores de Elasticsearch. Si está usando una versión anterior está restaurando un índice desde una instantánea, puede eliminar el índice existente (antes o después de volver a indexarlo).

## Verificaciones de licencias del cliente
<a name="troubleshooting-license"></a>

Las distribuciones predeterminadas de Logstash y Beats incluyen una comprobación de la licencia exclusiva y no se conectan a la versión de código abierto de. OpenSearch Asegúrese de usar las distribuciones Apache 2.0 (OSS) de estos clientes con Service. OpenSearch 

## Limitación controlada de solicitudes
<a name="troubleshooting-throttle-api"></a>

Si recibe errores persistentes de `403 Request throttled due to too many requests` o `429 Too Many Requests`, considere la posibilidad de escalar verticalmente. Amazon OpenSearch Service limita las solicitudes si la carga útil hace que el uso de la memoria supere el tamaño máximo del montón de Java.

## No se puede usar SSH en nodo
<a name="troubleshooting-ssh"></a>

No puedes usar SSH para acceder a ninguno de los nodos de tu OpenSearch clúster y no puedes modificarlos directamente. `opensearch.yml` En su lugar, usa la consola o los SDK para configurar tu dominio. AWS CLI Puede especificar unos ajustes en el nivel de clúster mediante las API de REST de OpenSearch. Para obtener más información, consulta la referencia de la API OpenSearch de [ Amazon Service ](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/Welcome.html) y[Operaciones compatibles en Amazon Service OpenSearch](supported-operations.md).

Si necesita más información sobre el rendimiento del clúster, puede [publicar los registros de errores y los registros lentos en CloudWatch](createdomain-configure-slow-logs.md).

## Error de instantánea "No válido para la clase de almacenamiento del objeto"
<a name="troubleshooting-glacier-snapshots"></a>

OpenSearch Las instantáneas del servicio no admiten la clase de almacenamiento de Amazon Glacier. Es posible que aparezca este error al intentar mostrar las instantáneas si el bucket de S3 incluye una regla de ciclo de vida que traslada los objetos a la clase de almacenamiento de Amazon Glacier.

Si tiene que restaurar una instantánea desde el bucket, restaure los objetos de Amazon Glacier, copie los objetos a un nuevo bucket y [registre el nuevo bucket](managedomains-snapshot-registerdirectory.md) como repositorio de instantáneas.

## Encabezado de host no válido
<a name="troubleshooting-host-header"></a>

OpenSearch El servicio requiere que los clientes lo especifiquen `Host` en los encabezados de la solicitud. Un valor de `Host` válido es el punto de conexión del dominio sin `https://`, como:

```
Host: search-my-sample-domain-ih2lhn2ew2scurji.us-west-2.es.amazonaws.com
```

Si recibe un `Invalid Host Header` error al realizar una solicitud, compruebe que su cliente o proxy incluya el punto final del dominio del OpenSearch servicio (y no, por ejemplo, su dirección IP) en el `Host` encabezado.

## Tipo de instancia M3 no válido
<a name="m3-instance-types"></a>

OpenSearch El servicio no admite agregar o modificar instancias M3 en dominios existentes que ejecuten OpenSearch la versión 6.7 y posteriores de Elasticsearch. Puede seguir utilizando instancias M3 con Elasticsearch 6.5 y versiones anteriores.

Recomendamos elegir un tipo de instancia más reciente. En el caso de los dominios que ejecutan OpenSearch Elasticsearch 6.7 o una versión posterior, se aplica la siguiente restricción:
+ Si el dominio existente no utiliza instancias M3, ya no podrá cambiar a ellas.
+ Si cambia un dominio existente de un tipo de instancia M3 a otro tipo de instancia, no puede volver a cambiar.

## Las consultas rápidas dejan de funcionar después de habilitarlas UltraWarm
<a name="troubleshooting-uw"></a>

Cuando las habilitas UltraWarm en un dominio, si no hay ninguna anulación preexistente en la `search.max_buckets` configuración, OpenSearch Service establece automáticamente el valor `10000` para evitar que las consultas que consumen mucha memoria saturen los nodos activos. Si las consultas rápidas utilizan más de 10 000 cubos, es posible que dejen de funcionar cuando las habilites. UltraWarm 

Como no puedes modificar esta configuración debido a la naturaleza gestionada de Amazon OpenSearch Service, tienes que abrir un caso de soporte para aumentar el límite. Los aumentos de límite no requieren una suscripción de premium support.

## No se puede cambiar a una versión anterior después de una actualización
<a name="troubleshooting-upgrade-snapshot"></a>

[In-place las actualizaciones ](version-migration.md) son irreversibles, pero si te pones en contacto con el equipo de [AWS soporte](https://aws.amazon.com/premiumsupport/), pueden ayudarte a restaurar la instantánea automática previa a la actualización en un dominio nuevo. Por ejemplo, si actualizas un dominio de Elasticsearch 5.6 a 6.4, AWS Support puede ayudarte a restaurar la instantánea anterior a la actualización en un nuevo dominio de Elasticsearch 5.6. Si ha realizado una instantánea manual del dominio original, puede [realizar ese paso usted mismo](managedomains-snapshots.md).

## ¿Necesitas un resumen de los dominios para todos Regiones de AWS
<a name="troubleshooting-domain-summary"></a>

El siguiente script usa el [AWS CLI comando ](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-regions.html) describe-regions de Amazon EC2 para crear una lista de todas las regiones en las que el OpenSearch servicio podría estar disponible. A continuación, llama a [list-domain-names](https://docs.aws.amazon.com/cli/latest/reference/es/list-domain-names.html) para cada región:

```
for region in `aws ec2 describe-regions --output text | cut -f4`
do
    echo "\nListing domains in region '$region':"
    aws opensearch list-domain-names --region $region --query 'DomainNames'
done
```

Recibe el siguiente resultado para cada región:

```
Listing domains in region:'us-west-2'...
[
  {
    "DomainName": "sample-domain"
  }
]
```

Las regiones en las que el OpenSearch servicio no está disponible muestran el mensaje «No se pudo conectar a la URL del punto de enlace».

## Error del navegador al usar los OpenSearch paneles
<a name="troubleshooting-dashboards-debug-browser-errors"></a>

Su navegador agrupa los mensajes de error del servicio en objetos de respuesta HTTP cuando utiliza los paneles para ver los datos de su OpenSearch dominio de servicio. Puede usar las herramientas para desarrolladores que suele haber disponibles en los navegadores web, como el Modo desarrollador de Chrome, para ver los errores de servicio subyacentes y como ayuda en las tareas de depuración.

**Para ver errores de servicio en Chrome**

1. Desde la barra del menú superior de Chrome, seleccione **Ver**, **Desarrollador**, **Herramientas de desarrollador**.

1. Seleccione la pestaña **Red**.

1. En la columna **Estado**, seleccione cualquier sesión HTTP que tenga un estado de 500.

**Para ver errores de servicio en Firefox**

1. Desde el menú, seleccione **Herramientas**, **Desarrollador de web**, **Red**.

1. Seleccione cualquier sesión HTTP que tenga un estado de 500.

1. Seleccione la pestaña **Respuesta** para ver la respuesta de servicio.

## Partición de nodos y sesgo de almacenamiento
<a name="handling-errors-node-skew"></a>

El *sesgo de partición* de nodo es cuando uno o más nodos de un clúster tienen significativamente más particiones que los demás nodos. El *sesgo de almacenamiento* de nodo es cuando uno o más nodos de un clúster tienen mucho más almacenamiento (`disk.indices`) que los demás nodos. Si bien estas dos condiciones pueden ocurrir temporalmente, por ejemplo, cuando un dominio ha reemplazado un nodo y todavía le está asignando particiones, debe abordarlas si persisten.

Para identificar ambos tipos de sesgo, ejecuta la operación de la [ \_cat/allocation ](https://opensearch.org/docs/latest/opensearch/rest-api/cat/cat-allocation/) API y compara las `disk.indices` entradas `shards` y de la respuesta:

```
 shards    | disk.indices  | disk.used  | disk.avail   | disk.total   | disk.percent |  host     | ip       | node
    {{264}}    |      {{465.3mb}}  |   {{229.9mb}}  |      {{1.4tb}}   |      {{1.5tb}}   |            {{0}} |  {{x.x.x.x}}  | {{x.x.x.x}}  | {{node1}}
    115    |        7.9mb  |    83.7mb  |     49.1gb   |     49.2gb   |            0 |  x.x.x.x  | x.x.x.x  | node2
    {{264}}    |      {{465.3mb}}  |   {{235.3mb}}  |      {{1.4tb}}   |      {{1.5tb}}   |            {{0}} |  {{x.x.x.x}}  | {{x.x.x.x}}  | {{node3}}
    116    |        7.9mb  |    82.8mb  |     49.1gb   |     49.2gb   |            0 |  x.x.x.x  | x.x.x.x  | node4
    115    |        8.4mb  |      85mb  |     49.1gb   |     49.2gb   |            0 |  x.x.x.x  | x.x.x.x  | node5
```

Si bien es normal que haya algún sesgo de almacenamiento, cualquier valor por encima del 10 % del promedio es significativo. Cuando la distribución de las particiones está sesgada, el uso de la CPU, la red y el ancho de banda del disco también puede verse sesgado. Debido a que una mayor cantidad de datos generalmente implica más operaciones de indexación y búsqueda, los nodos más pesados también tienden a ser los nodos con mayor carga de recursos, mientras que los nodos más livianos representan una capacidad infrautilizada.

**Corrección**: utilice recuentos de particiones que sean múltiplos del recuento de nodos de datos para garantizar que cada índice se distribuya de manera uniforme entre los nodos de datos.

## Partición del índice y el sesgo de almacenamiento
<a name="handling-errors-index-skew"></a>

El *sesgo de partición* del índice es cuando uno o más nodos contienen más particiones de un índice que los otros nodos. El *sesgo de almacenamiento* de índice es cuando uno o más nodos contienen una cantidad desproporcionadamente grande del almacenamiento total de un índice.

El sesgo de índice es más difícil de identificar que el sesgo de nodos porque requiere cierta manipulación del resultado de la [ \_cat/shards ](https://opensearch.org/docs/latest/opensearch/rest-api/cat/cat-shards/) API. Investigue el sesgo del índice si hay algún indicio de sesgo en las métricas de clúster o nodo. A continuación, se indican algunos indicios comunes del sesgo de índice:
+ Errores HTTP 429 que se producen en un subconjunto de nodos de datos
+ Colocación en cola de operaciones de búsqueda o índice desigual en los nodos de datos
+ Utilización desigual de la and/or CPU en pilas de JVM entre los nodos de datos

**Corrección**: utilice recuentos de particiones que sean múltiplos del recuento de nodos de datos para garantizar que cada índice se distribuya de manera uniforme entre los nodos de datos. Si sigue viendo que el almacenamiento de índices o los fragmentos están sesgados, es posible que deba forzar una reasignación de fragmentos, lo que ocurre con cada [ blue/green implementación de su dominio de servicio. ](managedomains-configuration-changes.md) OpenSearch 

## Operación no autorizada tras seleccionar acceso a la VPC
<a name="vpc-permissions"></a>

Al crear un dominio nuevo mediante la consola de OpenSearch servicio, tiene la opción de seleccionar VPC o acceso público. Si seleccionas el acceso a la ** VPC**, el OpenSearch servicio consulta la información de la VPC y produce un error si no tienes los permisos adecuados:

```
You are not authorized to perform this operation. (Service: AmazonEC2; Status Code: 403; Error Code: UnauthorizedOperation
```

Para poder realizar esta consulta, debe tener acceso a las operaciones `ec2:DescribeVpcs`, `ec2:DescribeSubnets` y `ec2:DescribeSecurityGroups`. Este requisito solo es para la consola. Si usas la AWS CLI para crear y configurar un dominio con un punto final de la VPC, no necesitas acceder a esas operaciones.

## Bloqueo al cargar después de crear el dominio de la VPC
<a name="vpc-sts"></a>

Después de crear un dominio que utiliza el acceso a la VPC, es posible que la operación **Configuration state (estado de configuración)** del dominio no pase del estado **Loading (Cargando)**. Si se produce este problema, es probable que tengas AWS Security Token Service (AWS STS) * deshabilitado * () en tu región.

Para añadir puntos de enlace de la VPC a su VPC, el OpenSearch servicio debe asumir la función. `AWSServiceRoleForAmazonOpenSearchService` Por lo tanto, AWS STS debe estar habilitado para crear nuevos dominios que utilicen el acceso a la VPC en una región determinada. Para obtener más información sobre la activación y la desactivación AWS STS, consulte la Guía del usuario de [ IAM. ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html)

## Solicitudes denegadas a la API OpenSearch
<a name="troubleshooting-tbac"></a>

Con la introducción del control de acceso basado en etiquetas para la OpenSearch API, es posible que empieces a recibir errores de acceso denegado donde antes no los tenías. Esto puede deberse a que una o más de sus políticas de acceso contienen `Deny` y utilizan la condición `ResourceTag`, y ahora se están respetando esas condiciones.

Por ejemplo, la política siguiente solo denegaba el acceso a la `CreateDomain` de la API de configuración, si el dominio tenía la etiqueta `environment=production`. Aunque la lista de acciones también incluye `ESHttpPut`, la declaración de denegación no se aplicó a esa acción ni a ninguna otra acción `ESHttp*`.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [{
    "Action": [
      "es:CreateDomain",
      "es:ESHttpPut"
    ],
    "Effect": "Deny",
    "Resource": "*",
    "Condition": {
      "ForAnyValue:StringEquals": {
        "aws:ResourceTag/environment": [
          "production"
        ]
      }
    }
  }]
}
```

------

Con la compatibilidad añadida de etiquetas para los métodos OpenSearch HTTP, una política de IAM basada en la identidad como la anterior provocará que se niegue el acceso a la acción al usuario adjunto. `ESHttpPut` Anteriormente, en ausencia de validación de etiquetas, el usuario adjunto habría podido enviar solicitudes PUT.

Si empieza a ver errores de acceso denegado después de actualizar sus dominios al software de servicio R20220323 o posterior, compruebe las políticas de acceso basadas en identidad para ver si es así y actualícelas si es necesario para permitir el acceso.

## No se puede conectar desde Alpine Linux
<a name="troubleshooting-alpine"></a>

Alpine Linux limita el tamaño de respuesta de DNS a 512 bytes. Si intentas conectarte a tu dominio de OpenSearch servicio desde la versión 3.18.0 o una versión anterior de Alpine Linux, la resolución de DNS puede fallar si el dominio está en una VPC y tiene más de 20 nodos. Si utiliza una versión de Alpine Linux superior a la 3.18.0, debería poder resolver más de 20 hosts. Para obtener más información, consulte las [notas de la versión de Alpine Linux 3.18.0](https://alpinelinux.org/posts/Alpine-3.18.0-released.html).

Si su dominio está en una VPC, le recomendamos que utilice otras distribuciones de Linux, como Debian, Ubuntu, CentOS, Red Hat Enterprise Linux o Amazon Linux 2, para conectarse a él.

## Hay demasiadas solicitudes de Search Backpressure
<a name="troubleshooting-search-backpressure"></a>

CPU-based El control de admisión es un mecanismo de control que limita de forma proactiva el número de solicitudes a un nodo en función de su capacidad actual, tanto para los aumentos orgánicos como para los picos de tráfico. Las solicitudes excesivas devuelven un código de estado HTTP 429 “Demasiadas solicitudes” en caso de rechazo. Este error indica que los recursos del clúster son insuficientes, que las solicitudes de búsqueda consumen muchos recursos o que se ha producido un aumento imprevisto de la carga de trabajo.

Search Backpressure proporciona el motivo del rechazo, lo que puede ayudar a ajustar las solicitudes de búsqueda que consumen muchos recursos. En caso de picos de tráfico, recomendamos volver a intentarlo desde el lado del cliente, con un retroceso y una fluctuación exponenciales.

## Error de certificado cuando se utiliza un SDK
<a name="troubleshooting-certificates"></a>

Como AWS los SDK utilizan los certificados de CA de su ordenador, los cambios en los certificados de los AWS servidores pueden provocar errores de conexión al intentar utilizar un SDK. Los mensajes de error varían, pero suelen contener el siguiente texto:

```
Failed to query OpenSearch
...
SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
```

Puede evitar estos errores manteniendo actualizados los certificados de CA de su equipo y el sistema operativo. Si detecta este problema en un entorno corporativo y no administra su propio equipo, es posible que deba pedir ayuda a un administrador con el proceso de actualización.

La siguiente lista muestra las versiones mínimas necesarias del sistema operativo y Java:
+ Las versiones de Microsoft Windows con actualizaciones instaladas a partir de enero de 2005 o fechas posteriores, contienen al menos uno de los CA necesarios en su lista de confianza.
+ Mac OS X 10.4 con Java para Mac OS X 10.4 Release 5 (febrero de 2007), Mac OS X 10.5 (octubre de 2007) y las versiones posteriores contienen al menos uno de los CA necesarios en su lista de confianza.
+ Red Hat Enterprise Linux 5 (marzo de 2007), 6 y 7 y CentOS 5, 6 y 7 contienen al menos uno de los CA necesarios en su lista de confianza predeterminada.
+ Java 1.4.2\_12 (mayo de 2006), 5 Update 2 (marzo de 2005) y todas las versiones posteriores, incluido Java 6 (diciembre de 2006), 7 y 8, contienen al menos uno de los CA necesarios en su lista de confianza predeterminada.

Las tres entidades de certificación son:
+ Amazon Root CA 1
+ Starfield Services Root Certificate Authority - G2
+ Starfield Class 2 Certification Authority

Los certificados raíz de las primeras dos entidades están disponibles en [Amazon Trust Services](https://www.amazontrust.com/repository/), aunque mantener el equipo actualizado es la solución más sencilla. Para obtener más información sobre ACM-provided los certificados, consulte [AWS Gestor de certificados las preguntas frecuentes. ](https://aws.amazon.com/certificate-manager/faqs/#certificates)

**nota**  
Actualmente, los dominios de OpenSearch servicio de la región us-east-1 utilizan certificados de una autoridad diferente. Tenemos previsto actualizar la región para utilizar estas nuevas entidades de certificación en un futuro próximo.

## La instalación del complemento personalizado falla debido a la compatibilidad de las versiones
<a name="troubleshooting-custom-plugins"></a>

**Problema**: La instalación del complemento falló debido a una falta de coincidencia entre la versión del complemento y la instancia en ejecución. OpenSearch La función devuelve el siguiente error:

```
PluginValidationFailureReason : The provided plugin could not be loaded.
```

**Causa**: el complemento se compiló para OpenSearch ${{{MAJOR}}}. ${{{MINOR}.{PATCH}}}, pero su entorno ejecuta OpenSearch ${{{MAJOR}}}. $ {{{MINOR}}} .0. OpenSearch requiere una coincidencia exacta de versiones entre los complementos y la OpenSearch instalación principal por motivos de estabilidad y seguridad.

**Posible solución**: crea el plugin con la OpenSearch versión ${{{MAJOR}}}. $ {{{MINOR}}} .0 para que coincida con la versión de tu clúster.

**Para verificar y actualizar la versión de OpenSearch**

1. Utilice la API o el panel de control del clúster para ejecutar el siguiente comando. Sustituya {{default placeholder values}} por su propia información.

   **Solicitud de API:**

   ```
   curl -X GET {{your-opensearch-endpoint}}/
   ```

   **Consola de Dev Tools en el panel de control:**

   ```
   GET /
   ```

   El comando devuelve información similar a la siguiente.

   ```
   {
     "name": "{{node-id}}",
     "cluster_name": "{{account-id}}:{{domain-name}}",
     "cluster_uuid": "{{cluster-uuid}}",
     "version": {
       "distribution": "opensearch",
       "number": "2.17.0",
       "build_type": "tar",
       "build_hash": "unknown",
       "build_date": "2024-12-17T11:00:09.799828091Z",
       "build_snapshot": false,
       "lucene_version": "9.11.1",
       "minimum_wire_compatibility_version": "7.10.0",
       "minimum_index_compatibility_version": "7.0.0"
     },
     "tagline": "The OpenSearch Project: https://opensearch.org/"
   }
   ```

1. Si el número de versión no es ${{{MAJOR}}}. $ {{{MINOR}}} .0, reconstruye el plugin haciendo lo siguiente:

   1. Actualiza el plugin `descriptor.properties` para especificar la versión ${{{MAJOR}}}. $ {{{MINOR}}} .0.

   1. Reconstruya el complemento con el comando correspondiente a su tipo de proyecto.

   1. Ejecute el comando [update-package](https://docs.aws.amazon.com/cli/latest/reference/opensearch/update-package.html) con el archivo recién creado `.zip`.

   1. Ejecute el comando [associate-package](https://docs.aws.amazon.com/cli/latest/reference/opensearch/associate-package.html) para asociar la última versión del complemento que se creó al ejecutar el comando `update-package` en el paso anterior.