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
En este tema se describe cómo identificar y resolver problemas comunes de Amazon OpenSearch Service. Consulte la información de esta sección antes de ponerse en contacto con el Soporte de AWS
No se puede acceder a OpenSearch Dashboards
El punto de conexión de OpenSearch Dashboards 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, es posible que aparezca el siguiente error cuando se intente acceder a Dashboards:
"User: anonymous is not authorized to perform: es:ESHttpGet"Si su dominio de OpenSearch Service utiliza el acceso mediante VPC, probablemente no ocurra este error, pero puede que se agote el tiempo de espera. Para obtener más información acerca de cómo solucionar este problema y las distintas opciones de configuración disponibles Controlar el acceso a los paneles , consulte Acerca de las políticas de acceso a VPC los dominios y Identity and Access Management en Amazon OpenSearch Service.
No se puede obtener acceso al dominio de VPC
Consulte Acerca de las políticas de acceso a VPC los dominios y Probar dominios VPC.
Clúster en estado de solo lectura
Comparado con versiones anteriores de Elasticsearch, OpenSearch y Elasticsearch 7.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 produce una pérdida de cuórum y el clúster tiene más de un nodo, OpenSearch Service restaura el cuórum y coloca el clúster en un estado de solo lectura. Dispone de dos opciones para hacerlo:
-
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.
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 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 produce una pérdida de cuórum y el clúster solo tiene un nodo, OpenSearch Service sustituye el nodo y no coloca el clúster 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, OpenSearch Service envía dos eventos a su AWS Health Dashboard
Estado rojo del clúster
El estado rojo del clúster significa que al menos una partición principal y sus réplicas no están asignados a un nodo. OpenSearch Service sigue tratando de tomar instantáneas automatizadas de todos los índices independientemente de su estado, pero las instantáneas fallan mientras el estado del clúster rojo persiste.
Las causas más comunes de un estado rojo del clúster son que los nodos del clúster han fallado y que el proceso de OpenSearch se ha bloqueado debido a una carga de procesamiento elevada continua.
nota
OpenSearch Service almacena 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 el dominio de OpenSearch Service pasa a un estado rojo del clúster, el equipo de AWS Support podría contactar con usted para preguntarle si desea corregir el problema por sí mismo o si prefiere que ellos lo ayuden. También puede definir una alarma de CloudWatch que le notifique cuando se produzca un estado rojo del clúster.
En última instancia, los fragmentos rojos causan clústeres rojos y los índices rojos causan fragmentos rojos. Para identificar los índices que causan el estado rojo del clúster, OpenSearch tiene algunas API útiles.
-
GET /_cluster/allocation/explainelige el primer fragmento no asignado 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?vmuestra 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 rojo del clúster, podría ampliar el dominio de OpenSearch Service para utilizar tipos de instancias de mayor tamaño, más instancias o más almacenamiento basado en EBS e intentar volver a crear los índices problemáticos.
Si eliminar un índice problemático no es factible, puede restaurar una instantánea, 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 más importante es resolver el estado rojo del clúster antes de volver a configurar su dominio de OpenSearch Service. 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
Si el estado del clúster permanece en rojo de manera continuada durante más de una hora, OpenSearch Service intenta corregirlo automáticamente redirigiendo particiones no asignadas o restaurando desde instantáneas anteriores.
Si no consigue corregir uno o varios índices en rojo y el estado del clúster permanece en rojo durante un total de 14 días, OpenSearch Service solo toma 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 el clúster cumple uno de estos criterios, OpenSearch Service envía notificaciones diarias durante los siguientes 7 días en las que explica que, si no se corrigen estos índices, se eliminarán todas las particiones no asignadas. Si el estado del clúster sigue en rojo transcurridos 21 días, OpenSearch Service elimina las particiones no asignadas (almacenamiento y computación) de todos los índices en rojo. Las notificaciones correspondientes a cada uno de estos eventos se reciben en el panel Notificaciones de la consola de OpenSearch Service. Para obtener más información, consulte Eventos del estado del clúster.
Recuperación de una carga de procesamiento elevada continua
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 | 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. 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. Los tipos de instancias Graviton basados en ARM utilizan el recolector de basura Garbage-First (G1), que es similar a CMS, pero utiliza pausas breves adicionales y desfragmentación del montón para reducir aún más la necesidad de recolecciones de basura completas. En cualquier caso, si el uso de memoria continúa creciendo por encima de lo que el recopilador de basura puede obtener durante la recopilación de basura completa, OpenSearch se bloquea con un error de memoria insuficiente. En todos los tipos de instancias, una buena regla es mantener el uso por debajo del 80 %. La API
|
Establezca interruptores de memoria para la JVM. Para obtener más información, consulte OutOfMemoryError de JVM. 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
Un estado amarillo del clúster significa que los fragmentos principales de todos los índices están asignados a nodos de un clúster, pero los fragmentos de réplica de al menos un índice no lo están. Los clústeres de un nodo siempre se inicializan con un estado amarillo, ya que no existe 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 OpenSearch Service.
Los clústeres de varios nodos pueden tener brevemente un estado de clúster amarillo después de crear un nuevo índice o después de un error de nodo. Este estado se resuelve automáticamente a medida que OpenSearch replica datos en todo el clúster. La falta de espacio en disco 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
Puede que reciba un error ClusterBlockException por los siguientes motivos.
Falta de espacio de almacenamiento disponible
Si uno o más nodos de su clúster tienen un espacio de almacenamiento inferior al valor mínimo de 1) 20 % del espacio de almacenamiento disponible, o 2) 20 GiB de espacio de almacenamiento, las operaciones básicas de escritura, como la adición de documentos y la creación de índices, pueden empezar a fallar. Cálculo de requisitos de almacenamiento proporciona un resumen de cómo OpenSearch Service utiliza el espacio en disco.
Para evitar problemas, monitorice la métrica FreeStorageSpace en la consola de OpenSearch Service y crear alarmas de CloudWatch que se activan cuando FreeStorageSpace esté por debajo de un determinado umbral. GET
/_cat/allocation?v también proporciona un resumen útil de la asignación de particiones y el uso del disco. Para solucionar los problemas asociados a una falta de espacio de almacenamiento, amplíe su dominio de OpenSearch Service para utilizar tipos de instancias de mayor tamaño, más instancias o más almacenamiento basado en EBS.
Presión alta de memoria de JVM
Si la métrica JVMMemoryPressure supera el 92 % durante 30 minutos, OpenSearch Service activa un mecanismo de protección y bloquea todas las operaciones de escritura para impedir que el clúster alcance el 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.
Si la métrica JVMMemoryPressure vuelve al 88% o un valor inferior durante cinco minutos, la protección queda deshabilitada 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. Tenga en cuenta que borrar la memoria caché puede interrumpir las consultas en curso.index-name/_cache/clear?fielddata=true
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
para sus índices keyword. -
Optimice las solicitudes de búsqueda e indexación mediante la selección del número correcto de particiones.
-
Configure políticas de Index State Management (ISM) paraeliminar los índices que no se utilizan periódicamente.
Error al migrar a multi-AZ con modo de espera
Se pueden producir los siguientes problemas al migrar un dominio existente a Multi-AZ con modo de espera.
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
Si crea un índice al migrar un dominio de Multi-AZ sin modo de espera a uno con modo de espera, y la plantilla de índice o la política de ISM no siguen las pautas de copia de datos recomendadas, esto puede provocar una incoherencia en los datos y es posible que la migración no se realice correctamente. 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
Número incorrecto de copias de datos
Si no tiene el número correcto de copias de datos en su dominio, la migración a Multi-AZ con modo de espera fallará.
OutOfMemoryError de JVM
OutOfMemoryError de una JVM significa normalmente que se ha alcanzado uno de los siguientes interruptores de la JVM.
| Interruptor | 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
Las instancias de Amazon EC2 pueden experimentar terminaciones y reinicios inesperados. Normalmente, OpenSearch Service 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 si se da esta condición, abra el panel del dominio en la consola de OpenSearch Service. 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
También puede definir una alarma de CloudWatch para recibir un aviso 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 OpenSearch Service.
Para proteger los clústeres frente a terminaciones y reinicios inesperados de los nodos, cree al menos una réplica para cada índice en su dominio de OpenSearch Service.
Límite máximo de fragmentos superado
OpenSearch y las versiones 7.x de Elasticsearch tienen una configuración predeterminada de no más de 1000 fragmentos por nodo. OpenSearch/ElasticSearch genera un error si una solicitud, como crear un nuevo índice, provocara que se supere este límite. Si detecta este error, dispone de varias opciones:
-
Añada más nodos de datos al clúster.
-
Aumente la configuración
_cluster/settings/cluster.max_shards_per_node. -
Utilice la API _shrink para reducir el número de fragmentos en el nodo.
Dominio atascado en estado de procesamiento
El dominio de OpenSearch Service entra en el estado “Processing” (Procesando) cuando se encuentra en medio de un cambio de configuración. Si se inicia un cambio de configuración, el estado del dominio cambia a “Processing” (Procesando) mientras OpenSearch Service crea un nuevo entorno. En el nuevo entorno, OpenSearch Service lanza un nuevo conjunto de nodos aplicables (tales como datos, maestro 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 pasos de resolución detallados para cada una de estas situaciones, consulte Why is my Amazon OpenSearch Service domain stuck in the “Processing” state?
Bajo balance de ráfaga EBS
OpenSearch Service le envía una notificación de consola cuando el balance de ráfaga de EBS en uno de sus volúmenes de uso general (SSD) está por debajo del 70 % y una notificación de seguimiento si el balance 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). Puede monitorizar el balance de ráfagas de EBS con la métrica BurstBalance de CloudWatch.
No se pueden habilitar los registros de auditoría
Cuando intente habilitar la publicación de registro de auditoría mediante la consola del servicio de OpenSearch, puede encontrar el error siguiente:
La política de acceso a recursos especificada para el grupo de registros de CloudWatch Logs no concede permisos suficientes para que Amazon OpenSearch Service cree una secuencia de registro. Compruebe la política de acceso a recursos.
Si detecta este error, compruebe que el resourceelemento de su política incluye el ARN del grupo de registro correcto. Si lo hace, siga estos pasos:
-
Espere varios minutos.
-
Actualice la página en el navegador web.
-
Seleccione Seleccionar grupo existente.
-
Para Grupo de registros existente, seleccione el grupo de registro que ha creado antes de recibir el mensaje de error.
-
En la sección de políticas de acceso, seleccione Seleccionar política existente.
-
Para Política existente, elija la política que ha creado antes de recibir el mensaje de error.
-
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
No se puede cerrar el índice
El servicio OpenSearch es compatible con la API _close
Verificaciones de licencias del cliente
Las distribuciones predeterminadas de Logstash y Beats incluyen una comprobación de licencia de propiedad exclusiva y no se puede conectar a la versión de código abierto de OpenSearch. Asegúrese de utilizar las distribuciones de Apache 2.0 (OSS) de estos clientes con OpenSearch Service.
Limitación controlada de solicitudes
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 realiza una limitación controlada de las solicitudes si la carga puede provocar que el uso de memoria supere el tamaño máximo de la pila de Java.
No se puede usar SSH en nodo
No se puede utilizar SSH para obtener acceso a ninguno de los nodos del clúster de OpenSearch, y no puede modificar directamente opensearch.yml. En su lugar, utilice la consola, AWS CLI o los SDK para configurar su dominio. Puede especificar unos ajustes en el nivel de clúster mediante las API de OpenSearch REST . Para obtener más información, consulte la Referencia de API de Amazon OpenSearch Service y Operaciones compatibles en Amazon OpenSearch Service.
Si necesita más información sobre el rendimiento del clúster, puede publicar los registros de errores y los registros lentos en CloudWatch.
Error de instantánea "No válido para la clase de almacenamiento del objeto"
Las instantáneas de OpenSearch Service no admiten la clase de almacenamiento de S3 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 S3 Glacier.
Si tiene que restaurar una instantánea desde el bucket, restaure los objetos de S3 Glacier, copie los objetos a un nuevo bucket y registre el nuevo bucket como repositorio de instantáneas.
Encabezado de host no válido
OpenSearch Service requiere que los clientes especifiquen Host en los encabezados de solicitud. Un valor de Host válido es el punto de enlace del dominio sin https://, como:
Host: search-my-sample-domain-ih2lhn2ew2scurji.us-west-2.es.amazonaws.com
Si recibe un error de Invalid Host Header al realizar una reserva, compruebe que su cliente o proxy incluye el punto de enlace del dominio de OpenSearch Service (y no, por ejemplo, su dirección IP) en el encabezado Host.
Tipo de instancia M3 no válido
OpenSearch Service no admite agregar o modificar instancias M3 a dominios existentes que ejecutan OpenSearch o Elasticsearch versión 6.7 o posteriores. Puede seguir utilizando instancias M3 con Elasticsearch 6.5 y versiones anteriores.
Recomendamos elegir un tipo de instancia más reciente. Para dominios que ejecutan OpenSearch o Elasticsearch 6.7 o versiones posteriores, 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 activas dejan de funcionar después de habilitar UltraWarm
Cuando habilita UltraWarm en un dominio, si no hay anulaciones preexistentes en la configuración de search.max_buckets, OpenSearch Service establece automáticamente el valor en 10000 para evitar que las consultas con gran cantidad de memoria saturen los nodos calientes. Si sus consultas activas utilizan más de 10 000 buckets, es posible que dejen de funcionar cuando habilite UltraWarm.
Dado que no puede modificar esta configuración debido a la naturaleza administrada de Amazon OpenSearch Service, debe 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
Las actualizaciones in situ son irreversibles, pero si se pone en contacto con AWS Support
Resumen necesario de dominios para todas las Regiones de AWS
El siguiente script utiliza el comando de Amazon EC2 describe-regions de AWS CLI para crear una lista de todas las regiones en las que OpenSearch Service podría estar disponible. A continuación, llama a list-domain-names 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 OpenSearch Service no está disponible devuelven el error "Could not connect to the endpoint URL" (No se pudo conectar con la URL del punto de enlace).
Error del navegador al usar paneles de OpenSearch
El navegador incluye los mensajes de error de servicio en los objetos de respuesta HTTP cuando usa Dashboards para ver datos de su dominio de OpenSearch Service. 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
-
Desde la barra del menú superior de Chrome, seleccione Ver, Desarrollador, Herramientas de desarrollador.
-
Seleccione la pestaña Red.
-
En la columna Estado, seleccione cualquier sesión HTTP que tenga un estado de 500.
Para ver errores de servicio en Firefox
-
Desde el menú, seleccione Herramientas, Desarrollador de web, Red.
-
Seleccione cualquier sesión HTTP que tenga un estado de 500.
-
Seleccione la pestaña Respuesta para ver la respuesta de servicio.
Partición de nodos y sesgo de almacenamiento
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, ejecute la operación de la API _cat/allocationshards y disk.indices en la respuesta:
shards | disk.indices | disk.used | disk.avail | disk.total | disk.percent | host | ip | node264|465.3mb|229.9mb|1.4tb|1.5tb|0|x.x.x.x|x.x.x.x|node1115 | 7.9mb | 83.7mb | 49.1gb | 49.2gb | 0 | x.x.x.x | x.x.x.x | node2264|465.3mb|235.3mb|1.4tb|1.5tb|0|x.x.x.x|x.x.x.x|node3116 | 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
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 del índice es más difícil de identificar que el sesgo del nodo porque requiere cierta manipulación de la salida de la API _cat/shards
-
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 CPU o la pila de JVM en 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 un sesgo de almacenamiento de índices o partición, es posible que tenga que forzar una reasignación de particiones, que se produce con cada implementación azul/verde de su dominio de OpenSearch Service.
Operación no autorizada tras seleccionar acceso a la VPC
Cuando crea un dominio a través de la consola de OpenSearch Service, tiene la opción de seleccionar el acceso público o el acceso a la VPC. Si selecciona Acceso a la VPC, OpenSearch Service consulta la información de la VPC y genera un error si no tiene permisos adecuados:
You are not authorized to perform this operation. (Service: AmazonEC2; Status Code: 403; Error Code: UnauthorizedOperationPara 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 utiliza la CLI de AWS para crear y configurar un dominio con un punto de conexión de la VPC, no es necesario que tenga acceso a dichas operaciones.
Bloqueo al cargar después de crear el dominio de la VPC
Después de crear un dominio que utiliza el acceso a la VPC, es posible que la operación Configuration state (esado de configuración) del dominio no pase del estado Loading (Cargando). Si se produce este problema, es probable que AWS Security Token Service (AWS STS) esté desactivado para su región.
Para añadir puntos de enlace de la VPC a la VPC, OpenSearch Service debe asumir el rol 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 desactivación de AWS STS, consulte la Guía del usuario de IAM.
Solicitudes denegadas a la API de OpenSearch
Con la introducción del control de acceso basado en etiquetas para la API de OpenSearch, es posible que empiece a ver errores de acceso denegado donde no lo hacía antes. 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*.
{ "Version": "2012-10-17", "Statement": [{ "Action": [ "es:CreateDomain", "es:ESHttpPut" ], "Effect": "Deny", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:ResourceTag/environment": [ "production" ] } } }] }
Con la compatibilidad agregada de etiquetas para los métodos HTTP de OpenSearch, una política basada en la identidad de IAM como la anterior dará lugar a que se deniegue el acceso a la acción ESHttpPut al usuario adjunto. 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
Alpine Linux limita el tamaño de respuesta de DNS a 512 bytes. Si intenta conectarse a su dominio de OpenSearch Service desde Alpine Linux versión 3.18.0 o anterior, 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
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
El control de admisión basado en la CPU 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 en caso de incrementos orgánicos como de 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
Dado que los SDK de AWS utilizan certificados de entidad de certificación desde su equipo, los cambios en los certificados en los servidores de AWS pueden provocar errores de conexión cuando intentar usar un SDK. Los mensajes de error varían, pero suelen contener el siguiente texto:
Failed to query OpenSearch
...
SSL3_GET_SERVER_CERTIFICATE:certificate verify failedPuede 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
nota
En la actualidad, los dominios de OpenSearch Service de la región us-east-1 utilizan certificados de una entidad diferente. Tenemos previsto actualizar la región para utilizar estas nuevas entidades de certificación en un futuro próximo.
