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

アップグレード後のチェック

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

• ログでアップグレードの成功を確認

• OSGi バンドルの確認

• Oak バージョンの確認

• PreUpgradeBackup フォルダーの検査

• ページの初期検証

• AEM サービスパックの適用

• AEM 機能の移行

• スケジュールされたメンテナンス設定の確認

• レプリケーションエージェントの有効化

• スケジュール済みカスタムジョブの有効化

• テスト計画の実行

ログのアップグレード成功の確認

upgrade.log

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

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

具体的には、次のことが確実におこなわれます。

• アップグレードフレームワークで検出されたアップグレードエラーは、単一のアップグレードレポートで一元管理されます。
• アップグレードレポートには、手動での必要な介入に関する指標が含まれています。

これに対応するため、 upgrade.log ファイル。

以下に、アップグレード中にエラーが発生しないレポート例を示します。

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

error.log

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

OSGi バンドルの確認

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

Oak バージョンの確認

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

PreUpgradeBackup フォルダーの検査

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

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

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

ページの初期検証

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

AEM サービスパックの適用

関連するAEM 6.5 Service Pack がリリースされている場合は、適用します。

AEM機能の移行

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

スケジュールされたメンテナンス設定の確認

データストアのガベージコレクションを有効にする

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

オンラインでのリビジョンクリーンアップの有効化

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

テスト計画の実行

定義済みのに対して詳細なテスト計画を実行します コードのアップグレードとカスタマイズ の下に テスト手順 」セクションに入力します。

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

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

スケジュール済みカスタムジョブの有効化

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

アップグレードの問題の分析

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

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

リポジトリの移行に失敗

CRX2 から Oak へのデータ移行は、CQ 5.4 に基づくソースインスタンスで始まるあらゆるシナリオで実行可能である必要があります。このドキュメントのアップグレード手順に従って、 repository.xmlを使用する場合は、カスタム認証子が JAAS 経由で開始されていないことと、移行を開始する前にインスタンスに不整合がないかどうかが確認されていることを確認します。

移行が失敗した場合は、 upgrade.log. 問題がまだわかっていない場合は、カスタマーサポートに報告します。

アップグレードが実行されませんでした

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

パッケージとバンドルの更新に失敗

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

一部のAEMバンドルがアクティブ状態に切り替わらない

起動していないバンドルがある場合は、未満の依存関係を確認します。

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

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

カスタムバンドルがアクティブ状態に切り替わらない

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

削除された API は、以前のリリースの 1 つで廃止済みとマークする必要があります。 コードの直接移行に関する手順については、この廃止のお知らせを参照してください。 Adobeは、可能な限りセマンティックバージョン管理を目的としており、バージョンで重大な変更を示すことができます。

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

Platform UI の不具合

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

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

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

カスタムコンポーネント、テンプレートまたは UI 拡張の誤動作

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

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

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

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

error.log と upgrade.log の分析

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

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

grep -v UnrelatedErrorString

一部のエラーメッセージは、すぐには説明できない場合があります。 この場合、発生したコンテキストを調べると、エラーが作成された場所を把握するのに役立ちます。 次の方法でエラーを区切ることができます。

• grep -B（エラーの前の行を追加）

または

• grep -A（エラーの後の行を追加）

一部のケースでは、この状態につながる有効なケースが存在し、アプリケーションがこれが実際のエラーであるかどうかを常に判断できないので、エラーが WARN メッセージに出ることがあります。 これらのメッセージも必ずご覧ください。

アドビサポートのご案内

このページのアドバイスを受けても問題が解決しない場合は、Adobeサポートにお問い合わせください。 お使いの事例に関するサポートエンジニアにできる限り多くの情報を提供するには、アップグレード時の upgrade.log ファイルを必ず含めてください。