Comprobación de estado de la búsqueda

La API de comprobación de estado de la búsqueda se utiliza para comprobar regularmente el estado de los contenedores de Commerce para asegurarse de que están en un estado correcto.

La comprobación de estado de búsqueda es una llamada REST con el siguiente punto final con el tipo de parámetro necesario y una modalidad de parámetro opcional:
/search/admin/resources/health/status?type=type&mode=modetype
donde type es entorno o contenedor,. El contenedor permite un parámetro adicional, mode=modetype donde modetype es el inicio (valor predeterminado) o la capacidad de ejecución. El valor predeterminado para modo es inicio, que es el comportamiento actual.

La llamada de comprobación de estado devolverá 200 si es satisfactoria y 500 si no es satisfactoria.

type=environment
Se efectúa una comprobación de estado para comprobar si varias partes pueden comunicarse entre sí. El resultado difiere ligeramente dependiendo del tipo de nodo en el que se hace ping:
  • En los servidores maestros, se comprueban la base de datos de creación y el servidor de transacciones de creación.
  • En el repetidor, el proceso busca una base de datos activa y núcleos en todos los subordinados.
  • En subordinados, busca una base de datos en tiempo real, un servidor de transacciones activo y núcleos en todos los subordinados.
type=container
La comprobación es una ejecución de prueba de microservicio que se ejecuta a un intervalo establecido para garantizar que cada contenedor se mantenga en buen estado. Cuando se llama en el maestro o repetidor, verifica que todos los núcleos locales acepten consultas de búsqueda y sean receptivos. Si se ejecuta en el repetidor, realizará la misma comprobación, además de que si la modalidad está establecida en el inicio, verificará que la réplica está funcionando con subordinados.
mode=startup
Opción PREDETERMINADO si el parámetro mode no está establecido. Cuando el parámetro mode no se invoca o tiene el valor de startup, si el repetidor de búsqueda se desactiva (o no está disponible temporalmente), todos sus servidores de búsqueda subordinados también se desactivan.
  • Compruebe que podemos enviar una solicitud a cada uno de nuestros núcleos de búsqueda (basándose en los núcleos de búsqueda definidos en la tabla SRCHCONF/SRCHCONFEXT).
  • Si el paso 1 es satisfactorio, compruebe los resultados de la réplica de índice.
  • Devuelva una comprobación de estado satisfactoria si no ha fallado ninguna comprobación; de lo contrario, devuelva una comprobación de estado incorrecta.
mode=liveness
Si el parámetro mode tiene el valor de liveness, la comprobación de estado devolverá Ok si los servidores subordinados Solr están activos incluso si el repetidor de búsqueda no está disponible.
  1. Compruebe que puede enviar una solicitud a cada uno de sus núcleos de búsqueda (basándose en los núcleos de búsqueda definidos en la tabla SRCHCONF/SRCHCONFEXT).
  2. Devuelva una comprobación de estado satisfactoria si no ha fallado ninguna comprobación; de lo contrario, devuelva una comprobación de estado anómala.

Las dos llamadas siguientes se devolverán con el estado 500.

search/admin/resources/health/status?type=container 

search/admin/resources/health/status?type=container& mode=startup

Esta llamada devolverá un estado de 200 si el repetidor está inactivo pero los servidores subordinados están activos.

search/admin/resources/health/status?type=container& mode=liveness