Fehlerbehebung für die IBM Watson® Discovery-Kassette für IBM Cloud Pak® for Data-Implementierungen

Hier erfahren Sie, wie Sie Probleme, die bei der Verwendung des Produkts auftreten können, beheben und beheben.

IBM Cloud Pak for Data

Diese Informationen gelten nur für Instanzen von IBM Watson® Discovery, die auf IBM Cloud Pak® for Datainstalliert sind. Tipps zur Fehlerbehebung beim Hinzufügen von Daten zu installierten und verwalteten Implementierungen finden Sie unter Fehlerbehebung bei der Aufnahme.

Die Informationen in diesem Abschnitt schlagen Schritte vor, die Sie ausführen können, um Probleme zu untersuchen, die möglicherweise auftreten. Informationen zu bekannten Problemen und ihren Fehlerumgehungen pro Version finden Sie unter Bekannte Probleme.

Minio-Pods treten während der Installation oder des Upgrades in eine Warmstartschleife ein

  • Fehler: Während einer Installation oder eines Upgrades von Discoverywird Cannot find volume "export" to mount into container "ibm-minio" angezeigt Wenn Sie den Status der Minio-Pods mit dem Befehl oc get pods -l release=wd-minio -o wide und anschließend die Minio operator-Protokolle mit den Befehlen oc get pods -A | grep ibm-minio-operator und oc logs -n <namespace> ibm-minio-operator-XXXXX überprüfen, wird ein Fehler ähnlich dem folgenden in den Protokollen angezeigt:

    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"

  • Ursache: Ein Job, der ein Speicherbucket für Minio erstellt und anschließend gelöscht wird, wird nicht ordnungsgemäß gelöscht.

  • Lösung: Führen Sie die folgenden Schritte aus, um zu überprüfen, ob ein unvollständiger create-bucket-Job für Minio vorhanden ist. Ist dies der Fall, löschen Sie den unvollständigen Job, damit der Job erneut erstellt und anschließend erfolgreich ausgeführt werden kann.

    1. Verwenden Sie den folgenden Befehl, um den Minio-Job zu suchen:

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

    2. Wenn ein vorhandener Job in der Antwort aufgelistet ist, löschen Sie den Job mit dem folgenden Befehl:

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

    3. Überprüfen Sie mit dem folgenden Befehl, ob alle Minio-Pods erfolgreich gestartet wurden:

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

Im Protokoll wird eine Nachricht No space left on device angezeigt.

Wenn der Pod wd-ibm-elasticsearch-es-server-client wiederholt neu gestartet wird und anschließend den Status Crashloopbackoff meldet, wobei die Nachricht No space left on device in das Protokoll für den Pod geschrieben wird, kann das Problem auf einen Speichermangel im Pod zurückzuführen sein. Führen Sie die Schritte zum Beheben von Problemen aufgrund abnormaler Speicherbedingungen aus oder wenden Sie sich an den IBM Support.

Im Protokoll wird eine Nachricht java.lang.OutOfMemoryError: Java heap space angezeigt.

Bei der Indexierung einer großen Gruppe von Dokumenten, auf die mehrere Aufbereitungen angewendet wurden, kann der Speicherplatz auf dem Workerknoten ausgehen. Um das Problem zu beheben, stellen Sie zunächst fest, welcher Pod nicht mehr über ausreichend Speicherplatz verfügt, indem Sie die folgenden Schritte ausführen:

Wenn der Dokumentstatus nicht auf Processing hochgestuft werden kann, überprüfen Sie den Status der Pods inlet, outlet und converter.

  1. Führen Sie den folgenden Befehl aus:

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

  2. Wenn einer der Pods keinen Running-Status aufweist, starten Sie den fehlgeschlagenen Pod mit dem folgenden Befehl neu:

    oc delete pod <pod_name>

  3. Andernfalls öffnen Sie die Seite Sammlungen verwalten>{collection name}>Aktivität. Überprüfen Sie den Abschnitt Warnungen und Fehler auf einen Blick auf die Nachricht OutOfMemory happened during conversion. Please reconsider size of documents. Verwenden Sie bei Anzeige den folgenden Befehl, um die Speicherkapazität für den Converter zu erhöhen:

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

    Passen Sie den Wert von maxHeapMemory und den Containerspeicher an Ihre Clusterressourcen an.

  4. Nachdem der Pod converter erfolgreich erneut gestartet wurde, klicken Sie auf der Registerkarte "Aktivität" auf Erneut verarbeiten.

Wenn Dokumente im Status Processing blockiert sind und nicht in den Status Available für eine Objektgruppe hochgestuft werden können, führen Sie die folgenden Schritte durch:

  1. Überprüfen Sie den Status von Hadoop mit dem folgenden Befehl:

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

    Dabei ist l ein kleines L für die Liste.

  2. Wenn einer der Pods keinen Running-Status aufweist, starten Sie den fehlgeschlagenen Pod mit dem folgenden Befehl neu:

    oc delete pod <pod_name>

  3. Überprüfen Sie, ob einer der Hadoop-Workerknoten nicht über ausreichend Speicher verfügt, indem Sie mit dem folgenden Befehl nach der Nachricht OOM when allocating suchen:

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

  4. Wenn eine Übereinstimmung gefunden wird, verwenden Sie den folgenden Befehl, um die Ressource zu patchen:

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

    Der maximal zulässige Wert für pythonAnalyzerMaxMemory ist 12g. Der Standardwert ist 6g. Erhöhen Sie den Wert schrittweise, z. B. in Inkrementen von 2g gleichzeitig entsprechend Ihren Clusterressourcen.

  5. Überprüfen Sie, ob einer der Hadoop-Workerknoten nicht über ausreichend Speicher verfügt, indem Sie mit dem folgenden Befehl nach der Nachricht OutOfMemoryError suchen:

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

  6. Wenn eine Übereinstimmung gefunden wird, überprüfen Sie die aktuellen Umgebungsvariablenwerte und die Hadoop-Workerknotenspeicherressourcen mit den folgenden Befehlen:

    • Gehen Sie wie folgt vor, um die Variable "DOCPROC_MAX_MEMORY" im Orchestrator-Container zu überprüfen:

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

    • Gehen Sie wie folgt vor, um die Variable "YARN_NODEMANAGER_RESOURCE_MEMORY_MB" im Workerknotencontainer Hadoop zu überprüfen:

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

    • Gehen Sie wie folgt vor, um die Speicherressource des Containers hdp-worker zu überprüfen:

      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. Verwenden Sie den folgenden Befehl, um die Ressourcen der Umgebungsvariablen schrittweise zu korrigieren:

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

    Die Standardwerte für die Ressourcen lauten wie folgt:

    • docproc.maxMemory: 2g

      Erhöhung in Inkrementen von 2g gleichzeitig.

    • nm.memoryMB: 10,240

      Beginnen Sie bei 12.000 und erhöhen Sie den Wert in Schritten von jeweils 2.000.

    • memory requests/limits: 13Gi/18Gi

      Erhöhung in Inkrementen von 2Gi gleichzeitig.

  8. Überprüfen Sie mit dem folgenden Befehl, ob die Hadoop-Pods erfolgreich erneut gestartet werden können:

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

  9. Bestätigen Sie, dass die neuen Konfigurationen angewendet wurden, nachdem Sie den Cluster korrigiert haben.

  10. Wenn der Pod nicht neu gestartet wird, prüfen Sie mit dem folgenden Befehl, ob die Ressource aktualisiert wurde:

    oc get wd wd -o yaml

  11. Überprüfen Sie den Status von Elasticsearch, indem Sie die Client-und Datenknoten separat überprüfen.

  12. Führen Sie auf dem Clientknoten den folgenden Befehl aus, um zu überprüfen, ob eine Ausnahmebedingung aufgrund abnormaler Speicherbedingungen aufgetreten ist:

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

  13. Wenn eine Fehlernachricht mit Ausnahme von INFO-Nachrichten gefunden wird, erhöhen Sie die Speicherressource mit dem folgenden Befehl:

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

  14. Nach der Ausführung dieses Befehls wird der Elasticsearch-Client-Pod ungefähr 20 Minuten später erneut gestartet. Überwachen Sie das "AGE" des Pods mit dem folgenden Befehl:

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

  15. Überprüfen Sie nach dem erfolgreichen Neustart des Pods den neuen Wert von ES_JAVA_OPTS und die Containerspeicherbegrenzung mit dem folgenden Befehl:

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

  16. Führen Sie auf dem Datenknoten den folgenden Befehl aus, um zu überprüfen, ob eine Ausnahmebedingung aufgrund abnormaler Speicherbedingungen aufgetreten ist:

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

  17. Wenn eine Fehlernachricht mit Ausnahme von INFO-Nachrichten gefunden wird, erhöhen Sie die Speicherressource mit dem folgenden Befehl:

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

  18. Nach der Ausführung dieses Befehls wird der Elasticsearch-Client-Pod ungefähr 20 Minuten später erneut gestartet. Überwachen Sie das "AGE" des Pods mit dem folgenden Befehl:

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

  19. Nachdem der Pod erfolgreich erneut gestartet wurde, überprüfen Sie den neuen Wert von ES_JAVA_OPTS und den Wert für die Containerspeicheranforderungen/-begrenzung mit dem folgenden Befehl:

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

    Legen Sie für beide Knoten (Client und Daten) für resources.limits.memory den Wert 2 * maxHeap fest.

    Wenn der Pod nach 30 Minuten nicht erneut gestartet werden kann, indem der Befehl oc patch angewendet wird, erfassen Sie Protokolle, um sie mit dem IBM Support gemeinsam zu nutzen, indem Sie den folgenden Befehl verwenden:

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

Bei beiden Problemen, bei denen der Dokumentstatus nicht auf Processing hochgestuft werden kann und bei denen Dokumente im Status Processing verbleiben, können Sie bei Verwendung des Portworx-Speichers prüfen, ob die Elasticsearch-Platte voll ist.

  1. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob die Festplatte Elasticsearch voll ist:

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

  2. Wenn das Protokoll eine Nachricht wie watermark exceeded on x-data-1 anzeigt, bedeutet dies, dass die Platte auf dem angegebenen Knoten voll ist und Sie die Plattengröße mit dem folgenden Befehl erhöhen müssen:

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

    Dabei steht N für die Datenknotennummer, die aus dem Protokoll gemeldet wurde.

    Wenn das Protokoll beispielsweise data-1 im Knotennamen erwähnt, lautet der zu verwendende Befehl:

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

Shard-Grenzwert in Discovery for Cloud Pak for Data festlegen

In der Discovery-Version 4.0 gibt es eine Begrenzung der Anzahl von Shards, die auf einem Cluster geöffnet bleiben können. In Entwicklungsinstanzen beträgt der Grenzwert 1.000 offene Shards und in Produktionsinstanzen beträgt der Grenzwert zwei Datenknoten, die 2.000 offenen Shards oder 1.000 offenen Shards pro Datenknoten entsprechen. Nachdem Sie einen der Grenzwerte erreicht haben, können Sie keine weiteren Projekte und Sammlungen in Ihrem Cluster erstellen. Wenn Sie versuchen, ein neues Projekt und eine neue Sammlung zu erstellen, erhalten Sie eine Fehlernachricht.

Diese Beschränkung ist darauf zurückzuführen, dass bei der Installation von Discovery Version 4.0 automatisch Elasticsearch Version 7.10.2 auf Ihren Clustern ausgeführt wird. Da diese Version von Elasticsearch in Ihren Clustern ausgeführt wird, wird eine neue Konfiguration für die Clusterstabilität verfügbar, die die Anzahl der offenen Shards für jeden Elasticsearch-Datenknoten auf 1.000 begrenzt.

Wenn Sie keine neuen Projekte und Sammlungen erstellen können und Fehlernachrichten erhalten, überprüfen Sie zunächst den Status Ihres Elasticsearch-Clusters und die Anzahl der Shards in diesem Cluster. Ziehen Sie in Betracht, die Anzahl der Datenknoten in Ihrem Cluster zu erhöhen, um mehr Shards zu unterstützen. Diese Methode ist optimal für die Leistungsmaximierung geeignet. Eine größere Anzahl an Knoten verbraucht jedoch auch mehr Speicher. Wenn die Anzahl der Shards den Grenzwert erreicht, können Sie auch den Grenzwert in einem Datenknoten erhöhen. Weitere Informationen zur Erhöhung des Shard-Grenzwerts in einem Knoten finden Sie in Shard-Grenzwert erhöhen.

Dieser Grenzwert von 1.000 Shards gilt für Versionen von Discovery ab Version 4.0.

Shard-Grenzwert erhöhen

  1. Melden Sie sich am Discovery-Cluster an.

  2. Greifen Sie auf Ihren Datenknoten zu.

  3. Geben Sie den folgenden Befehl ein:

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

  4. Geben Sie den folgenden Befehl ein und ersetzen Sie dabei <> und den Inhalt durch Ihre Portnummer:

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

    Wenn Sie nicht wissen, wie Ihre Portnummer lautet, geben Sie den folgenden Befehl ein, um diese zu ermitteln:

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

    Der curl-Befehl POST gibt den Wert für active_primary_shards zurück. Wenn Sie über einen Datenknoten verfügen, der einen Wert über 1.000 aufweist oder wenn Sie über zwei Datenknoten verfügen, die zusammen einen Wert über 2.000 aufweisen, müssen Sie den Shard-Grenzwert erhöhen, um neue Projekte und Sammlungen in Ihrem Cluster erstellen zu können.

    Wenn Sie diesen Grenzwert erhöhen, leidet die Stabilität des Clusters darunter, da es nun eine höhere Anzahl an Shards enthält.

  5. Geben Sie den folgenden Befehl ein, um die Anzahl der Shards zu erhöhen, und ersetzen Sie dabei <port_number> durch Ihre Portnummer und <total_shards_per_node> und <max_shards_per_node> durch die neue Shard-Grenze, die Sie einem Knoten zuweisen möchten:

    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'

    Nachdem Sie den Shard-Grenzwert erhöht haben, können Sie weitere Projekte und Sammlungen in Ihrem Cluster erstellen.

Sperrstatus aufheben

IBM Cloud Pak for Data Nur installiert: Wenn der gateway-Pod neu gestartet wird, führt er ein Datenbankvalidierungs-Plug-in aus, das nach Änderungen sucht und die neuesten Änderungssätze auf die gemeinsam genutzte Datenbank anwendet. Wenn die Pod-Einheit neu gestartet wird, während diese Prüfung läuft, bleibt das Plug-in möglicherweise im Sperrzustand, sodass der Dienst nicht gestartet werden kann. Möglicherweise ist ein manueller Eingriff in die Datenbank erforderlich, um die Sperre aufzuheben.

Wenn die Discovery-API nicht online geht oder der gateway-0-Pod so aussieht, als würde er ständig abstürzen, können Sie versuchen, die Liberty-Serverprotokolle für den API-Dienst hier zu überprüfen: /opt/ibm/wlp/output/wdapi/logs/messages.log

Die Protokolle würden anzeigen, ob Liquibase ausfällt und nicht ausgeführt werden kann. Wenn das System gesperrt ist, sehen Sie möglicherweise etwas Ähnliches wie das Folgende:

[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

Das Plug-in kann manuell entsperrt werden. Wenn Discovery 2.1.4 oder früher vorhanden ist, geben Sie den folgenden Befehl in der Postgres-Datenbank ein, die der gateway-0-Pod betrachtet:

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

Wenn Sie Discovery 2.2.0 oder höher haben, geben Sie den folgenden Befehl in der Postgres-Datenbank ein, die der gateway-0-Pod betrachtet:

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

Wenn Sie dann den gateway-Pod neu starten können, sollte alles wieder normal funktionieren.

Umgebungsvariableneinstellungen für Smart Document Understanding

Es gibt zwei Umgebungsvariablen, die für Smart Document Understanding in IBM Watson® Discovery Version 2.1.0 angepasst werden müssen. Dieses Problem wurde in Version 2.1.1 behoben. Weitere Informationen finden Sie in Release 2.1.1, 24. Januar 2020.

SDU_PYTHON_REST_RESPONSE_TIMEOUT_MS
SDU_YOLO_TIMEOUT_SEC

Beide Variablen auf den jeweiligen Stundenwert (hour) gesetzt werden. Diese Werte müssen in <release-name>-watson-discovery-hdp ConfigMap eingestellt werden.

Die Werte sollten wie folgt lauten:

SDU_PYTHON_REST_RESPONSE_TIMEOUT_MS Festzulegende Einstellung 3600000

SDU_YOLO_TIMEOUT_SEC Festzulegende Einstellung 3600

Diese Werte sollten festgelegt werden, wenn die Software installiert oder erneut installiert wird.

Fehlerbehebung bei Fehlernachrichten

Wenn Sie Fehlernachrichten erhalten, die sich auf Zeitlimitüberschreitungen und zu wenige Speicherplatz für Ihre Aufbereitungen beziehen, können Sie die folgenden Befehle eingeben, um den Zeitlimitwert und die Speichereinstellungen zu ändern und so möglicherweise die Ursache für die Fehlernachrichten beheben:

  • Hinweis: <enrichment_name>: Document enrichment timed out

    Vorgeschlagene Aktion: Erhöhen Sie den Zeitlimitwert für die Dokumentverarbeitung. Geben Sie den folgenden Befehl ein, um das Standardzeitlimit von 10 auf 20 Minuten zu erhöhen:

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

  • Hinweis: <enrichment_name>: Document enrichment failed due to lack of memory

    Vorgeschlagene Aktion: Erhöhen Sie den Speichergrenzwert für den Orchestratorcontainer. Geben Sie den folgenden Befehl ein, um den Speichergrenzwert von 4 auf 6 Gi zu erhöhen.

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

  • Hinweisnachricht: Indexing request timed out

    Vorgeschlagene Aktion: Erhöhen Sie den Zeitlimitwert für die Durchführung von Push-Operationen für Dokumente zu Elasticsearch. Geben Sie den folgenden Befehl ein, um das Standardzeitlimit von 10 auf 20 Minuten zu erhöhen:

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