Resolución de problemas del cartucho IBM Watson® Discovery para despliegues de IBM Cloud Pak® for Data

Aprenda a resolver problemas y a resolverlos que pueda encontrar al utilizar el producto.

IBM Cloud Pak for Data

Esta información sólo se aplica a las instancias de IBM Watson® Discovery que están instaladas en IBM Cloud Pak® for Data. Para obtener sugerencias de resolución de problemas sobre la adición de datos a despliegues instalados y gestionados, consulte Resolución de problemas de ingestión.

La información de este tema sugiere los pasos que puede seguir para investigar los problemas que pueden producirse. Para obtener información sobre problemas conocidos y sus soluciones temporales por versión, consulte Problemas conocidos.

Los pods de Minio entran en un bucle de rearranque durante la instalación o actualización

  • Error: Cannot find volume "export" to mount into container "ibm-minio" se muestra durante una instalación o actualización de Discovery. Cuando compruebe el estado de los pods de Minio utilizando el mandato oc get pods -l release=wd-minio -o wide y, a continuación, compruebe los registros de Minio operator utilizando los mandatos oc get pods -A | grep ibm-minio-operator y, a continuación, oc logs -n <namespace> ibm-minio-operator-XXXXX, verá un error similar al siguiente en los registros:

    ibm-minio/templates/minio-create-bucket-job.yaml failed: jobs.batch "wd-minio-discovery-create-bucket" already exists) and failed rollback: failed to replace object"

  • Causa: un trabajo que crea un grupo de almacenamiento para Minio y, a continuación, se suprime una vez que se completa, no se está suprimiendo correctamente.

  • Solución: realice los pasos siguientes para comprobar si existe un trabajo create-bucket incompleto para Minio. Si es así, suprima el trabajo incompleto para que el trabajo se pueda volver a crear y, a continuación, se pueda ejecutar correctamente.

    1. Compruebe el trabajo Minio utilizando el mandato siguiente:

      oc get jobs | grep 'wd-minio-discovery-create-bucket'

    2. Si se lista un trabajo existente en la respuesta, suprima el trabajo utilizando el mandato siguiente:

      oc delete job $(oc get jobs -oname | grep 'wd-minio-discovery-create-bucket')

    3. Verifique que todos los pods de Minio se inician correctamente utilizando el mandato siguiente:

      oc get pods -l release=wd-minio -o wide

Se muestra un mensaje No space left on device en el registro

Si un pod wd-ibm-elasticsearch-es-server-client se reinicia repetidamente y, a continuación, notifica el estado Crashloopbackoff con el mensaje No space left on device escrito en el registro para el pod, el problema puede ser una falta de memoria en el pod. Siga los pasos para resolver problemas de falta de memoria o póngase en contacto con el soporte de IBM.

Se muestra un mensaje java.lang.OutOfMemoryError: Java heap space en el registro

Al indexar un conjunto grande de documentos que tienen varios enriquecimientos aplicados, el nodo trabajador puede quedarse sin espacio. Para solucionar el problema, primero determine qué pod se ha quedado sin memoria realizando los pasos siguientes:

Si el estado del documento no se puede promocionar a Processing, compruebe el estado de los pods inlet, outlet y converter.

  1. Ejecute el mandato siguiente:

    oc get pod -l 'tenant=wd,run in (inlet,outlet,converter)'

  2. Si alguno de los pods no muestra un estado Running, reinicie el pod anómalo utilizando el mandato siguiente:

    oc delete pod <pod_name>

  3. De lo contrario, abra la página Gestionar colecciones>{collection name}>Actividad. Consulte la sección Avisos y errores de un vistazo para ver el mensaje, OutOfMemory happened during conversion. Please reconsider size of documents. Si se muestra, utilice el mandato siguiente para aumentar el tamaño de memoria del conversor:

    oc patch wd wd --type=merge \
--patch='{"spec":{"ingestion":{"converter":b{"maxHeapMemory":"10240m","resources":{"limits":{"memory":"10Gi"}}}}}}'

    Ajuste el valor de maxHeapMemory y la memoria del contenedor de acuerdo con los recursos del clúster.

  4. Después de que el pod de converter se reinicie correctamente, pulse Reprocesar en la pestaña Actividad.

Si los documentos están atascados en el estado Processing y no se pueden promocionar al estado Available para una colección, realice los pasos siguientes:

  1. Compruebe el estado de Hadoop utilizando el siguiente comando:

    oc get pod -l 'tenant=wd,run in (hdp-rm,hdp-worker)'

    donde l es una L en minúsculas para la lista.

  2. Si alguno de los pods no muestra un estado Running, reinicie el pod anómalo utilizando el mandato siguiente:

    oc delete pod <pod_name>

  3. Compruebe si alguno de los nodos de trabajador Hadoop no tiene memoria suficiente utilizando el mandato siguiente para buscar el mensaje OOM when allocating :

    oc logs -l tenant=wd,run=hdp-worker -c logger --tail=-1 \
| grep "OOM when allocating"

  4. Si se encuentra una coincidencia, utilice el mandato siguiente para aplicar un parche al recurso:

    oc patch wd wd --type=merge \
--patch='{"spec":{"orchestrator":{"docproc":{"pythonAnalyzerMaxMemory":"8g"}}}}'

    El valor máximo permitido para pythonAnalyzerMaxMemory es 12g. El valor predeterminado es 6g. Aumente el valor gradualmente, como por ejemplo en incrementos de 2g a la vez según los recursos del clúster.

  5. Compruebe si alguno de los nodos de trabajador Hadoop no tiene memoria suficiente utilizando el mandato siguiente para buscar el mensaje OutOfMemoryError :

    oc logs -l tenant=wd,run=hdp-worker -c logger --tail=-1 \
| grep "OutOfMemoryError"

  6. Si se encuentra una coincidencia, compruebe los valores de la variable de entorno actual y los recursos de memoria del nodo trabajador Hadoop utilizando los mandatos siguientes:

    • Para comprobar la variable "DOCPROC_MAX_MEMORY" en el contenedor de Orchestrator:

      oc exec `oc get po -l run=orchestrator -o 'jsonpath={.items[0].metadata.name}'` env \
| grep DOCPROC_MAX_MEMORY

    • Para comprobar la variable "YARN_NODEMANAGER_RESOURCE_MEMORY_MB" en el contenedor de nodos trabajadores Hadoop:

      oc exec `oc get po -lrun=hdp-worker -o 'jsonpath={.items[0].metadata.name}'` \
-c hdp-worker -- env | grep YARN_NODEMANAGER_RESOURCE_MEMORY_MB

    • Para comprobar el recurso de memoria del contenedor hdp-worker :

      oc get po -l run=hdp-worker -o 'jsonpath=requests are \
{.items[*].spec.containers[?(.name=="hdp-worker")].resources.requests.memory}, \
limits are {.items[*].spec.containers[?(.name=="hdp-worker")].resources.limits.memory}'

  7. Aplique un parche gradual a los recursos de la variable de entorno utilizando el mandato siguiente:

    oc patch wd `oc get wd -o 'jsonpath={.items[0].metadata.name}'` \
--type=merge --patch='{"spec":{"orchestrator":{"docproc":{"maxMemory":"4g"}}, \
"hdp":{"worker":{"nm":{"memoryMB":12000}, "resources":{"limits":{"memory":"20Gi"}, \
"requests":{"memory":"20Gi"}}}}}}'

    Los valores predeterminados para los recursos son los siguientes:

    • docproc.maxMemory: 2g

      Aumento en incrementos de 2g a la vez.

    • nm.memoryMB: 10,240

      Parte de 12.000 y aumenta en incrementos de 2.000 a la vez.

    • memory requests/limits: 13Gi/18Gi

      Aumento de incrementos de 2Gi a la vez.

  8. Compruebe si los pods Hadoop se reinician correctamente utilizando el mandato siguiente:

    oc get pods -l 'tenant=wd,run in (orchestrator,hdp-worker)'

  9. Confirme que las nuevas configuraciones se han aplicado después de aplicar el parche en el clúster.

  10. Si el pod no se reinicia, compruebe si el recurso se ha actualizado utilizando el mandato siguiente:

    oc get wd wd -o yaml

  11. Compruebe el estado de Elasticsearch comprobando el cliente y los nodos de datos por separado.

  12. En el nodo de cliente, ejecute el mandato siguiente para comprobar si se ha producido una excepción de falta de memoria:

    oc logs -l tenant=wd,ibm-es-data=False,ibm-es-master=False \
-c elasticsearch --tail=-1 | grep "OutOfMemoryError"

  13. Si se encuentra un mensaje de error, excluyendo los mensajes INFO, aumente el recurso de memoria utilizando el mandato siguiente:

    oc patch wd wd --type=merge \
--patch='{"spec":{"elasticsearch":{"clientNode":{"maxHeap":"896m","resources":{"limits":{"memory":"1792Mi"}}}}}}'

  14. Después de ejecutar este mandato, el pod de cliente Elasticsearch se reinicia unos 20 minutos después. Supervise la "AGE" del pod utilizando el mandato siguiente:

    oc get pod -l tenant=wd,ibm-es-data=False,ibm-es-master=False

  15. Después de que el pod se haya reiniciado correctamente, compruebe el nuevo valor de ES_JAVA_OPTS y el límite de memoria del contenedor utilizando el mandato siguiente:

    oc describe $(oc get po -l tenant=wd,ibm-es-data=False,ibm-es-master=False -o name)

  16. En el nodo de datos, ejecute el mandato siguiente para comprobar si se ha producido una excepción de falta de memoria:

    oc logs -l tenant=wd,ibm-es-data=True,ibm-es-master=False \
-c elasticsearch --tail=-1 | grep "OutOfMemoryError"

  17. Si se encuentra un mensaje de error, excluyendo los mensajes INFO, aumente el recurso de memoria utilizando el mandato siguiente:

    oc patch wd wd --type=merge \
--patch='{"spec":{"elasticsearch":{"dataNode":{"maxHeap":"6g","resources":{"limits":{"memory":"10Gi"},"requests":{"memory":"8Gi"}}}}}}'

  18. Después de ejecutar este mandato, el pod de cliente Elasticsearch se reinicia unos 20 minutos después. Supervise la "AGE" del pod utilizando el mandato siguiente:

    oc get pod -l tenant=wd,ibm-es-data=True,ibm-es-master=False

  19. Después de que el pod se haya reiniciado correctamente, compruebe el nuevo valor de ES_JAVA_OPTS y las solicitudes/límite de memoria de contenedor utilizando el mandato siguiente:

    oc describe $(oc get po -l tenant=wd,ibm-es-data=True,ibm-es-master=False -o name)

    Para ambos nodos (cliente y datos), establezca resources.limits.memory igual a 2 * maxHeap.

    Si el pod no se puede reiniciar después de 30 minutos aplicando el mandato oc patch, recopile registros para compartirlos con el soporte de IBM utilizando el mandato siguiente:

    oc logs -l control-plane=ibm-es-controller-manager --tail=-1

Para ambos problemas, donde el estado del documento no se puede promocionar a Processing y donde los documentos están atascados en el estado Processing, si está utilizando el almacenamiento Portworx, puede comprobar si el disco Elasticsearch está lleno.

  1. Ejecute el siguiente comando para comprobar si el disco e Elasticsearch s está lleno:

    oc logs -l tenant=wd,run=elastic,ibm-es-master=True \
-c elasticsearch --tail=100000|grep 'disk watermark'

  2. Si el registro muestra un mensaje como, por ejemplo, watermark exceeded on x-data-1, significa que el disco del nodo especificado está lleno y que es necesario aumentar el tamaño del disco utilizando el mandato siguiente:

    oc patch pvc $(oc get pvc -l tenant=wd,run=elastic,ibm-es-data=True,ibm-es-master=False \
-o jsonpath='{.items[N].metadata.name}') \
-p '{"spec": {"resources": {"requests":{"storage": "60Gi"}}}}'

    donde N indica el número de nodo de datos que se ha notificado desde el registro.

    Por ejemplo, si el registro menciona data-1 en el nombre de nodo, el mandato a utilizar es:

    oc patch pvc $(oc get pvc -l tenant=wd,run=elastic,ibm-es-data=True,ibm-es-master=False \
-o jsonpath='{.items[1].metadata.name}') -p '{"spec": {"resources": {"requests":{"storage": "60Gi"}}}}'

Configuración del límite de fragmentos en Discovery para Cloud Pak para datos

En la versión 1.1.0 de Discovery, 4.0, existe un límite en el número de fragmentos que pueden permanecer abiertos en un clúster. En las instancias de desarrollo, el límite es de 1.000 fragmentos abiertos, y en instancias de producción, el límite es dos nodos de datos, que es igual a 2.000 fragmentos abiertos, o 1.000 fragmentos abiertos por nodo de datos. Después de alcanzar el límite, no puede crear más proyectos ni colecciones en el clúster, y, si intenta crear un proyecto y una colección nuevos, recibirá un mensaje de error.

Este límite se debe al hecho de que, cuando instala Discovery versión 4.0, Elasticsearch versión 7.10.2 se ejecuta automáticamente en sus clústeres. Debido a que esta versión de Elasticsearch se ejecuta en los clústeres, pasa a estar disponible una nueva configuración de estabilidad de clúster que limita el número de fragmentos abiertos a 1.000 por cada nodo de datos de Elasticsearch.

Si no puede crear nuevos proyectos y colecciones y recibe errores, compruebe primero el estado del clúster de Elasticsearch y el número de fragmentos de dicho clúster. Tenga en cuenta la posibilidad de aumentar el número de nodos de datos en el clúster para dar soporte a más fragmentos. Este método resulta óptimo para maximizar el rendimiento. Sin embargo, un número mayor de nodos utiliza más memoria. Si el número de fragmentos alcanza el límite, también puede aumentar el límite en un nodo de datos. Para obtener más información sobre cómo aumentar el límite de fragmentos en un nodo, consulte Aumento del límite de fragmentos.

Este límite de 1.000 fragmentos se aplica a las versiones de Discovery que son 4.0 o superiores.

Aumento del límite de fragmentos

  1. Inicie una sesión en el clúster de Discovery.

  2. Acceda al nodo de datos.

  3. Escriba el mandato siguiente:

    oc exec -it $(oc get pod \
-l app=elastic,ibm-es-data=True -o jsonpath='{.items[0].metadata.name}') -- bash

  4. Introduzca el siguiente comando, sustituyendo el <> y el contenido interior por su número de puerto:

    curl -X POST http://localhost:<port_number>/_cluster/health?pretty

    Si no sabe cuál es su número de puerto, escriba el siguiente mandato para localizarlo:

    oc get pod -l app=elastic,ibm-es-data=True -o json \
| jq .items[].spec.containers[].ports[0].containerPort | head -n 1`

    El mandato de curl POST devuelve un valor para active_primary_shards. Si tiene un nodo de datos que tiene un valor mayor que 1.000 o si tiene dos nodos de datos que tienen un valor mayor que 2.000, debe aumentar el límite de fragmentos para crear nuevos proyectos y colecciones en el clúster.

    Si aumenta este límite, el clúster pierde estabilidad porque contiene un número mayor de fragmentos.

  5. Introduzca el siguiente comando para aumentar el número de fragmentos, sustituyendo <port_number> por su número de puerto y <total_shards_per_node> y <max_shards_per_node> por el nuevo límite de fragmentos que desea asignar a un nodo:

    curl -X POST http://localhost:<port_number>/_cluster/settings \
-d '{"persistent": {"cluster.routing.allocation.total_shards_per_node":<total_shards_per_node>, \
"cluster.max_shards_per_node":<max_shards_per_node>} }' \
-XPUT -H 'Content-Type:application/json'

    Después de aumentar el límite de fragmentos, puede crear más proyectos y colecciones en el clúster.

Eliminación de un estado de bloqueo

IBM Cloud Pak for Data Solo instalado: Cuando el pod de gateway se reinicia, ejecuta un complemento de validación de base de datos que comprueba los cambios y aplica los últimos conjuntos de cambios a la base de datos compartida. Si el pod se reinicia mientras esta comprobación está en curso, el plug-in podría permanecer en estado de bloqueo, impidiendo que el servicio se inicie. Puede que sea necesaria una intervención manual en la base de datos para desbloquearla.

Si la API de Discovery no se activa o si el pod de gateway-0 parece estar en un bucle de bloqueo constante, puede intentar comprobar los registros del servidor Liberty para el servicio API que se encuentra aquí: /opt/ibm/wlp/output/wdapi/logs/messages.log

Los registros indicarían si Liquibase está fallando y no puede ejecutarse. Si el sistema está bloqueado, es posible que vea algo similar a lo siguiente:

[11/7/19 5:07:51:491 UTC] 0000002f liquibase.executor.jvm.JdbcExecutor I SELECT LOCKED FROM public.databasechangeloglock WHERE ID=1
[11/7/19 5:07:51:593 UTC] 0000002f liquibase.lockservice.StandardLockService I Waiting for changelog lock....
[11/7/19 5:08:01:601 UTC] 0000002f liquibase.executor.jvm.JdbcExecutor I SELECT LOCKED FROM public.databasechangeloglock WHERE ID=1
[11/7/19 5:08:02:091 UTC] 0000002f liquibase.lockservice.StandardLockService I Waiting for changelog lock....
[11/7/19 5:08:12:097 UTC] 0000002f liquibase.executor.jvm.JdbcExecutor I SELECT LOCKED FROM public.databasechangeloglock WHERE ID=1
[11/7/19 5:08:12:197 UTC] 0000002f liquibase.lockservice.StandardLockService I Waiting for changelog lock....
[11/7/19 5:08:22:203 UTC] 0000002f liquibase.executor.jvm.JdbcExecutor I SELECT ID,LOCKED,LOCKGRANTED,LOCKEDBY FROM public.databasechangeloglock WHERE ID=1
[11/7/19 5:08:22:613 UTC] 0000002f com.ibm.ws.logging.internal.impl.IncidentImpl I FFDC1015I: An FFDC Incident has been created: "org.jboss.weld.exceptions.DeploymentException: WELD-000049: Unable to invoke public void liquibase.integration.cdi.CDILiquibase.onStartup() on liquibase.integration.cdi.CDILiquibase@7f02a07 com.ibm.ws.container.service.state.internal.ApplicationStateManager 31" at ffdc\_19.11.07\_05.08.22.0.log

Es posible desbloquear manualmente el plug-in. Si tiene Discovery 2.1.4 o anterior, especifique el mandato siguiente en la base de datos postgres que está examinando el pod gateway-0 :

psql dadmin
UPDATE DATABASECHANGELOGLOCK SET LOCKED=FALSE, LOCKGRANTED=null, LOCKEDBY=null where ID=1;

Si tiene Discovery 2.2.0 o posterior, especifique el mandato siguiente en la base de datos postgres que está buscando el pod gateway-0 :

oc exec -it wd-discovery-postgres-0 -- bash -c 'env PGPASSWORD="$PG_PASSWORD" psql "postgresql://$PG_USER@$STKEEPER_CLUSTER_NAME-proxy-service:$STKEEPER_PG_PORT/dadmin" -c "UPDATE DATABASECHANGELOGLOCK SET LOCKE
D=FALSE, LOCKGRANTED=null, LOCKEDBY=null where ID=1"'

Si puede reiniciar el pod de gateway, todo debería reanudarse con normalidad.

Valores de variables de entorno para Smart Document Understanding

Hay dos variables de entorno que deben ajustarse para la comprensión inteligente de documentos en la versión 2.1.0 de IBM Watson® Discovery. Esto se ha resuelto en la versión 2.1.1; consulte release 2.1.1, 24 de enero de 2020.

SDU_PYTHON_REST_RESPONSE_TIMEOUT_MS
SDU_YOLO_TIMEOUT_SEC

Ambas variables se deben establecer en su respectivo valor de hour. Estos valores deben establecerse en el archivo <release-name>-watson-discovery-hdp ConfigMap.

Los valores deben ser:

SDU_PYTHON_REST_RESPONSE_TIMEOUT_MS Debe establecerse en 3600000

SDU_YOLO_TIMEOUT_SEC Debe establecerse en 3600

Estos valores se deben establecer cuando se instala o cuando se reinstala el software.

Solución de problemas de mensajes de error

Si recibe mensajes de error relacionados con tiempos de espera excedidos y con memoria insuficiente para sus enriquecimientos, puede especificar los mandatos siguientes para cambiar los valores de tiempo de espera y de memoria para poder resolver estos mensajes de error:

  • Mensaje de aviso: <enrichment_name>: Document enrichment timed out

    Acción recomendada: aumentar el tiempo de espera de proceso de documentos. Especifique el siguiente mandato para aumentar el tiempo de espera predeterminado de 10 a 20 minutos:

    oc patch wd wd --type=merge \
--patch='{"spec": {"orchestrator": {"docproc": {"defaultTimeoutSeconds": 1200 } } } }'

  • Mensaje de aviso: <enrichment_name>: Document enrichment failed due to lack of memory

    Acción recomendada: aumentar el límite de memoria del contenedor del orquestador. Especifique el siguiente mandato para aumentar el límite de memoria de 4 Gi a 6 Gi:

    oc patch wd wd --type=merge \
--patch='{"spec": {"orchestrator": {"resources": {"limits": {"memory": "6Gi"} } } } }'

  • Mensaje de aviso: Indexing request timed out

    Acción recomendada: aumentar el tiempo de espera para enviar documentos a Elasticsearch. Especifique el siguiente mandato para aumentar el tiempo de espera predeterminado de 10 a 20 minutos:

    oc patch wd wd --type=merge \
--patch='{"spec": {"shared": {"elastic": {"publishTimeoutSeconds": 1200 } } } }'