アップグレード後のチェックおよびトラブルシューティング post-upgrade-checks-and-troubleshooting

アップグレード後のチェック post-upgrade-checks

次に インプレースアップグレード アップグレードを完了するには、次のアクティビティを実行する必要があります。 AEMが 6.5 jar で起動され、アップグレードされたコードベースがデプロイされていることを前提としています。

ログでアップグレードの成功を確認する verify-logs-for-upgrade-success

upgrade.log

以前は、インスタンスのアップグレード後の状態を調べるには、様々なログファイル、リポジトリの一部、ランチパッドを慎重に調べる必要がありました。 アップグレード後のレポートを生成すると、運用開始前に欠陥のあるアップグレードを検出するのに役立ちます。

この機能の主な目的は、アップグレードの成功を検証するために必要な、複数のエンドポイントにわたる手動の解釈や複雑な解析ロジックの必要性を減らすことです。 このソリューションは、外部の自動化システムが更新の成功または特定された失敗に対応するための明確な情報を提供することを目的としています。

具体的には、次のことが可能です。

これに対応するために、でログを生成する方法が変更されました upgrade.log ファイル。

アップグレード中にエラーが発生しなかったことを示すサンプルレポートを次に示します。

アップグレードプロセスでインストールされなかったバンドルを示すサンプルレポートを次に示します。

error.log

target version jar を使用したAEMの起動中および起動後は、error.log を慎重に確認する必要があります。 警告やエラーがあれば、確認する必要があります。 一般に、ログの先頭で問題を探すのが最適です。 ログの後半で発生するエラーは、実際には、ファイルの前半で呼び出される根本原因の副作用である可能性があります。 エラーや警告を繰り返し発生する場合は、以下を参照してください。 アップグレードに関する問題の分析.

OSGi バンドルの確認 verify-osgi-bundles

OSGi コンソール /system/console/bundles に移動し、開始されていないバンドルがあるかどうかを確認します。いずれかのバンドルがインストール済み状態の場合は、 error.log を参照して、根本的な問題を判断します。

Oak バージョンの確認 verify-oak-version

アップグレード後、Oak バージョンがに更新されたことを確認できます。 1.10.2. Oak バージョンを確認するには、OSGi コンソールに移動し、Oak バンドル（Oak Core、Oak Commons、Oak Segment Tar）に関連付けられたバージョンを調べます。

PreUpgradeBackup フォルダーの検査 inspect-preupgradebackup-folder

アップグレード中、AEMはカスタマイズのバックアップを作成して、の下に格納することを試みます /var/upgrade/PreUpgradeBackup/<time-stamp-of-upgrade>. このフォルダーをCRXDE Liteで表示するには、次が必要な場合があります。 CRXDE Liteを一時的に有効にする.

タイムスタンプがあるフォルダーには、mergeStatus という名前のプロパティがあり、COMPLETED という値である必要があります。この to-process フォルダーは空で、かつ 上書き ノードは、アップグレード中に上書きされたノードを示します。 残余ノードの下のコンテンツは、アップグレード中に安全に結合できなかったコンテンツを示します。 実装が子ノードのいずれかに依存している場合（およびアップグレードされたコードパッケージによってまだインストールされていない場合）、手動で結合する必要があります。

ステージング環境または実稼動環境の場合は、この演習の後でCRXDE Liteを無効にします。

ページの初期検証 initial-validation-of-pages

AEMで複数のページに対して初期検証を実行します。 オーサー環境をアップグレードする場合は、開始ページとようこそページ（/aem/start.html、/libs/cq/core/content/welcome.html）を開きます。オーサー環境とパブリッシュ環境の両方で、アプリケーションページをいくつか開き、正しくレンダリングされるかどうかスモークテストをおこないます。 問題が発生した場合は、error.log を調べてトラブルシューティングをおこないます。

AEM サービスパックの適用 apply-aem-service-packs

関連するAEM 6.5 サービスパックがリリースされている場合は、それらをすべて適用します。

AEM機能の移行 migrate-aem-features

AEMのいくつかの機能では、アップグレード後に追加の手順が必要です。 これらの機能と、AEM 6.5 に移行するための手順の完全なリストは、次にあります コードのアップグレードとカスタマイズ ページ。

スケジュールされたメンテナンス設定の確認 verify-scheduled-maintenance-configurations

データストアのガベージコレクションを有効にする enable-data-store-garbage-collection

ファイルデータストアを使用する場合は、データストアのガベージコレクションタスクが有効になっていて、週別メンテナンスリストに追加されていることを確認します。 説明は こちら を参照してください。

オンラインでのリビジョンクリーンアップの有効化 enable-online-revision-cleanup

MongoMK または新しい TarMK セグメント形式を使用する場合は、リビジョンのクリーンアップタスクが有効になっていて、日別メンテナンスリストに追加されていることを確認します。 説明 こちら.

テスト計画の実行 execute-test-plan

定義されたとおりに詳細なテスト計画を実行 コードのアップグレードとカスタマイズ の下 テスト手順 セクション。

レプリケーションエージェントの有効化 enable-replication-agents

パブリッシュ環境が完全にアップグレードおよび検証されたら、オーサー環境でレプリケーションエージェントを有効にします。 エージェントがそれぞれのパブリッシュインスタンスに接続できることを確認します。 イベントの順序について詳しくは、アップグレード手順を参照してください。

スケジュール済みカスタムジョブの有効化 enable-custom-scheduled-jobs

この時点で、コードベースの一部としてスケジュールされたジョブを有効にできます。

アップグレードに関する問題の分析 analyzing-issues-with-upgrade

ここでは、AEM 6.3 へのアップグレード手順の中で発生する可能性のあるいくつかの問題について説明します。

これらのシナリオは、アップグレードに関連する問題の根本原因を追跡するのに役立ち、プロジェクトまたは製品固有の問題を特定するのに役立ちます。

リポジトリの移行に失敗する repository-migration-failing-

CRX2 から Oak へのデータ移行は、CQ 5.4 に基づいたソースインスタンスから始まるあらゆるシナリオで実行可能です。このドキュメントのアップグレード手順（の準備を含む）に確実に従ってください。 repository.xml、JAAS 経由でカスタム認証システムが起動されていないことと、移行を開始する前にインスタンスの不整合がチェックされていることを確認します。

それでも移行が失敗する場合は、を調べて根本原因を解明することができます。 upgrade.log. 問題が解決しない場合は、カスタマーサポートに報告してください。

アップグレードは実行されませんでした the-upgrade-did-not-run

準備手順を開始する前に、必ずを実行してください ソース インスタンスを最初に実行するには、Java™ -jar aem-quickstart.jar コマンドを使用します。 これは、quickstart.properties ファイルが正しく生成されていることを確認するために必要です。 ない場合、アップグレードは機能しません。 あるいは、ソースインスタンスのインストールフォルダーの crx-quickstart/conf の下を探して、このファイルが存在するかどうかを確認します。また、AEMを起動してアップグレードを開始する場合は、Java™ -jar aem-quickstart.jar コマンドを使用してアップグレードを実行する必要があります。 開始スクリプトから起動しても、AEMはアップグレードモードでは起動しません。

パッケージとバンドルの更新に失敗する packages-and-bundles-fail-to-update-

アップグレード中にパッケージのインストールに失敗した場合、パッケージに含まれるバンドルも更新されません。 このカテゴリの問題は、データストアの設定ミスが原因で発生します。 また、次のように表示されます エラー および 警告 error.log のメッセージ。 ほとんどの場合、デフォルトのログインが機能しないことがあるので、CRXDE を直接使用して設定の問題を調べ、見つけることができます。

一部のAEM バンドルがアクティブ状態に切り替わっていません some-aem-bundles-are-not-switching-to-the-active-state

起動していないバンドルがある場合は、依存関係が満たされていないかどうかを確認します。

この問題が発生するケースは、パッケージインストールの失敗に基づいています。この場合、バンドルはアップグレードされず、新しいバージョンと互換性がないと見なされます。 このトラブルシューティング方法の詳細については、を参照してください。 パッケージとバンドルの更新に失敗する 上。

また、新しいAEM 6.5 インスタンスのバンドルリストと、アップグレードされたインスタンスを比較して、アップグレードされなかったバンドルを検出することもお勧めします。 この比較によって、error.log で検索すべき問題を絞り込むことができます。

カスタムバンドルがアクティブ状態に切り替わっていない custom-bundles-not-switching-to-the-active-state

カスタムバンドルがアクティブ状態に切り替わらない場合は、change API を読み込んでいないコードが存在する可能性が最も高くなります。 これは、ほとんどの場合、満足できない依存関係につながります。

削除された API は、以前のリリースの 1 つで非推奨（廃止予定）としてマークされる必要があります。 コードの直接移行に関する手順は、この非推奨（廃止予定）通知に記載されています。 Adobeは、可能な場合、セマンティックバージョニングを目的としているので、バージョンが重大な変更を示す可能性があります。

また、問題を引き起こした変更が必要かどうかを確認し、必要でない場合は元に戻すことをお勧めします。 また、パッケージの書き出しのバージョン増加が、厳密なセマンティックバージョニングに従って、必要以上に増加したかどうかも確認します。

Platform UI が正しく機能しない malfunctioning-platform-ui

アップグレード後に UI の特定の機能が正しく動作しない場合は、まずインターフェイスのカスタムオーバーレイを確認する必要があります。 一部の構造が変更され、オーバーレイが更新を必要とするか、古くなっている可能性があります。

次に、クライアントライブラリにフックされるカスタムの追加拡張機能まで追跡できる JavaScript エラーがないか確認します。 AEM レイアウトに問題を引き起こす可能性のあるカスタム CSS に対しても、同じことが当てはまります。

最後に、JavaScript で処理できない可能性のある設定ミスがないか確認します。 これは通常、拡張機能が適切に非アクティブ化されていない場合に発生します。

カスタムコンポーネント、テンプレートまたは UI 拡張機能の誤動作 malfunctioning-custom-components-templates-or-ui-extensions

通常、これらの問題の根本原因は、開始されていないバンドルやインストールされていないパッケージの場合と同じですが、コンポーネントを最初に使用したときに問題が発生し始める点が異なります。

誤ったカスタムコードに対処する方法は、最初にスモークテストを実行して原因を特定することです。 問題を特定したら、記事のこの[リンク]の節にあるレコメンデーションを参照して、問題の修正方法を確認します。

/etc の下にカスタマイズが存在しない missing-customizations-under-etc

/apps と /libs はアップグレードで適切に処理されますが、/etc の下の変更はアップグレード後に /var/upgrade/PreUpgradeBackup から手動で復元する必要がある場合があります。手動で統合する必要があるコンテンツについては、この場所を確認してください。

error.log と upgrade.log の分析 analyzing-the-error.log-and-upgrade.log

ほとんどの状況では、問題の原因を見つけるために、エラーを調べる必要があります。 ただし、アップグレードの場合、古いバンドルが適切にアップグレードされない可能性があるので、依存関係の問題も監視する必要があります。

これを行う最善の方法は、発生している問題に関係ないと予想されるすべてのメッセージを削除して error.log を削除することです。 これは、grep のようなツールを使用して、次のコマンドを使用して実行できます。

grep -v UnrelatedErrorString

一部のエラーメッセージは、すぐに説明にならない場合があります。 その場合、エラーが発生するコンテキストを調べることで、エラーが発生した場所を把握することもできます。 次を使用してエラーを区切ることができます。

または

場合によっては、この状態になる有効なケースがあり、アプリケーションが実際のエラーかどうかを常に判断できるとは限らないので、エラーが WARN メッセージに表示される場合もあります。 これらのメッセージも参照してください。

アドビサポートのご案内 contacting-adobe-support

このページのアドバイスを確認しても問題が発生する場合は、Adobeサポートにお問い合わせください。 担当ケースを担当するサポートエンジニアに可能な限り多くの情報を提供するには、アップグレードから upgrade.log ファイルを必ず含めてください。