Resolução de problemas IBM Watson® Discovery Cartucho para implementações do IBM Cloud Pak® for Data

Aprenda maneiras de solucionar problemas e abordar assuntos que você pode encontrar enquanto utiliza o produto.

IBM Cloud Pak for Data

Essas informações se aplicam apenas a instâncias de IBM Watson® Discovery que são instaladas em IBM Cloud Pak® for Data. Para obter dicas de resolução de problemas sobre a inclusão de dados em implementações instaladas e gerenciadas, consulte Resolução de problemas de problemas.

As informações neste tópico sugerem passos que você pode tomar para investigar questões que possam ocorrer. Para obter informações sobre questões conhecidas e seus workarounds por versão, veja Problemas Conhecidos.

Pods de Minio entram em um loop de reboot durante a instalação ou atualização

  • Erro: Cannot find volume "export" to mount into container "ibm-minio" é exibido durante uma instalação ou atualização de Discovery. Ao verificar o status dos pods do Minio usando o comando, oc get pods -l release=wd-minio -o wide e, em seguida, verificar os logs Minio operator usando os comandos, oc get pods -A | grep ibm-minio-operator e, em seguida, oc logs -n <namespace> ibm-minio-operator-XXXXX, você verá um erro semelhante ao seguinte nos logs:

    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: Um trabalho que cria um balde de armazenamento para Minio e depois é excluído depois que ele se conclui, não está sendo excluído adequadamente.

  • Solução: Complete as etapas a seguir para verificar se um trabalho incompleto de create-bucket para Minio existe. Se for assim, exclua o job incompleto para que o trabalho possa ser recriado e possa então executar com sucesso.

    1. Confira a tarefa do Minio usando o seguinte comando:

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

    2. Se um job existente for listado na resposta, exclua a tarefa usando o seguinte comando:

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

    3. Verifique se todos os pods do Minio começam com sucesso usando o seguinte comando:

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

Uma mensagem No space left on device é exibida no log

Se o pod wd-ibm-elasticsearch-es-server-client reiniciar repetidamente e então relatar o estado Crashloopbackoff com a mensagem No space left on device escrita no log para o pod, então a questão pode ser uma falta de memória no pod. Siga os passos para solucionar problemas de problemas de memória ou entre em contato com o Suporte IBM.

Uma mensagem java.lang.OutOfMemoryError: Java heap space é exibida no log

Ao indexar um grande conjunto de documentos que possuem múltiplos enriquecimentos aplicados a eles, o nó do trabalhador pode ficar sem espaço. Para tratar do assunto, primeiro determine qual pod está fora da memória, completando as seguintes etapas:

Se o status do documento não puder ser promovido a Processing, verifique o status dos pods inlet, outlet e converter.

  1. Execute o comando a seguir:

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

  2. Se qualquer um dos pods não estiver mostrando um status Running, reinicie o pod com falha usando o seguinte comando:

    oc delete pod <pod_name>

  3. Caso contrário, abra a página Gerenciar coleções>{collection name}>Atividade. Verifique a seção Avisos e erros em uma olhada para a mensagem, OutOfMemory happened during conversion. Please reconsider size of documents. Se mostrada, use o seguinte comando para aumentar o tamanho da memória para o conversor:

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

    Ajuste o valor de maxHeapMemory e a memória do contêiner de acordo com seus recursos de cluster.

  4. Após o pod converter reiniciar com sucesso, clique em Reprocessar a partir da guia Atividade.

Se os documentos estiverem presos no status Processing e não puderem ser promovidos ao status Available para uma coleção, complete as seguintes etapas:

  1. Verifique o status de Hadoop usando o seguinte comando:

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

    onde l é uma minúslista L para lista.

  2. Se qualquer um dos pods não estiver mostrando um status Running, reinicie o pod com falha usando o seguinte comando:

    oc delete pod <pod_name>

  3. Verifique se qualquer um dos nós do trabalhador Hadoop tem memória insuficiente usando o seguinte comando para procurar a mensagem OOM when allocating :

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

  4. Se uma correspondência for encontrada, use o seguinte comando para corrigir o recurso:

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

    O valor máximo permitido para pythonAnalyzerMaxMemory é 12g. O valor padrão é 6g. Aumente o valor gradualmente, como em incrementos de 2g em um momento de acordo com seus recursos de cluster.

  5. Verifique se qualquer um dos nós do trabalhador Hadoop tem memória insuficiente usando o seguinte comando para procurar a mensagem OutOfMemoryError :

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

  6. Se uma correspondência for encontrada, verifique os valores da variável de ambiente atual e os recursos de memória do nó do trabalhador Hadoop usando os seguintes comandos:

    • Para verificar a variável "DOCPROC_MAX_MEMORY" no contêiner do orquestrador:

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

    • Para verificar a variável "YARN_NODEMANAGER_RESOURCE_MEMORY_MB" no contêiner do nó do trabalhador 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 verificar o recurso de memória do contêiner 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. Patch os recursos de variáveis de ambiente gradualmente usando o seguinte comando:

    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"}}}}}}'

    Os valores padrão para os recursos são os seguintes:

    • docproc.maxMemory: 2g

      Aumento de incrementos de 2g de cada vez.

    • nm.memoryMB: 10,240

      Comece a partir de 12.000 e aumente em incrementos de 2.000 de cada vez.

    • memory requests/limits: 13Gi/18Gi

      Aumento de incrementos de 2Gi de cada vez.

  8. Verifique se os pods do Hadoop reiniciam com sucesso usando o seguinte comando:

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

  9. Confirme se as novas configurações foram aplicadas depois que você patchou o cluster.

  10. Se o pod não for reiniciado, verifique se o recurso foi atualizado utilizando-se o seguinte comando:

    oc get wd wd -o yaml

  11. Verifique o status de Elasticsearch verificando separadamente o cliente e os nós de dados.

  12. No nó cliente, execute o seguinte comando para verificar se ocorreu uma exceção fora de memória:

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

  13. Se uma mensagem de erro for encontrada, excluindo as mensagens INFO, aumente o recurso de memória usando o seguinte comando:

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

  14. Depois de executar este comando, o pod do cliente Elasticsearch é reiniciado cerca de 20 minutes minutos depois. Monitore a "AGE" do pod usando o seguinte comando:

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

  15. Depois que o pod for reiniciado com sucesso, verifique o novo valor de ES_JAVA_OPTS e o limite de memória do contêiner usando o seguinte comando:

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

  16. No nó de dados, execute o seguinte comando para verificar se ocorreu uma exceção de memória de saída de memória:

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

  17. Se uma mensagem de erro for encontrada, excluindo as mensagens INFO, aumente o recurso de memória usando o seguinte comando:

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

  18. Depois de executar este comando, o pod do cliente Elasticsearch é reiniciado cerca de 20 minutes minutos depois. Monitore a "AGE" do pod usando o seguinte comando:

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

  19. Após o pod ser reiniciado com sucesso, verifique o novo valor de ES_JAVA_OPTS e os pedidos / limite de memória do contêiner usando o seguinte comando:

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

    Para ambos os nós (cliente e dados), configure o resources.limits.memory igual a 2 * maxHeap.

    Se o pod não puder ser reiniciado após 30 mins minutos aplicando o comando oc patch, colete logs para compartilhar com o Suporte IBM usando o seguinte comando:

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

Para ambos os problemas, em que o status do documento não pode ser promovido a Processing e onde os documentos estão presos no status Processing, se você estiver usando o armazenamento Portworx, você poderá verificar se o disco Elasticsearch está cheio.

  1. Execute o seguinte comando para verificar se o disco Elasticsearch está cheio:

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

  2. Se o log mostrar uma mensagem como watermark exceeded on x-data-1, significa que o disco no nó que está especificado está cheio e você precisa aumentar o tamanho do disco, usando o seguinte comando:

    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"}}}}'

    onde N denota o número do nó de dados que foi informado a partir do log.

    Por exemplo, se o log menciona data-1 no nome do nó, então o comando a utilizar é:

    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"}}}}'

Configurando o limite de shard no Discovery para o Cloud Pak for Data

Na versão Discovery 4.0, há um limite para o número de fragmentos que podem permanecer abertos em um cluster. Nas instâncias de desenvolvimento, o limite é de 1.000 shards abertos e, nas instâncias de produção, o limite é dois nós de dados, o que é igual a 2.000 shards abertos ou 1.000 shards abertos por nó de dados. Depois de atingir qualquer limite, não será possível criar mais nenhum projeto e coleções em seu cluster e, se tentar criar um novo projeto e uma coleção, você receberá uma mensagem de erro.

Esse limite se deve ao fato de que, ao instalar a versão Discovery 4.0, a versão Elasticsearch 7.10.2 é executada automaticamente em seus clusters. Como essa versão do Elasticsearch é executada em seus clusters, uma nova configuração de estabilidade do cluster torna-se disponível, que limita a 1.000 shards abertos para cada nó de dados do Elasticsearch.

Se não for possível criar novos projetos e coleções e receber erros, primeiro verifique o status de seu cluster do Elasticsearch e o número de shards nesse cluster. Considere aumentar o número de nós de dados em seu cluster para suportar mais shards. Esse método é ideal para maximizar o desempenho. No entanto, um número aumentado de nós usa mais memória. Se o número de shards atingir o limite, também é possível aumentar o limite em um nó de dados. Para obter mais informações sobre como aumentar o limite de shard em um nó, consulte Aumentando o limite de shard.

Esse limite de 1.000 shards se aplica a versões do Discovery que são 4.0 ou superior.

Aumentando o limite de shard

  1. Efetue login em seu cluster do Discovery.

  2. Acesse seu nó de dados.

  3. Insira o comando a seguir:

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

  4. Digite o seguinte comando, substituindo o endereço <> e o conteúdo interno pelo número da porta:

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

    Se você não souber qual é o número da sua porta, insira o comando a seguir para localizá-lo:

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

    O comando POST de curl retorna um valor para active_primary_shards. Se você tiver um nó de dados que tenha um valor maior que 1.000 ou se tiver dois nós de dados que tenham um valor maior que 2.000, deverá aumentar o limite de shard para criar novos projetos e coleções em seu cluster.

    Se aumentar esse limite, o cluster se tornará menos estável, porque ele contém um número maior de shards.

  5. Digite o seguinte comando para aumentar o número de shards, substituindo <port_number> pelo número da porta e <total_shards_per_node> e <max_shards_per_node> pelo novo limite de shards que você deseja atribuir a um nó:

    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'

    Depois de aumentar o limite de shard, será possível criar mais projetos e coleções em seu cluster.

Limpando um estado de bloqueio

IBM Cloud Pak for Data Somente instalado: Quando o pod gateway é reiniciado, ele executa um plug-in de validação de banco de dados que verifica se há alterações e aplica os conjuntos de alterações mais recentes ao banco de dados compartilhado. Se o pod for reiniciado enquanto essa verificação estiver em andamento, o plug-in poderá permanecer em um estado de bloqueio, impedindo a inicialização do serviço. Pode ser necessária uma intervenção manual no banco de dados para limpar o bloqueio.

Se a API do Discovery não ficar on-line ou se o pod gateway-0 parecer estar em um loop de falha constante, você pode tentar verificar os logs do servidor do Liberty para o serviço de API localizado aqui: /opt/ibm/wlp/output/wdapi/logs/messages.log

Os registros indicariam se o Liquibase está falhando e não consegue ser executado. Se o sistema estiver bloqueado, você poderá ver algo semelhante ao seguinte:

[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

É possível desbloquear manualmente o plug-in. Se você tiver Discovery 2.1.4 ou mais cedo, digite o seguinte comando no banco de dados postgres que o pod gateway-0 está olhando:

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

Se você tiver Discovery 2.2.0 ou posterior, digite o seguinte comando no banco de dados postgres que o pod gateway-0 está olhando para:

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"'

Se você puder reiniciar o pod gateway, tudo deverá ser retomado normalmente.

Configurações de variáveis de ambiente para o Smart Document Understanding

Há duas variáveis de ambiente que precisam ser ajustadas para o Smart Document Understanding no IBM Watson® Discovery versão 2.1.0. Isso foi resolvido na versão 2.1.1. Consulte Liberação 2.1.1, de 24 de janeiro de 2020.

SDU_PYTHON_REST_RESPONSE_TIMEOUT_MS
SDU_YOLO_TIMEOUT_SEC

Ambas devem ser configuradas para seu respectivo valor hour. Esses valores devem ser definidos no site <release-name>-watson-discovery-hdp ConfigMap.

Os valores devem ser:

SDU_PYTHON_REST_RESPONSE_TIMEOUT_MS Deve ser configurado para 3600000

SDU_YOLO_TIMEOUT_SEC Deve ser configurado para 3600

Esses valores devem ser configurados quando o software é instalado ou reinstalado.

Mensagens de erro de resolução de problemas

Se você receber as mensagens de erro que estão relacionadas a tempos limite e à memória insuficiente para seus enriquecimentos, será possível inserir os comandos a seguir para mudar o as configurações de tempo limite e de memória para resolver potencialmente essas mensagens de erro:

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

    Ação sugerida: aumentar o tempo limite de processamento do documento. Insira o comando a seguir para aumentar o tempo limite padrão de 10 para 20 minutos:

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

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

    Ação sugerida: aumentar o limite de memória do contêiner do orquestrador. Insira o comando a seguir para aumentar o limite de memória de 4 Gi para 6 Gi:

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

  • Mensagem de aviso: Indexing request timed out

    Ação sugerida: aumente o tempo limite para enviar por push os documentos para o Elasticsearch. Insira o comando a seguir para aumentar o tempo limite padrão de 10 para 20 minutos:

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