Traitement des incidents liés à la cartouche IBM Watson® Discovery pour les déploiements IBM Cloud Pak® for Data

Découvrez comment identifier et résoudre les problèmes que vous pouvez rencontrer lors de l'utilisation du produit.

IBM Cloud Pak for Data

Ces informations s'appliquent uniquement aux instances de IBM Watson® Discovery installées sur IBM Cloud Pak® for Data. Pour des conseils de traitement des incidents liés à l'ajout de données à des déploiements installés et gérés, voir Traitement des incidents liés à l'ingestion.

Les informations de cette rubrique suggèrent les étapes que vous pouvez effectuer pour examiner les problèmes qui peuvent se produire. Pour plus d'informations sur les problèmes connus et leurs solutions par version, voir Problèmes connus.

Les pods Minio entrent dans une boucle de réamorçage lors de l'installation ou de la mise à niveau

  • Erreur: Cannot find volume "export" to mount into container "ibm-minio" s'affiche lors d'une installation ou d'une mise à niveau de Discovery. Lorsque vous vérifiez le statut des pods Minio à l'aide de la commande oc get pods -l release=wd-minio -o wide, puis que vous consultez les journaux Minio operator à l'aide des commandes oc get pods -A | grep ibm-minio-operator, puis oc logs -n <namespace> ibm-minio-operator-XXXXX, vous voyez une erreur similaire à la suivante dans les journaux:

    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"

  • Cause: Un travail qui crée un compartiment de stockage pour Minio, puis qui est supprimé une fois qu'il est terminé, n'est pas supprimé correctement.

  • Solution: Procédez comme suit pour vérifier s'il existe un travail create-bucket incomplet pour Minio. Si tel est le cas, supprimez le travail incomplet afin qu'il puisse être recréé, puis exécutez-le avec succès.

    1. Recherchez le travail Minio à l'aide de la commande suivante:

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

    2. Si un travail existant est répertorié dans la réponse, supprimez-le à l'aide de la commande suivante:

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

    3. Vérifiez que tous les pods Minio démarrent correctement à l'aide de la commande suivante:

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

Un message No space left on device s'affiche dans le journal

Si un pod wd-ibm-elasticsearch-es-server-client redémarre à plusieurs reprises, puis signale l'état Crashloopbackoff avec le message No space left on device consigné dans le journal du pod, le problème peut être un manque de mémoire sur le pod. Suivez les étapes de traitement des problèmes de mémoire insuffisante ou contactez le support IBM.

Un message java.lang.OutOfMemoryError: Java heap space s'affiche dans le journal

Lors de l'indexation d'un grand ensemble de documents auxquels plusieurs enrichissements sont appliqués, le noeud worker peut être à court d'espace. Pour résoudre ce problème, déterminez d'abord quel pod manque de mémoire en procédant comme suit:

Si le statut du document ne peut pas être promu en Processing, vérifiez le statut des pods inlet, outlet et converter.

  1. Exécutez la commande suivante :

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

  2. Si l'un des pods ne présente pas le statut Running, redémarrez le pod défaillant à l'aide de la commande suivante:

    oc delete pod <pod_name>

  3. Sinon, ouvrez la page Manage collections>{collection name}>Activity. Consultez la section Warnings and errors at a glance pour le message, OutOfMemory happened during conversion. Please reconsider size of documents. Si elle est affichée, utilisez la commande suivante pour augmenter la taille de la mémoire du convertisseur:

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

    Ajustez la valeur de maxHeapMemory et la mémoire du conteneur en fonction des ressources de votre cluster.

  4. Une fois le pod converter redémarré, cliquez sur Retraiter dans l'onglet Activité.

Si des documents sont bloqués à l'état Processing et ne peuvent pas être promus à l'état Available pour une collection, procédez comme suit:

  1. Vérifiez l'état de Hadoop à l'aide de la commande suivante :

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

    où l est un L minuscule pour la liste.

  2. Si l'un des pods ne présente pas le statut Running, redémarrez le pod défaillant à l'aide de la commande suivante:

    oc delete pod <pod_name>

  3. Vérifiez si l'un des noeuds worker Hadoop ne dispose pas de suffisamment de mémoire à l'aide de la commande suivante pour rechercher le message OOM when allocating :

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

  4. Si une correspondance est trouvée, utilisez la commande suivante pour corriger la ressource:

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

    La valeur maximale autorisée pour pythonAnalyzerMaxMemory est 12g. La valeur par défaut est 6g. Augmentez la valeur progressivement, par exemple par incréments de 2g en fonction des ressources de votre cluster.

  5. Vérifiez si l'un des noeuds worker Hadoop ne dispose pas de suffisamment de mémoire à l'aide de la commande suivante pour rechercher le message OutOfMemoryError :

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

  6. Si une correspondance est trouvée, vérifiez les valeurs de variable d'environnement en cours et les ressources de mémoire de noeud worker Hadoop à l'aide des commandes suivantes:

    • Pour vérifier la variable "DOCPROC_MAX_MEMORY" dans le conteneur de l'orchestrateur:

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

    • Pour vérifier la variable "YARN_NODEMANAGER_RESOURCE_MEMORY_MB" dans le conteneur de noeud worker 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

    • Pour vérifier la ressource mémoire du conteneur 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. Corrigez progressivement les ressources de la variable d'environnement à l'aide de la commande suivante:

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

    Les valeurs par défaut des ressources sont les suivantes:

    • docproc.maxMemory: 2g

      Augmentation par incréments de 2g à la fois.

    • nm.memoryMB: 10,240

      Commencez à partir de 12 000 et augmentez par incréments de 2 000 à la fois.

    • memory requests/limits: 13Gi/18Gi

      Augmentation par incréments de 2Gi à la fois.

  8. Vérifiez si les pods Hadoop redémarrent correctement à l'aide de la commande suivante:

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

  9. Vérifiez que les nouvelles configurations ont été appliquées après avoir corrigé le cluster.

  10. Si le pod n'est pas redémarré, vérifiez si la ressource a été mise à jour à l'aide de la commande suivante:

    oc get wd wd -o yaml

  11. Vérifiez le statut d' Elasticsearch en vérifiant séparément le client et les noeuds de données.

  12. Sur le noeud client, exécutez la commande suivante pour vérifier si une exception de mémoire insuffisante s'est produite:

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

  13. Si un message d'erreur est trouvé, à l'exception des messages INFO, augmentez la ressource mémoire à l'aide de la commande suivante:

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

  14. Après avoir exécuté cette commande, le pod client Elasticsearch est redémarré environ 20 minutes plus tard. Surveillez le "AGE" du pod à l'aide de la commande suivante:

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

  15. Une fois le pod redémarré, vérifiez la nouvelle valeur de ES_JAVA_OPTS et la limite de mémoire du conteneur à l'aide de la commande suivante:

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

  16. Sur le noeud de données, exécutez la commande suivante pour vérifier si une exception de mémoire insuffisante s'est produite:

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

  17. Si un message d'erreur est trouvé, à l'exception des messages INFO, augmentez la ressource mémoire à l'aide de la commande suivante:

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

  18. Après avoir exécuté cette commande, le pod client Elasticsearch est redémarré environ 20 minutes plus tard. Surveillez le "AGE" du pod à l'aide de la commande suivante:

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

  19. Une fois le pod redémarré, vérifiez la nouvelle valeur de ES_JAVA_OPTS et la limite / demande de mémoire de conteneur à l'aide de la commande suivante:

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

    Pour les deux postes (client et données), définissez resources.limits.memory sur 2 * maxHeap.

    Si le pod ne peut pas être redémarré après 30 minutes en appliquant la commande oc patch, collectez les journaux à partager avec le support IBM à l'aide de la commande suivante:

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

Pour les deux problèmes, où le statut des documents ne peut pas être promu en Processing et où les documents sont bloqués à l'état Processing, si vous utilisez le stockage Portworx, vous pouvez vérifier si le disque Elasticsearch est saturé.

  1. Exécutez la commande suivante pour vérifier si le disque Elasticsearch est plein :

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

  2. Si le journal affiche un message tel que watermark exceeded on x-data-1, cela signifie que le disque sur le noeud spécifié est plein et que vous devez augmenter la taille du disque à l'aide de la commande suivante:

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

    où N désigne le numéro de noeud de données qui a été signalé dans le journal.

    Par exemple, si le journal mentionne data-1 dans le nom de noeud, la commande à utiliser est la suivante:

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

Définition de la limite de fragment dans Discovery for Cloud Pak for Data

Dans la version Discovery 4.0, il y a une limite au nombre de shards qui peuvent rester ouverts sur un cluster. Dans les instances de développement, la limite est de 1 000 fragments ouverts et dans les instances de production, la limite est de deux noeuds de données, ce qui équivaut à 2 000 fragments ouverts, soit 1 000 fragments ouverts par noeud de données. Une fois que vous avez atteint les deux limites, vous ne pouvez pas créer d'autres projets et collections sur votre cluster et, si vous tentez de créer un projet et une collection, vous recevez un message d'erreur.

Cette limite est due au fait que, lorsque vous installez la version Discovery 4.0, la version Elasticsearch 7.10.2 s'exécute automatiquement sur vos clusters. Etant donné que cette version d'Elasticsearch s'exécute sur vos clusters, une nouvelle configuration de stabilité de cluster est disponible. Elle limite le nombre de fragments ouverts à 1 000 pour chaque noeud de données Elasticsearch.

Si vous ne parvenez pas à créer de projets et de collections et que vous recevez des erreurs, commencez par vérifier le statut de votre cluster Elasticsearch et le nombre de fragments sur ce cluster. Envisagez d'augmenter le nombre de noeuds de données sur votre cluster pour prendre en charge d'autres fragments. Cette méthode s'avère optimale pour augmenter les performances. L'augmentation du nombre de noeuds utilise toutefois plus de mémoire. Si le nombre de fragments atteint la limite, vous pouvez également augmenter la limite dans un noeud de données. Pour plus d'informations sur l'augmentation de la limite de fragments dans un noeud, voir Augmentation de la limite de fragments.

Cette limite de 1 000 fragments s'applique aux versions de Discovery qui sont 4.0 ou supérieures.

Augmentation de la limite de fragments

  1. Connectez-vous à votre cluster Discovery.

  2. Accédez à votre noeud de données.

  3. Entrez la commande suivante :

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

  4. Entrez la commande suivante, en remplaçant le <> et le contenu à l'intérieur par votre numéro de port :

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

    Si vous ne connaissez pas votre numéro de port, entrez la commande suivante pour le trouver :

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

    La commande curl POST renvoie une valeur pour active_primary_shards. Si l'un de vos noeuds de données comporte plus de 1 000 fragments ou si vous disposez de deux noeuds de données comportant plus de 2 000 fragments, vous devez augmenter la limite de fragments pour pouvoir créer des projets et des collections dans votre cluster.

    Si vous augmentez cette limite, le cluster devient moins stable car il contient plus de fragments.

  5. Entrez la commande suivante pour augmenter le nombre d'unités, en remplaçant <port_number> par votre numéro de port et <total_shards_per_node> et <max_shards_per_node> par la nouvelle limite d'unités que vous souhaitez attribuer à un nœud :

    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'

    Après avoir augmenté la limite de fragments, vous pouvez créer d'autres projets et collections sur votre cluster.

Suppression d'un état de verrouillage

IBM Cloud Pak for Data Installé uniquement: Lorsque le pod gateway redémarre, il exécute un plug-in de validation de base de données qui vérifie les modifications et applique les derniers jeux de modifications à la base de données partagée. Si le pod est redémarré alors que cette vérification est en cours, le plug-in peut rester dans un état de verrouillage, ce qui empêche le service de démarrer. Une intervention manuelle dans la base de données peut être nécessaire pour supprimer le verrou.

Si l'API de découverte ne se met pas en ligne ou si le pod gateway-0 semble être dans une boucle de crash constante, vous pouvez essayer de vérifier les journaux du serveur Liberty pour le service API situé ici : /opt/ibm/wlp/output/wdapi/logs/messages.log

Les journaux indiquent si Liquibase est défaillant et incapable de fonctionner. Si le système est verrouillé, vous pouvez voir quelque chose de similaire à ce qui suit :

[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

Il est possible de déverrouiller manuellement le plug-in. Si vous disposez de Discovery 2.1.4 ou version antérieure, entrez la commande suivante sur la base de données postgres que le pod gateway-0 recherche:

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

Si vous disposez de Discovery 2.2.0 ou version ultérieure, entrez la commande suivante sur la base de données postgres que le pod gateway-0 recherche:

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 vous pouvez ensuite redémarrer le pod gateway, tout devrait reprendre normalement.

Paramètres des variables d'environnement pour Smart Document Understanding

Deux variables d'environnement doivent être ajustées pour Smart Document Understanding dans IBM Watson® Discovery version 2.1.0. Ce problème a été résolu dans la version 2.1.1. Voir Edition 2.1.1 du 24 janvier 2020.

SDU_PYTHON_REST_RESPONSE_TIMEOUT_MS
SDU_YOLO_TIMEOUT_SEC

Ces deux variables doivent être réglées sur leur valeur hour respective. Ces valeurs doivent être définies dans le site <release-name>-watson-discovery-hdp ConfigMap.

Les valeurs doivent être les suivantes :

SDU_PYTHON_REST_RESPONSE_TIMEOUT_MS Doit être définie sur 3600000

SDU_YOLO_TIMEOUT_SEC Doit être définie sur 3600

Ces valeurs doivent être définies lors de l'installation ou de la réinstallation du logiciel.

Traitement des messages d'erreur

Si vous recevez des messages d'erreur liés aux délais d'attente et à une mémoire insuffisante pour vos enrichissements, vous pouvez entrer les commandes suivantes pour modifier les paramètres de délai et de mémoire afin de résoudre éventuellement les messages d'erreur suivants :

  • Message d'avertissement : <enrichment_name>: Document enrichment timed out

    Action préconisée : augmentez le délai d'attente de gestion de documents. Entrez la commande suivante pour augmenter le délai d'attente par défaut de 10 à 20 minutes :

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

  • Message d'avertissement : <enrichment_name>: Document enrichment failed due to lack of memory

    Action préconisée : augmentez la limite de mémoire du conteneur d'orchestration. Entrez la commande suivante pour augmenter la limite de mémoire de 4 Gi à 6 Gi :

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

  • Message de notification : Indexing request timed out

    Action préconisée : augmentez le délai d'attente pour l'envoi de documents à Elasticsearch. Entrez la commande suivante pour augmenter le délai d'attente par défaut de 10 à 20 minutes :

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