機械翻訳について

ドメインのデバッグ

ドメインまたはクラスタのYAMLファイルのデプロイ後にドメインの問題をデバッグするための提案を次に示します。

目次

失敗のタイプ、重大度およびチューニングの理解

デバッグする際は、失敗タイプ、失敗の重大度、再試行動作およびチューニングの再試行を理解するのに役立ちます。「ドメイン失敗再試行処理」を参照してください。 これらは、リソース・ステータス、イベント、イントロスペクタ・ジョブおよびポッドでレポートされた失敗に適用されます。

ドメイン・ステータスの確認

ドメイン・ステータスを確認するには: kubectl -n MY_NAMESPACE describe domain MY_DOMAIN_RESOURCE_NAME 詳細は、「ドメイン条件」を参照してください。

ノート.status.observedGeneration.metadata.generationと等しくない場合、これは、.specまたは.metadataに対する最新の変更に関して、ステータスが最新ではないことを示します。 オペレータがステータスの更新処理中であるか、オペレータが実行中ではありません。

クラスタ・ステータスの確認

クラスタ・リソースをデプロイしている場合は、オプションでkubectl -n MY_NAMESPACE describe cluster MY_CLUSTER_NAMEを使用して各リソースのステータスを確認できます。

同じ情報がdomain.status.clustersの下のDomainリソースのステータスで報告されます。 詳細は、「クラスタ条件」を参照してください。

ノート: 特定のクラスタ・ステータスの.observedGenerationが、対応するクラスタ・リソースの.metadata.generationと等しくない場合、これは、.specまたは.metadataに対する最新の変更に関して、ステータスが最新ではないことを示します。 オペレータがステータスの更新処理中であるか、オペレータが実行中ではありません。

ドメイン・イベントの確認

ドメインのイベントを確認するには: kubectl -n MY_NAMESPACE get events --sort-by='.lastTimestamp'

詳細は、「ドメイン・イベント」を参照してください。

イントロスペクタ・ジョブの確認

イントロスペクタ・ジョブが失敗した場合は、ジョブとそのポッドのkubectl describeを調べ、ログ(存在する場合)も調べます。

失敗のデバッグ中にイントロスペクタ・ジョブが再試行されないようにするには、domain.spec.failureRetryLimitMinutes0に構成します。 詳細は、「ドメイン失敗再試行処理」を参照してください。

たとえば、ドメインUIDがsample-domain1で、ドメイン・ネームスペースがsample-domain1-nsであるとします。

ここでは、ドメインのポッド間に失敗したイントロスペクタ・ジョブ・ポッドが表示されます:

$ kubectl -n sample-domain1-ns get pods -l weblogic.domainUID=sample-domain1
NAME                                         READY   STATUS    RESTARTS   AGE
sample-domain1-admin-server                  1/1     Running   0          19h
sample-domain1-introspector-v2l7k            0/1     Error     0          75m
sample-domain1-managed-server1               1/1     Running   0          19h
sample-domain1-managed-server2               1/1     Running   0          19h
  • まず、ジョブのdescribeコマンドの出力を確認します。

    $ kubectl -n sample-domain1-ns describe job/sample-domain1-introspector
    
  • 次に、ジョブのポッドdescribe出力を確認します。特に、そのeventsを参照してください。

    $ kubectl -n sample-domain1-ns describe pod/sample-domain1-introspector-v2l7k
    
  • 最後に、ジョブのポッドのログを確認します。

    $ kubectl -n sample-domain1-ns logs job/sample-domain1-introspector
    
  • 前述のコマンドと同じ出力を持つ代替のログ・コマンドを次に示します。$ kubectl -n sample-domain1-ns logs pod/sample-domain1-introspector-v2l7k

Model in Imageドメインでイントロスペクタ・ジョブが失敗する一般的な理由は、モデル・ファイルのエラーが原因です。 このような失敗を示すイントロスペクタ・ジョブからのサンプル・ログ出力を次に示します:

 ...

 SEVERE Messages:
       1. WLSDPLY-05007: Model file /u01/wdt/models/model1.yaml,/weblogic-operator/wdt-config-map/..2020_03_19_15_43_05.993607882/datasource.yaml contains an unrecognized section: TYPOresources. The recognized sections are domainInfo, topology, resources, appDeployments, kubernetes

イントロスペクタ・ログは、spec.logHomeが構成され、spec.logHomeEnabledがtrueの場合、ドメイン・リソースのspec.logHomeディレクトリにミラー化されます。

モデル・ファイル・エラーがspec.configuration.model.configMapのモデル・ファイルを参照している場合は、修正したモデル・ファイルを使用してConfigMapを再デプロイし、ドメインの再起動またはロールを開始することでエラーを修正できます。 同様に、モデル・ファイル・エラーがモデル・イメージ内のモデル・ファイルを参照している場合は、修正したイメージをデプロイし、新しいイメージを参照するようにドメインYAMLファイルを変更してから、ドメインの再起動またはロールを開始することでエラーを修正できます。

WebLogic Serverポッドの確認

イントロスペクタ・ジョブが成功した場合、イントロスペクタ・ジョブまたはポッドは存在せず、オペレータがドメインのMY_DOMAIN_UID-weblogic-domain-introspect-cm ConfigMapを作成し、オペレータがドメインのWebLogic Serverポッドを実行します。

kubectl -n MY_NAMESPACE get podsでWebLogic Serverポッドにエラーがあることが判明した場合は、kubectl -n MY_NAMESPACE describe pod POD_NAMEkubectl -n MY_NAMESPACE logs POD_NAMEまたはkubectl -n MY_NAMESPACE get events --sort-by='.lastTimestamp'(あるいはその両方)を使用してデバッグします。

実行中のドメインのWebLogic構成に対してオンライン更新を実行する場合は、「オンライン更新ステータスとラベル」を参照してください。

ドキュメントの確認

対応するドキュメントがある一般的な問題は次のとおりです:

  • ドメインまたはクラスタのYAMLファイルがデプロイされ、イントロスペクタまたはWebLogic Serverポッドが起動せず、さらにオペレータ・ログにドメインに関する記述が含まれていない場合は、オペレータによって監視されるようにドメインのネームスペースが設定されていることを確認してください。 オペレータ「ネームスペース管理」およびオペレータ「よくある間違いと解決策」のドキュメントを参照してください。
  • イントロスペクタ・ジョブまたはWebLogic Serverポッドのdescribeでイメージ・アクセス・エラーが表示される場合は、「イメージをプルできません」のFAQを参照してください。

オペレータの確認

問題がオペレータ自体またはネームスペース管理に固有である場合は、オペレータ「トラブルシューティング」のドキュメントを参照してください。