Risoluzione dei problemi relativi alla cartuccia IBM Watson® Discovery per le distribuzioni IBM Cloud Pak® for Data

Scopri come risolvere e risolvere i problemi che potrebbero verificarsi durante l'uso del prodotto.

IBM Cloud Pak for Data

Queste informazioni si applicano soltanto a istanze di IBM Watson® Discovery installate su IBM Cloud Pak® for Data. Per i suggerimenti per la risoluzione dei problemi relativi all'aggiunta di dati sia alle distribuzioni installate che a quelle gestite, consultare Risoluzione dei problemi dell'inserimento.

Le informazioni contenute in questo argomento suggeriscono le operazioni che è possibile eseguire per esaminare i problemi che potrebbero verificarsi. Per informazioni sui problemi noti e le loro soluzioni temporanee per versione, vedi Problemi noti.

I pod Minio immettono un loop di riavvio durante l'installazione o l'aggiornamento

Errore: Cannot find volume "export" to mount into container "ibm-minio" viene visualizzato durante un'installazione o un aggiornamento di Discovery. Quando controlli lo stato dei pod Minio utilizzando il comando, oc get pods -l release=wd-minio -o wide, e poi controlla i log Minio operator utilizzando i comandi, oc get pods -A | grep ibm-minio-operator e oc logs -n <namespace> ibm-minio-operator-XXXXX, vedi un errore simile al seguente nei log:
```
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 lavoro che crea un bucket di archiviazione per Minio e viene quindi eliminato una volta completato, non viene eliminato correttamente.
Soluzione: completare la seguente procedura per controllare se esiste un lavoro create-bucket incompleto per Minio. In tal caso, eliminare il lavoro incompleto in modo che il lavoro possa essere ricreato e possa quindi essere eseguito correttamente.
1. Controllare il lavoro Minio utilizzando il seguente comando:
```
oc get jobs | grep 'wd-minio-discovery-create-bucket'
```
2. Se un lavoro esistente è elencato nella risposta, eliminare il lavoro utilizzando il seguente comando:
```
oc delete job $(oc get jobs -oname | grep 'wd-minio-discovery-create-bucket')
```
3. Verifica che tutti i pod Minio vengano avviati correttamente utilizzando il seguente comando:
```
oc get pods -l release=wd-minio -o wide
```

Nel file di log viene visualizzato un messaggio `No space left on device`

Se il pod wd-ibm-elasticsearch-es-server-client viene riavviato ripetutamente e quindi riporta lo stato Crashloopbackoff con il messaggio No space left on device scritto nel log per il pod, il problema potrebbe essere una mancanza di memoria sul pod. Segui la procedura per risolvere i problemi di memoria esaurita o contatta il supporto IBM.

Nel file di log viene visualizzato un messaggio `java.lang.OutOfMemoryError: Java heap space`

Quando indicizzi una grande serie di documenti a cui vengono applicati più arricchimenti, il nodo di lavoro può esaurire lo spazio. Per risolvere il problema, determinare prima quale pod ha esaurito la memoria completando la seguente procedura:

Se lo stato del documento non può essere promosso a Processing, controlla lo stato dei pod inlet, outlet e converter.

Esegui il seguente comando:

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

Se uno dei pod non mostra uno stato Running, riavvia il pod in errore utilizzando il seguente comando:
```
oc delete pod <pod_name>
```
Altrimenti, aprire la pagina Gestisci raccolte>{collection name}>Attività. Controllare la sezione Avvertenze ed errori a colpo d'occhio per il messaggio, OutOfMemory happened during conversion. Please reconsider size of documents. Se mostrato, utilizzare il seguente comando per aumentare la dimensione della memoria per il converter:
```
oc patch wd wd --type=merge \
--patch='{"spec":{"ingestion":{"converter":b{"maxHeapMemory":"10240m","resources":{"limits":{"memory":"10Gi"}}}}}}'
```
Modifica il valore di maxHeapMemory e la memoria contenitore in base alle tue risorse cluster.
Dopo che il pod converter è stato riavviato correttamente, fai clic su Rielabora dalla scheda Attività.

Se i documenti sono bloccati nello stato Processing e non possono essere promossi allo stato Available per una raccolta, completare la seguente procedura:

Verificate lo stato di Hadoop utilizzando il seguente comando:
```
oc get pod -l 'tenant=wd,run in (hdp-rm,hdp-worker)'
```
dove l è una L minuscola per l'elenco.
Se uno dei pod non mostra uno stato Running, riavvia il pod in errore utilizzando il seguente comando:
```
oc delete pod <pod_name>
```
Controlla se uno dei nodi di lavoro Hadoop ha memoria insufficiente utilizzando il seguente comando per cercare il messaggio OOM when allocating :
```
oc logs -l tenant=wd,run=hdp-worker -c logger --tail=-1 \
| grep "OOM when allocating"
```
Se viene trovata una corrispondenza, utilizzare il seguente comando per correggere la risorsa:
```
oc patch wd wd --type=merge \
--patch='{"spec":{"orchestrator":{"docproc":{"pythonAnalyzerMaxMemory":"8g"}}}}'
```
Il valore massimo consentito per pythonAnalyzerMaxMemory è 12g. Il valore predefinito è 6g. Aumenta il valore gradualmente, ad esempio in incrementi di 2g alla volta in base alle tue risorse cluster.
Controlla se uno dei nodi di lavoro Hadoop ha memoria insufficiente utilizzando il seguente comando per cercare il messaggio OutOfMemoryError :
```
oc logs -l tenant=wd,run=hdp-worker -c logger --tail=-1 \
| grep "OutOfMemoryError"
```

Se viene trovata una corrispondenza, controlla i valori correnti della variabile di ambiente e le risorse di memoria del nodo di lavoro Hadoop utilizzando questi comandi:

Per verificare la variabile "DOCPROC_MAX_MEMORY" nel contenitore orchestrator:

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

Per controllare la variabile "YARN_NODEMANAGER_RESOURCE_MEMORY_MB" nel contenitore del nodo di lavoro 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

Per controllare la risorsa di memoria del contenitore 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}'

Correggere gradualmente le risorse delle variabili di ambiente utilizzando il seguente 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"}}}}}}'
```
I valori predefiniti per le risorse sono i seguenti:
- docproc.maxMemory: 2g
  
  Aumento in incrementi di 2g alla volta.
- nm.memoryMB: 10,240
  
  Inizia da 12.000 e aumenta in incrementi di 2.000 alla volta.
- memory requests/limits: 13Gi/18Gi
  
  Aumento in incrementi di 2Gi alla volta.
Controlla se i pod Hadoop si riavviano correttamente utilizzando il seguente comando:
```
oc get pods -l 'tenant=wd,run in (orchestrator,hdp-worker)'
```
Conferma che le nuove configurazioni sono state applicate dopo aver corretto il cluster.
Se il pod non viene riavviato, controlla se la risorsa è stata aggiornata utilizzando il seguente comando:
```
oc get wd wd -o yaml
```
Controlla lo stato di Elasticsearch controllando separatamente il client e i nodi di dati.

Sul nodo client, eseguire il seguente comando per verificare se si è verificata un'eccezione di memoria esaurita:

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

Se viene trovato un messaggio di errore, escludendo i messaggi INFO, aumentare la risorsa di memoria utilizzando il seguente comando:

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

Dopo aver eseguito questo comando, il pod client Elasticsearch viene riavviato circa 20 minuti dopo. Monitora l'"AGE" del pod utilizzando il seguente comando:
```
oc get pod -l tenant=wd,ibm-es-data=False,ibm-es-master=False
```
Dopo che il pod è stato riavviato correttamente, controlla il nuovo valore di ES_JAVA_OPTS e il limite di memoria del contenitore utilizzando il seguente comando:
```
oc describe $(oc get po -l tenant=wd,ibm-es-data=False,ibm-es-master=False -o name)
```
Sul nodo di dati, eseguire il comando riportato di seguito per verificare se si è verificata un'eccezione di memoria esaurita:
```
oc logs -l tenant=wd,ibm-es-data=True,ibm-es-master=False \
-c elasticsearch --tail=-1 | grep "OutOfMemoryError"
```

Se viene trovato un messaggio di errore, escludendo i messaggi INFO, aumentare la risorsa di memoria utilizzando il seguente comando:

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

Dopo aver eseguito questo comando, il pod client Elasticsearch viene riavviato circa 20 minuti dopo. Monitora l'"AGE" del pod utilizzando il seguente comando:
```
oc get pod -l tenant=wd,ibm-es-data=True,ibm-es-master=False
```
Una volta riavviato correttamente il pod, controlla il nuovo valore di ES_JAVA_OPTS e il limite / richieste di memoria del contenitore utilizzando il seguente comando:
```
oc describe $(oc get po -l tenant=wd,ibm-es-data=True,ibm-es-master=False -o name)
```
Per entrambi i nodi (client e dati), impostare resources.limits.memory su 2 * maxHeap.

Se il pod non può essere riavviato dopo 30 minuti applicando il comando oc patch, raccogliere i log da condividere con il supporto IBM utilizzando il seguente comando:
```
oc logs -l control-plane=ibm-es-controller-manager --tail=-1
```

Per entrambi i problemi, dove lo stato del documento non può essere promosso a Processing e dove i documenti sono bloccati nello stato Processing, se stai utilizzando l'archiviazione Portworx, puoi verificare se il disco Elasticsearch è pieno.

Eseguire il seguente comando per verificare se il disco Elasticsearch è pieno:

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

Se il log mostra un messaggio come watermark exceeded on x-data-1, significa che il disco sul nodo specificato è pieno ed è necessario aumentare la dimensione del disco utilizzando il seguente 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"}}}}'

dove N indica il numero del nodo di dati riportato dal log.

Ad esempio, se il log cita data-1 nel nome nodo, il comando da utilizzare è:

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

Impostazione del limite di frammenti in Discovery for Cloud Pak for Data

In Discovery versione 4.0, c'è un limite al numero di frammenti che possono rimanere aperti su un cluster. Nelle istanze di sviluppo, il limite è di 1.000 frammenti aperti e nelle istanze di produzione, il limite è di due nodi di dati, che è uguale a 2.000 frammenti aperti o 1.000 frammenti aperti per nodo di dati. Una volta raggiunto uno dei limiti, non è possibile creare ulteriori progetti e raccolte sul cluster e se si tenta di creare un nuovo progetto e una nuova raccolta, si riceve un messaggio di errore.

Questo limite è dovuto al fatto che, quando installi Discovery versione 4.0, Elasticsearch versione 7.10.2 viene eseguito automaticamente sui tuoi cluster. Poiché questa versione di Elasticsearch viene eseguita sui cluster, diventa disponibile una nuova configurazione di stabilità del cluster che limita il numero di frammenti aperti a 1.000 per ogni nodo di dati Elasticsearch.

Se non riesci a creare nuovi progetti e raccolte e ricevi degli errori, controlla prima lo stato del tuo cluster Elasticsearch e il numero di frammenti su tale cluster. Prendere in considerazione l'aumento del numero di nodi di dati sul cluster per supportare più frammenti. Questo metodo è ottimale per massimizzare le prestazioni. Tuttavia, un numero maggiore di nodi utilizza più memoria. Se il numero di frammenti raggiunge il limite, è anche possibile aumentare il limite in un nodo di dati. Per ulteriori informazioni sull'aumento del limite di frammenti in un nodo, consultare Aumento del limite di frammenti.

Questo limite di 1.000 frammenti si applica alle versioni di Discovery che sono 4.0 o successive.

Aumento del limite di frammenti

Accedi al tuo cluster Discovery.
Accedere al nodo di dati.

Immettere il seguente comando:

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

Immetti il seguente comando, sostituendo <> e il contenuto all'interno con il numero di porta:
```
curl -X POST http://localhost:<port_number>/_cluster/health?pretty
```
Se non si conosce il numero di porta, immettere il seguente comando per trovarlo:
```
oc get pod -l app=elastic,ibm-es-data=True -o json \
| jq .items[].spec.containers[].ports[0].containerPort | head -n 1`
```
Il comando curl POST restituisce un valore per active_primary_shards. Se si dispone di un nodo di dati con un valore superiore a 1.000 o se si dispone di due nodi di dati con un valore superiore a 2.000, è necessario aumentare il limite di frammenti per creare nuovi progetti e raccolte nel cluster.

Se si aumenta questo limite, il cluster diventa meno stabile perché contiene un numero maggiore di frammenti.
Immettere il seguente comando per aumentare il numero di frammenti, sostituendo <port_number> con il proprio numero di porta e <total_shards_per_node> e <max_shards_per_node> con il nuovo limite di frammenti che si desidera assegnare 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'
```
Dopo aver aumentato il limite di frammenti, è possibile creare più progetti e raccolte sul cluster.

Rimozione di uno stato di blocco

IBM Cloud Pak for Data Solo installato: Quando il pod gateway si riavvia, esegue un plug-in di convalida del database che controlla le modifiche e applica i set di modifiche più recenti al database condiviso. Se il pod viene riavviato mentre è in corso questo controllo, il plug-in potrebbe rimanere in uno stato di blocco, impedendo l'avvio del servizio. Potrebbe essere necessario un intervento manuale sul database per cancellare il blocco.

Se l'API Discovery non è online o se il pod gateway-0 sembra essere in un ciclo di crash costante, si può provare a controllare i log del server Liberty per il servizio API, che si trovano qui: /opt/ibm/wlp/output/wdapi/logs/messages.log

I registri indicano se Liquibase non funziona e non è in grado di funzionare. Se il sistema è bloccato, potrebbe essere visualizzato qualcosa di simile al seguente:

[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

È possibile sbloccare manualmente il plugin. Se hai Discovery 2.1.4 o versioni precedenti, immetti il seguente comando sul database postgres che il pod gateway-0 sta esaminando:

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

Se si dispone di Discovery 2.2.0 o versione successiva, immettere il seguente comando sul database postgres che il pod gateway-0 sta esaminando:

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 poi si riavvia il pod gateway, tutto dovrebbe riprendere normalmente.

Impostazioni delle variabili di ambiente per Smart Document Understanding

Ci sono due variabili d'ambiente che devono essere regolate per Smart Document Understanding in IBM Watson® Discovery versione 2.1.0. Questo problema è stato risolto nella versione 2.1.1, vedi Release 2.1.1, 24 gennaio 2020.

SDU_PYTHON_REST_RESPONSE_TIMEOUT_MS
SDU_YOLO_TIMEOUT_SEC

Entrambe dovrebbero essere impostate sul rispettivo valore hour. Questi valori devono essere impostati nel sito <release-name>-watson-discovery-hdp ConfigMap.

I valori dovrebbero essere:

SDU_PYTHON_REST_RESPONSE_TIMEOUT_MS deve essere impostato su 3600000

SDU_YOLO_TIMEOUT_SEC deve essere impostato su 3600

Questi valori devono essere impostati quando il software viene installato o reinstallato.

Risoluzione dei messaggi di errore

Se ricevi messaggi di errore relativi a timeout e memoria insufficiente per i tuoi arricchimenti, puoi immettere i seguenti comandi per modificare le impostazioni di timeout e memoria per risolvere potenzialmente questi messaggi di errore:

Messaggio di avviso: <enrichment_name>: Document enrichment timed out

Azione consigliata: aumentare il timeout di elaborazione del documento. Immettere il seguente comando per aumentare il timeout predefinito da 10 a 20 minuti:
```
oc patch wd wd --type=merge \
--patch='{"spec": {"orchestrator": {"docproc": {"defaultTimeoutSeconds": 1200 } } } }'
```
Messaggio di avviso: <enrichment_name>: Document enrichment failed due to lack of memory

Azione consigliata: aumentare il limite di memoria del contenitore orchestrator. Immettere il seguente comando per aumentare il limite di memoria da 4 Gi a 6 Gi:
```
oc patch wd wd --type=merge \
--patch='{"spec": {"orchestrator": {"resources": {"limits": {"memory": "6Gi"} } } } }'
```
Messaggio di avviso: Indexing request timed out

Azione consigliata: aumentare il timeout per il push dei documenti a Elasticsearch. Immettere il seguente comando per aumentare il timeout predefinito da 10 a 20 minuti:
```
oc patch wd wd --type=merge \
--patch='{"spec": {"shared": {"elastic": {"publishTimeoutSeconds": 1200 } } } }'
```

Risoluzione dei problemi relativi alla cartuccia IBM Watson® Discovery per le distribuzioni IBM Cloud Pak® for Data

Risoluzione dei problemi relativi alla cartuccia IBM Watson® Discovery per le distribuzioni IBM Cloud Pak® for Data

I pod Minio immettono un loop di riavvio durante l'installazione o l'aggiornamento

Nel file di log viene visualizzato un messaggio No space left on device

Nel file di log viene visualizzato un messaggio java.lang.OutOfMemoryError: Java heap space

Impostazione del limite di frammenti in Discovery for Cloud Pak for Data

Aumento del limite di frammenti

Rimozione di uno stato di blocco

Impostazioni delle variabili di ambiente per Smart Document Understanding

Risoluzione dei messaggi di errore

Nel file di log viene visualizzato un messaggio `No space left on device`

Nel file di log viene visualizzato un messaggio `java.lang.OutOfMemoryError: Java heap space`