IBM Watson® Discovery Cartridge for IBM Cloud Pak® for Data デプロイメントのトラブルシューティング

製品の使用中に発生する可能性がある問題をトラブルシューティングして対処する方法について説明します。

IBM Cloud Pak for Data

この情報は、 IBM Cloud Pak® for Dataにインストールされている IBM Watson® Discovery のインスタンスにのみ適用されます。 インストール済みデプロイメントと管理対象デプロイメントの両方にデータを追加する際のトラブルシューティングのヒントについては、 取り込みのトラブルシューティング を参照してください。

このトピックの情報は、発生する可能性のある問題を調査するために実行できるステップを示しています。 既知の問題とバージョンごとの回避策については、 既知の問題 を参照してください。

インストールまたはアップグレード中に Minio ポッドがリブート・ループに入る

  • エラー: Discoveryのインストールまたはアップグレード中に Cannot find volume "export" to mount into container "ibm-minio" が表示されます。 When you check the status of the Minio pods by using the command, oc get pods -l release=wd-minio -o wide, and then check the Minio operator logs by using the commands, oc get pods -A | grep ibm-minio-operator, and then oc logs -n <namespace> ibm-minio-operator-XXXXX, you see an error similar to the following one in the 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"

  • 原因: 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 ポッドが正常に開始することを確認します。

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

No space left on device メッセージがログに表示されます。

wd-ibm-elasticsearch-es-server-client ポッドが繰り返し再始動して Crashloopbackoff 状態を報告し、そのポッドのログに No space left on device というメッセージが書き込まれる場合、問題はポッドのメモリー不足である可能性があります。 手順に従って メモリー不足の問題をトラブルシューティング するか、 IBM サポートに連絡してください。

java.lang.OutOfMemoryError: Java heap space メッセージがログに表示されます。

複数のエンリッチメントが適用されている大規模な文書セットに索引を付けると、ワーカー・ノードがスペース不足になる可能性があります。 この問題に対処するには、まず以下のステップを実行して、メモリー不足のポッドを判別します。

文書の状況を Processing にプロモートできない場合は、 inlet、 outlet、および converter の各ポッドの状況を確認します。

  1. 次のコマンドを実行します。

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

  2. いずれかのポッドが Running 状況を示していない場合は、以下のコマンドを使用して、失敗したポッドを再始動します。

    oc delete pod <pod_name>

  3. それ以外の場合は、 「コレクションの管理」>{collection name}>「アクティビティー」 ページを開きます。 「 Warnings and errors at a glance 」セクションでメッセージ「 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 ポッドが正常に再始動したら、「アクティビティー」タブで 「再処理」 をクリックします。

ドキュメントが Processing 状況のままで、コレクションの Available 状況にプロモートできない場合は、以下のステップを実行します。

  1. Hadoop のステータスを確認するには、次のコマンドを使用します

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

    ここで、 l はリストの小文字の L です。

  2. いずれかのポッドが Running 状況を示していない場合は、以下のコマンドを使用して、失敗したポッドを再始動します。

    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 ワーカー・ノードのメモリー・リソースを確認します。

    • オーケストレーター・コンテナーの "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 ポッドが正常に再始動されたかどうかを確認します。

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

  9. クラスターにパッチを適用した後に新しい構成が適用されたことを確認します。

  10. ポッドが再始動されない場合は、以下のコマンドを使用して、リソースが更新されたかどうかを確認します。

    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 クライアント・ポッドが再始動されます。 以下のコマンドを使用して、ポッドの「AGE」をモニターします。

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

  15. ポッドが正常に再始動されたら、以下のコマンドを使用して、 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 クライアント・ポッドが再始動されます。 以下のコマンドを使用して、ポッドの「AGE」をモニターします。

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

  19. ポッドが正常に再始動されたら、以下のコマンドを使用して、 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 に設定します。

    oc patch コマンドを適用して 30 分経過してもポッドを再始動できない場合は、以下のコマンドを使用してログを収集し、 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 つのデータ・ノードであり、これは 2,000 個の開いたノードと等しいので、データ・ノードあたり 1,000 個の開いたシャードとなります。 いずれかの制限に到達した後は、クラスター上にプロジェクトとコレクションをさらに作成することができません。新しいプロジェクトとコレクションの作成を試行すると、エラー・メッセージが表示されます。

この制限は、 Discovery バージョン 4.0 をインストールすると、 Elasticsearch バージョン 7.10.2 が自動的にクラスタ上で実行されるという事実によるものです。 このバージョンの Elasticsearch がクラスター上で実行されるので、Elasticsearch データ・ノードごとに開いているシャード数を 1,000 に制限する、新しいクラスター安定度の構成が使用可能になります。

新しいプロジェクトとコレクションを作成することができずに、エラーを受け取る場合は、まず Elasticsearch クラスターの状況と、そのクラスター上のシャード数を確認してください。 より多くのシャードをサポートするように、クラスター上のデータ・ノードの数を増やすことを検討します。 これは、パフォーマンスを最大化するために最適な方法です。 ただし、ノードの数を増やすとより多くのメモリーが使用されます。 シャードの数が制限に到達した場合、1 つのデータ・ノード内の制限を拡大することもできます。 ノード内のシャード制限を拡大する方法について詳しくは、シャード制限の拡大を参照してください。

この 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 よりも大きい 2 つのデータ・ノードがある場合、シャード制限を拡大して、クラスター内に新しいプロジェクトとコレクションを作成する必要があります。

    この制限を拡大すると、クラスターにはより多くのシャードが含まれるようになるので、その安定度は低下します。

  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 このチェックの処理中にポッドが再起動された場合、プラグインがロック状態のままとなり、サービスの開始が妨げられる可能性があります。 ロックを解除するには、手動でデータベースに介入する必要があるかもしれません。

Discovery API がオンラインにならない場合、または gateway-0 ポッドが常にクラッシュループ状態にあるように見える場合は、Liberty サーバーのログを以下に位置する API サービスについて確認してみてください。 /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 ポッドが参照している postgres データベースで以下のコマンドを入力します。

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

Discovery 2.2.0 以降がある場合は、 gateway-0 ポッドが参照している 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 ポッドを再起動できれば、すべてが通常通り再開するはずです。

Smart Document Understanding の環境変数の設定

IBM Watson® Discovery バージョン 2.1.0 では、Smart Document Understanding に関して調整が必要な 2 つの環境変数があります。 これは、バージョン 2.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 } } } }'