Jira HTTP 要求ログ アナライザー

tools $ ls ~/jira/releases/atlassian-jira-5.0.3-standalone/logs/
access_log.2012-05-15  catalina.2012-05-15.log  catalina.out                 localhost.2012-05-15.log  manager.2012-05-15.log
access_log.2012-05-16  catalina.2012-05-16.log  host-manager.2012-05-15.log  localhost.2012-05-16.log 

インストール 

jar ファイルをサーバーにコピーしてそこでツールを実行することも、ログファイルをワークステーションにコピーしてローカルで実行することも可能です。

対話形式で実行する

次のコマンドを実行すると、アナライザーを "対話モード" で実行できます。

java -jar access-log-analyser-1.0.jar

アナライザーを実行すると、ディレクトリまたはファイル名の入力を求められます (相対パスと絶対パスのどちらでも可)。
アクセスログのみが格納されているディレクトリ (例："/var/jira/access-logs/" または "../logs") や個々のファイル名 (例："logs/access-log-2012-08-15.txt") を入力できるほか、ワイルドカードとして '*' を使用することもできます (例："C:\\jira\logs\access-log.*")。

パラメーターを指定して実行する

また、次のようにパスをコマンドに渡すこともできます。

java -jar access-log-analyser-1.0.jarfile=/var/jira/access-logs/

「=」の前後にスペースは入りません。

コンテキスト パスを手動で設定する

サブコンテキスト (例: "/jira/") の下で Jira を実行すると、リクエスト ログのすべての URL にその手前のコンテキスト パスが含まれます。例:

/jira/secure/Dashboard.jspa 

コンテキストはツールによって自動検出されるため、通常、これは問題にはなりません。これが問題となるのは、アクセス ログが複数のアプリケーションまたは Web サイトの手前に設置されたプロキシ サーバー (例: Apache サーバー フロントエンド) から送られる場合です。この場合、Jira が誤ったコンテキスト パスを検出した場合 (実行時に検出されたコンテキスト パスを出力します) に、追加パラメーター "-context-path=<path>" を加えてコンテキスト パスを手動で設定する必要があります。例:

java -jar access-log-analyser-1.0.jarfile=* context-path=/jira

出力

ツールによって 3 つのファイルが作成されます。

request-log-summary.wiki

受信リクエストを既知の複数のカテゴリーにまとめます。
Confluence または Jira への挿入に適した Wiki 形式で出力されます。

requests-over-time.html

分析時間全体でのリクエストをグラフで示した Web ページです。
Google Chart を使用しており、Google Chart javascript ライブラリをダウンロードするためにはインターネット アクセスが必要です。

unknown-requests.txt

このファイルは、response-time-summary.html に "Unknown (不明な)" リクエストが多数表示される場合にのみ役に立ちます。
このファイルは、数の多い未認識のリクエストのグループ化を試みます。

結果の確認

リクエストカテゴリー

アナライザーの主な役割は、Jira のリクエスト ログに含まれるすべてのリクエストを読み込み、各リクエストを既知の "リクエスト カテゴリー" に分類することです。以下に一般的なカテゴリーをいくつか示し、その内容を簡単に説明します。

• Dashboard
  これはダッシュボードページを表示するためのコールです。各ダッシュボードを表示する度に、1 回のコールが行われます。その後、ダッシュボード内の各 "ガジェット" が Jira にコールバックしてその構成を読み込みます。こちらは "GADGETS" カテゴリー内に表示されます。その後、ほとんどのガジェットは少なくとも 1 つの REST コールを実行し、関心のあるデータを読み込みます。ほとんどの場合、これらは "REST_API" カテゴリー内に表示されます。
• Login
  ログインリクエスト。
• IssueNavigator
  課題検索ページ (単純検索または詳細検索)。
• ViewIssue
  Jira の "課題の表示" ページを取得するためのリクエスト。これが高になっていても驚くべきことではありません。
• PLUGIN_RESOURCES
  プラグインから提供されているリソース (たいていは CSS、JavaScript、および画像)。
• REST_API
  REST API に対する汎用コール。特定の REST エンドポイントが分類されることに注意してください。これらは Jira ページの AJAX コール由来する場合があります。また、データ取得のために Jira に対してクエリを実行する外部ツール/プラグインである可能性もあります。情報取得のために 1 つのページから複数の REST コールを実行する場合もあります。REST のいくつかの一般的な領域は、独自のカテゴリーを使用します。例: GreenHopper REST エンドポイントは nbspREST_GREENHOPPER の下に表示されます。
• Unauthorized_401
  401 (不正) ステータス コードを返されたリクエスト。ユーザーはログイン ページにリダイレクトされます。
  (v1.1 以上) 
• Forbidden_403
  403 (禁止) ステータス コードを返されたリクエスト。ユーザーがログイン後、表示権限のない URL をリクエストしました。
  (v1.1 以上) 
• CLIENT_ERROR_4xx
  その他の 4xx HTTP レスポンスで終了したリクエスト。たとえば、無効な URL を指定すると、404 レスポンスが返されます。ツールの v1.0 では、401 および 403 レスポンスがここに含まれ、v1.1 には独自のカテゴリがあります (上記を参照)。
• RPC
  古いリモート API (XML/RPC および SOAP) に対するコール。
• STATIC_RESOURCE
  画像、CSS、JavaScript などをすべて含みます。これらのリソースはすべて、ブラウザーでキャッシュできる必要があります。動的なリソースでは相対数を取得しようとするため、これらは統計対象の "パーセンテージ" では無視されます。
• ProjectAvatar
  プロジェクトアバター画像。

これらのリクエストの中には、特定のページ読み込みにおいて 1 回しかコールされないものもあります (ViewIssue、IssueNavigator など) が、その他のリクエストは、1 回のページ読み込みで複数回コールされる可能性があります (REST、GADGETS など)。ツールによって、すべてのカテゴリーがリクエスト数順に表示されます (動的リソースのパーセンテージと累計パーセンテージも含む)。

jira.atlassian.com の例

これらのリクエストのうち、ページを読み込むためのプライマリ リクエストは少数のみで、それ以外は「バックグラウンド リクエスト」 (REST、RPC、ガジェットなど) と、無視して問題ない複数のエラー (4xx 応答) であることがわかります。STATIC_RESOURCE はパーセンテージからすでに除外されており、残りの「バックグラウンド リクエスト」は合計数のおよそ半分を占めています。つまり、ViewIssue ページはすべてのリクエストの 15.7% を占めますが、これはアクセスされたすべてのページのおよそ 30% になります。

ページ レベルでは、J.A.C で行われる最も一般的な操作を確認できます。

J.A.C の高度な評価

1. 課題の表示、課題ナビゲーターおよびダッシュボードの数は、このタイプのインスタンスの標準の範囲内にあると考えます。
2. ログインは非常に多いように見えますが、J.A.C は約 80.000 ユーザー アカウントを持つパブリック インスタンスであるため、システム上のカジュアル ユーザー数の多さで説明できます。
3. XML 形式で課題を返す検索リクエストは非常に多く、おそらくこのインスタンスに固有です。「通常使用」を広い視野から確認することに意味があるのは、このような発見にあります。

内部および外部での所見

アトラシアンではこのツールを独自の Jira Server で確認するだけでなく、多数のエンタープライズのお客様にサーバーでツールを実行していただき、匿名化された結果を送信していただいています。お客様が Jira をどのように使用しているかを把握することで、最大規模の環境での Jira の使用をより正確に反映できるよう、パフォーマンス テストを調整できます。

弊社と複数のお客様のケースを含めた、多数の Jira サーバーでの所見を組み合わせたものを以下に示します。上位 5 件のリクエスト カテゴリーとそのパーセンテージ (統計リソースは無視します)、Jira のバージョンとピーク時負荷も示します。「ピーク時負荷」は、ピーク時に見られる最大負荷です。括弧内の 2 番目の負荷は、前後に他のピークがない、一度限りの急増を示します。

パフォーマンス テストを確認する

現在のパフォーマンス テストは、課題の表示、課題ナビゲーション、およびダッシュボードの 3 つが最も使用されるプライマリ ページであり、受信リクエストの大部分を占めているという想定に基づいています (テストには、ログイン、課題の編集、プロジェクトの参照などの多数のセカンダリ ページも含まれていますが、それらがすべてのリクエストに占める割合はそれぞれ 2% 未満とわずかです)。お客様にとって非常に重要なページが他にあるかどうかを確認するとともに、弊社でのテスト結果の割合が現実的であるかどうかも確かめた結果、これらのページはお客様が使用するページの上位 3 でページであることもわかりました。最も一般的な割合は、検索あたりの課題の表示が 2 ～ 3 件、ダッシュボードあたりの検索が約 1.5 件でした。

テストで見られた興味深いパターンとして、Gadget リクエストの数が Dashboard リクエストよりもはるかに多い (10:1 ～ 40:1) サイトが多数ありました。これは、10 以上のガジェットを持つダッシュボードである可能性もありますが、「ウォールボード」(個別ガジェットが定期的に更新する無人ダッシュボード) が多用されている可能性が高いことが考えられます。