IBM Cloud Docs
对 IBM Watson® Discovery Cartridge for IBM Cloud Pak® for Data 部署进行故障诊断

对 IBM Watson® Discovery Cartridge for IBM Cloud Pak® for Data 部署进行故障诊断

了解对您在使用产品时可能迂到的问题进行故障诊断和解决的方法。

IBM Cloud Pak for Data

此信息仅适用于安装在 IBM Cloud Pak® for Data上的 IBM Watson® Discovery 实例。 有关向已安装的部署和受管部署添加数据的故障诊断提示，请参阅 对摄入进行故障诊断。

本主题中的信息建议您可以采取哪些步骤来调查可能发生的问题。 有关已知问题及其每个版本的变通方法的信息，请参阅 已知问题。

Minio pod 在安装或升级期间进入重新引导循环

  • 错误: Cannot find volume "export" to mount into container "ibm-minio" 在安装或升级 Discovery期间显示。 使用命令 oc get pods -l release=wd-minio -o wide 检查 Minio pod 的状态，然后使用命令 oc get pods -A | grep ibm-minio-operator 和 oc logs -n <namespace> ibm-minio-operator-XXXXX 检查 Minio operator 日志时，您会在日志中看到类似于以下的错误:

    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"

  • 原因: 未正确删除为 Minio 创建存储区然后在其完成后将其删除的作业。

  • 解决方案: 完成以下步骤以检查 Minio 的不完整 create-bucket 作业是否存在。 如果是这样，请删除不完整的作业，以便可以重新创建该作业，然后可以成功运行该作业。

    1. 使用以下命令检查 Minio 作业:

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

    2. 如果响应中列出了现有作业，请使用以下命令删除该作业:

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

    3. 使用以下命令验证所有 Minio pod 是否成功启动:

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

No space left on device 消息显示在日志中

如果 wd-ibm-elasticsearch-es-server-client pod 重复重新启动，然后报告 Crashloopbackoff 状态，并将消息 No space left on device 写入 pod 的日志，那么问题可能是 pod 上缺少内存。 请执行以下步骤 对内存不足问题进行故障诊断 或联系 IBM 支持人员。

java.lang.OutOfMemoryError: Java heap space 消息显示在日志中

对应用了多个扩充项的大量文档建立索引时，工作程序节点可能会耗尽空间。 要解决此问题，请首先通过完成以下步骤来确定哪个 pod 内存不足:

如果无法将文档状态提升到 Processing，请检查 inlet，outlet 和 converter pod 的状态。

  1. 运行以下命令：

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

  2. 如果任何 pod 未显示 Running 状态，请使用以下命令重新启动失败的 pod:

    oc delete pod <pod_name>

  3. 否则，打开“管理集合>{collection name}>活动”页面。 检查消息的 警告和错误概览 部分，OutOfMemory happened during conversion. Please reconsider size of documents. 如果显示，请使用以下命令来提高转换器的内存大小:

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

    根据集群资源调整 maxHeapMemory 和容器内存的值。

  4. 在 converter pod 成功重新启动后，单击“活动”选项卡中的 重新处理。

如果文档处于 Processing 状态，并且无法提升到集合的 Available 状态，请完成以下步骤:

  1. 使用以下命令检查 Hadoop 的状态:

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

    其中 l 是列表的小写 L。

  2. 如果任何 pod 未显示 Running 状态，请使用以下命令重新启动失败的 pod:

    oc delete pod <pod_name>

  3. 通过使用以下命令来查找 OOM when allocating 消息，检查任何 Hadoop 工作程序节点是否内存不足:

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

  4. 如果找到匹配项，请使用以下命令对资源进行补丁:

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

    pythonAnalyzerMaxMemory 允许的最大值为 12g。 缺省值为 6g。 根据集群资源，逐步增大该值，例如一次递增 2g。

  5. 通过使用以下命令来查找 OutOfMemoryError 消息，检查任何 Hadoop 工作程序节点是否内存不足:

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

  6. 如果找到匹配项，请使用以下命令来检查当前环境变量值和 Hadoop 工作程序节点内存资源:

    • 要在 Orchestrator 容器中检查 "DOCPROC_MAX_MEMORY" 变量，请执行以下操作:

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

    • 要在 Hadoop 工作程序节点容器中检查 "YARN_NODEMANAGER_RESOURCE_MEMORY_MB" 变量，请执行以下操作:

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

    • 要检查 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. 使用以下命令逐步修补环境变量资源:

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

    资源的缺省值如下所示:

    • docproc.maxMemory: 2g

      一次递增 2g。

    • nm.memoryMB: 10,240

      从 12,000 个开始，一次增加 2,000 个增量。

    • memory requests/limits: 13Gi/18Gi

      一次增加 2Gi 的增量。

  8. 使用以下命令检查 Hadoop pod 是否成功重新启动:

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

  9. 在修补集群之后，确认已应用新配置。

  10. 如果未重新启动 pod，请使用以下命令检查是否更新了资源:

    oc get wd wd -o yaml

  11. 通过分别检查客户机和数据节点来检查 Elasticsearch 的状态。

  12. 在客户机节点上，运行以下命令以检查是否发生内存不足异常:

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

  13. 如果发现错误消息 (不包括 INFO 消息)，请使用以下命令来增加内存资源:

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

  14. 运行此命令后，大约 20 分钟后将重新启动 Elasticsearch 客户机 pod。 使用以下命令监视 pod 的 "AGE":

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

  15. 成功重新启动 pod 后，请使用以下命令检查 ES_JAVA_OPTS 的新值和容器内存限制:

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

  16. 在数据节点上，运行以下命令以检查是否发生内存不足异常:

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

  17. 如果发现错误消息 (不包括 INFO 消息)，请使用以下命令来增加内存资源:

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

  18. 运行此命令后，大约 20 分钟后将重新启动 Elasticsearch 客户机 pod。 使用以下命令监视 pod 的 "AGE":

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

  19. 成功重新启动 pod 后，请使用以下命令检查 ES_JAVA_OPTS 的新值和容器内存请求/限制:

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

    对于两个节点 (客户机和数据)，将 resources.limits.memory 设置为等于 2 * maxHeap。

    如果在 30 分钟后无法通过应用 oc patch 命令重新启动 pod，请使用以下命令收集日志以与 IBM 支持人员共享:

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

对于这两个问题，如果无法将文档状态提升到 Processing，并且文档处于 Processing 状态，那么如果您正在使用 Portworx 存储器，那么可以检查 Elasticsearch 磁盘是否已满。

  1. 运行以下命令以检查 Elasticsearch 磁盘是否已满:

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

  2. 如果日志显示 watermark exceeded on x-data-1 之类的消息，那么表示指定节点上的磁盘已满，您需要使用以下命令来增大磁盘大小:

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

    其中 N 表示从日志中报告的数据节点号。

    例如，如果日志在节点名中提到 data-1，那么要使用的命令为:

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

在 Discovery for Cloud Pak for Data 中设置分片数限制

在 Discovery 版本 4.0中，可以在集群上保持打开状态的分片数存在限制。 在开发实例中，打开的分片数限制为 1,000 个，在生产实例中，限制为两个数据节点，相当于 2,000 个打开的分片，即每个数据节点 1,000 个打开的分片。 在达到以上任一限制后，就无法在集群上创建任何更多的项目和集合。如果尝试创建新的项目和集合，就会收到错误消息。

此限制是由于在安装 Discovery V 4.0时，Elasticsearch V 7.10.2 会自动在集群上运行。 由于此版本的 Elasticsearch 在集群上运行，因此新的集群稳定性配置变为可用，此配置将每个 Elasticsearch 数据节点的打开分片数限制为 1,000。

如果无法创建新的项目和集合，并且收到错误，请首先检查 Elasticsearch 集群的状态以及该集群上的分片数。 请考虑增加集群上的数据节点数，以支持更多分片。 此方法对于最大限度地提高性能是最佳的。 但是，增加的节点数越多，使用的内存也越多。 如果分片数达到限制，还可以增大数据节点中的分片数限制。 有关增大节点中分片数限制的更多信息，请参阅增大分片数限制。

此 1,000 个分片的限制适用于 4.0 或更高版本的 Discovery 版本。

增大分片限制

  1. 登录到 Discovery 集群。

  2. 访问数据节点。

  3. 输入以下命令：

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

  4. 输入以下命令，将 <> 和其中的内容替换为您的端口号:

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

    如果您不知道端口号，请输入以下命令进行查找：

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

    curl POST 命令会返回 active_primary_shards 的值。 如果您有一个数据节点且其值大于 1,000，或者有两个数据节点且其值大于 2,000，必须增大分片数限制，才能在集群中创建新的项目和集合。

    如果增大此限制，集群会变得较不稳定，因为集群包含了增加的分片数。

  5. 输入以下命令以增加分片数，将 <port_number> 替换为您的端口号，并将 <total_shards_per_node> 和 <max_shards_per_node> 替换为要分配给节点的新分片限制:

    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'

    增大分片数限制后，可以在集群上创建更多项目和集合。

清除锁定状态

IBM Cloud Pak for Data 仅安装: 当 gateway pod 重新启动时，它会运行数据库验证插件以检查更改并将最新的变更集应用于共享数据库。 如果在此检查过程中重新启动 pod，那么插件可能会保持锁定状态，从而阻止服务启动。 可能需要手动数据库干预才能清除锁定。

如果发现 API 未联机，或者 gateway-0 pod 似乎处于常量崩溃循环中，那么您可以尝试检查位于以下位置的 API 服务的 Liberty 服务器日志: /opt/ibm/wlp/output/wdapi/logs/messages.log

这些日志将指示 Liquibase 是否发生故障并且无法运行。 如果系统已锁定，那么您可能会看到类似于以下内容的内容:

[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

可以手动解锁插件。 如果您具有 Discovery 2.1.4 或更低版本，请在 gateway-0 pod 正在查看的 postgres 数据库上输入以下命令:

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

如果您具有 Discovery 2.2.0 或更高版本，请在 gateway-0 pod 正在查看的 postgres 数据库上输入以下命令:

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

如果您随后可以重新启动 gateway pod，那么应正常恢复所有内容。

智能文档理解的环境变量设置

需要为 IBM Watson® Discovery V 2.1.0中的“智能文档理解”调整两个环境变量。 该问题已在 V2.1.1 中解决，请参阅 2.1.1 发行版，2020 年 1 月 24 日。

SDU_PYTHON_REST_RESPONSE_TIMEOUT_MS
SDU_YOLO_TIMEOUT_SEC

这两个变量都应该设置为其各自的 hour 值。 必须在 <release-name>-watson-discovery-hdp ConfigMap中设置这些值。

值应该为：

SDU_PYTHON_REST_RESPONSE_TIMEOUT_MS 应设为 3600000

SDU_YOLO_TIMEOUT_SEC 应设为 3600

这两个值应该在安装或重新安装软件时进行设置。

对错误消息进行故障诊断

如果收到有关扩充项超时和内存不足的错误消息，可输入以下命令来更改超时和内存设置，这可能会解决这些错误消息问题：

  • 通知消息: <enrichment_name>: Document enrichment timed out

    建议操作：增加文档处理超时。 输入以下命令以将缺省超时从 10 分钟增加到 20 分钟：

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

  • 通知消息: <enrichment_name>: Document enrichment failed due to lack of memory

    建议操作：增大编排器容器内存限制。 输入以下命令以将内存限制从 4 Gi 增大到 6 Gi：

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

  • 通知消息：Indexing request timed out

    建议操作：增加用于将文档推送到 Elasticsearch 的超时。 输入以下命令以将缺省超时从 10 分钟增加到 20 分钟：

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