request.log 分析の例 | AEM

Adobe Experience Manager（AEM）の request.log は、応答時間を含む豊富な情報のソースであり、パフォーマンスの問題を分析するために重要です。 この記事では、この点を説明するためのいくつかの例を示します。

説明 description

環境

Experience Manager 6.5

問題／症状

Adobe Experience Manager（AEM）の request.log には、パフォーマンスの問題を分析する際に役立つ様々な情報（応答時間など）が含まれています。 以下は、Linux コマンドを使用した分析例のリストです（ruby [ 1] や datamash [ 2] などの外部コマンドを含む）。

インストールガイド

[ 1] https://www.ruby-lang.org/en/documentation/installation/

[ 2] https://www.gnu.org/software/datamash/download/

解決策 resolution

目次

A.はじめに

B.準備手順

C.分析の例

日まとめ

A.はじめに

request.log の形式 :

AEM 6.5 では、デフォルトで次の形式で request.log が生成されます。 システムの制限により、この記事のコマンドラインはプレーンテキストではなく画像として表示されます。

request.log の例：

この記事では、「– >」を含む行は、「リクエストレコード」と呼ばれます。 「< –」を含む行は「応答レコード」です。

レコードの要求 :

AEMがリクエストを受信すると、リクエストレコードがログに記録されます。 受信日時、リクエスト ID、リクエスト方法および URL が含まれます。

応答記録 :

AEMがリクエストに応答すると、応答レコードがログに記録されます。 これには、応答の日時、要求 ID、ステータスコード、Content-Type および応答時間（ミリ秒単位）が含まれます。

対応するマニュアルを request.log の解釈で見つけます。

B.準備手順

手順 1. データクレンジング

request.log の分析に立ち入る前に、ログレコードを標準化することが重要です。

最初の sed コマンドは、応答レコードの Content-Type の余分なスペースを削除して、空白による誤ったフィールド分離を防ぎます。 Ruby コマンド （Ruby をインストールするには、上記 [1] を参照）は、日付形式を ISO 8601 に変換します。 また、ruby コマンドは、日付と時刻をコロンの代わりに空白で区切ります。

手順 2. 再開時間

AEMとサービスパックのインストールを再起動すると、request.log のリクエスト ID がリセットされます。 request ID = 0 を含むリクエストレコードは、次のような操作が存在する可能性を示しています。

上記の例では、リクエスト ID は 13:08:49 と 13:26:13 の 0 にリセットされました。

手順 3. 1 時間あたりのアクセス数

1 時間あたりのアクセス数と、request.log の時間範囲をカウントします。

手順 4. 最大同時処理

同時処理数は、AEMのサーバー負荷を推測するのに役立ちます。

デフォルトでは、AEMでの Jetty の最大同時接続数は 200 に設定されています。 応答が完了した後、ソケットを解放する際に遅延が生じる。 同時処理の数が約 170 を超えると、新しいリクエストを受け入れることができなくなります。

手順 5. ログファイルの分割

request.log のリクエスト ID は、AEMの再起動時またはサービスパックのインストール時にリセットされます。 この動作により、request.log ージにこのような操作が含まれている場合、分析が正しくないことがあります。 正確な分析を行い、同時に処理するファイルサイズを小さくするには、リクエストレコードをリクエストレ request.log ドで使用するリク ID = 0 ストを分割します。

手順 6. 要求レコードと応答レコードを結合する

リクエスト ID によってリクエストレコードと応答レコードを結合すると、パフォーマンスの問題が発生したタイミングを簡単に特定できます。 この結合ログファイルは、後の例で使用します。

最後の sed コマンドでは、対応する応答レコードがないリクエストレコードにダミーの応答を追加します。 リクエストレコードのない応答レコードも存在する場合があります。 しかし、これらは通常、調査の対象とはならないので、無知です。

結合されたログファイルは次のようになります。

C.分析の例

例 1. 最も重いアクセス

レスポンスなしのアクセスを含め、レスポンス時間の降順でマージ・ログ・ファイルをソートします。

例 2. 見つからない応答にアクセス

ダミーの応答時間を使用して、対応する応答レコードがないアクセスを抽出します。

応答のないアクセスを受け取るタイミングがサーバー負荷の増加と相関している場合、これらのアクセスはパフォーマンスの問題をトリガーする可能性があります。

例 3。 低速アクセス

10 秒以上かかった抽出アクセス。

ヒット数が多すぎる場合は、grep コマンドで [ 0-9] {5} を [ 0-9] {6} に置き換えて、100 秒以上かかったアクセスに絞り込みます。

例 4. 応答時間の時系列データ

データからタイムスタンプと応答時間のみを抽出すると、グラフを作成するのに役立ちます。

即座に応答したアクセスを省略すると、データの効率が向上します。 次の例では、2 秒を超えたアクセスを抽出しています。

例 5. 最小、平均（平均）、中央値、最大応答時間

上記の例では、統計処理に datamash コマンド （https://www.gnu.org/software/datamash/）を使用しています。 応答のないアクセスがログに含まれている場合、ダミーの値は結果に影響を与えます。

例 6。 1 期間あたりのアクセス数

10 分あたりのアクセス数をカウントします。 結果は、大きなトラフィックがパフォーマンスの問題の原因であるかどうかを判断するのに役立ちます。

次の例では、データをPOSTリクエストのみに絞り込みます。 典型的なユースケースは、Publish層へのコンテンツのオーサリングやレプリケーションが集中しているかどうかを判断することです。

例 7. 1 期間あたりの応答ステータスの数

datamash コマンドを使用して、10 分あたりの各応答ステータスの数のテーブルを作成します。

例 8。 頻度の高い URL

10 分ごとに最も頻繁にアクセスされた上位 3 つの URL を印刷します。

例 9. request.log レコードの access.log レコード

特定のリク access.log スト ID に対応するレコードを検索します。

同時に同じ URL への複数のアクセスが発生した場合、結果には、1 つのリクエスト ID に対して複数の access.log レコードが表示されます。

日まとめ

この記事の例は、パフォーマンスの問題を分析する際に役立ちます。

上記の例は CentOS 7.5 および Ubuntu 22.04LTS でテスト済みですが、バージョンの違いやコマンドのバリエーションなど、環境によっては期待どおりに動作しない場合があります。 環境にインストールされているコマンドに応じて調整してください。