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

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

レガシー

このページでは、アナライザー ツールの v1.x について説明します。Jira Access Log Analyzer に記載された最新バージョンを使用することをお勧めします。

このツールの用途

アナライザーの主な役割は、Jira のリクエスト ログに含まれるすべてのリクエストを読み込み、各リクエストを既知の "リクエスト カテゴリー" に分類することです。このツールを実行すると、次の 3 つのファイルが作成されます。

  1. 既知の各種カテゴリーにまとめられた受信リクエストの概要
  2. 分析時間全体でのリクエストをグラフで示した Web ページ
  3. 数の多い未認識のリクエストをグループ別に分けた受信リクエストの概要

要件

このアナライザーを実行するには、Java Runtime 環境をインストールする必要があります。

Jira サーバーと Web サーバーが生成するログにはいくつかの種類があることにご注意ください。これは "リクエストログ" ("アクセスログ" とも呼ばれる) を分析する目的でのみ作成されたツールです。
たとえば、スタンドアロンの Jira では次のようなログファイルが生成されます。

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 

このケースでは、"access_log" で始まる 2 つのファイルのみを分析する必要があります。

その他のファイルは、以下で説明するように、ファイル名にワイルドカードを使用して除外することができます。あるいは、アクセスログを一時フォルダーにコピーして、そのフォルダー全体を分析することも可能です。

このページの内容:

インストール 

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

VERSION (バージョン) ファイル 注意
v1.1 access-log-analyser-1.1.jar Jira 6.0 用の新しいパスを含むカテゴリーを追加しました
v1.0 access-log-analyser-1.0.jar Jira v5.x 以前向けに設計されています

 

対話形式で実行する

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

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 の例

カテゴリー別 J.A.C リクエスト

リクエスト カテゴリー

count

パーセンテージ

累計

STATIC_RESOURCE

7675051

-

-

REST_API

1560461

20.9%

20.9%

課題の表示

1168760

15.7%

36.6%

SearchRequest_XML

1047243

14.0%

50.6%

課題ナビゲーター

447391

6.0%

56.6%

ガジェット

313464

4.2%

60.8%

REST_ACTIVITY_STREAM

260381

3.5%

64.3%

ProjectAvatar

214543

2.9%

67.2%

ログイン

209259

2.8%

70.0%

RPC

187814

2.5%

72.5%

CLIENT_ERROR_4xx

177301

2.4%

74.9%

ダッシュボード

162825

2.2%

77.1%

ACTIVITY_STREAMS

138830

1.9%

79.0%

REST_GREENHOPPER

137477

1.8%

80.8%

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

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

ページ
利用状況
課題の表示 30 %
XML 検索リクエスト 26 %
課題ナビゲーター (検索) 12 %
ログイン 5 %
ダッシュボード 4 %

J.A.C の高度な評価

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

内部および外部での所見

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

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

VERSION (バージョン)

ピーク時負荷

リクエスト 1

リクエスト 2

リクエスト 3

リクエスト 4

リクエスト 5

v5.0.7

21.6 リクエスト/秒

ガジェット

31.1%

REST_GADGET

14.5%

ProjectAvatar

11.9%

REST_OTHER

9.7%

RPC

4.7%

v4.4.4

20 (45.5)リクエスト/秒

ガジェット

17.5%

REST_GADGET

10.8%

課題の表示

8.5%

REST_API

8.3%

ProjectAvatar

6.8%

v4.4

19.8 (39.5)リクエスト/秒

REST_whoslooking

51.3%

ガジェット

11.9%

REST_GADGET

8.3%

PLUGIN_RESOURCES

4.7%

REST_API

4.0%

?

15.8 リクエスト/秒

ProjectAvatar

24.8%

REST_API

18.9%

ガジェット

11.6%

REST_GADGET

6.9%

RPC

6.7%

?

12.9 リクエスト/秒

ProjectAvatar

36.2%

REST_API

17.0%

ガジェット

10.6%

REST_GADGET

7.2%

課題の表示

4.3%

v4.4.3

12.4 リクエスト/秒

ProjectAvatar

18.5%

ガジェット

13.8%

RPC

11.4%

USER_AVATAR

9.2%

REST_GADGET

7.9%

v5.1

12.1 リクエスト/秒

REST_API

20.9% 

課題の表示

15.7%

SearchRequest_XML

14.0%

課題ナビゲーター

6.0%

ガジェット

4.2%

v4.3.4

12.1 (31.6)リクエスト/秒

ガジェット

23.4%

REST_API

13.0%

REST_GADGET

8.9%

Tempo

8.6%

課題の表示

7.7%

v5.0

10.3 リクエスト/秒

ガジェット

31.3%

REST_GADGET

21.6%

USER_AVATAR

8.9%

課題の表示

6.3%

REST_API

4.0%

v5.1

9.5 リクエスト/秒

課題ナビゲーター

28.7%

ガジェット

17.0%

REST_GADGET

10.3%

REST_OTHER

9.6%

RPC

4.0%

v5.1

8.2 リクエスト/秒

CLIENT_ERROR_4xx

27.5%

SearchRequest_XML

11.1%

REST_API

9.0%

ガジェット

7.5%

REST_GADGET

6.3%

v3.13

4.9 リクエスト/秒

LazyPortletLoader

26.6%

課題の表示

15.7%

チャート

13.9%

ダッシュボード

6.5%

ワークフロー トランジション

4.8%

v4.2.2

4.6 リクエスト/秒

ガジェット

21.2%

REST_GADGET

20.1%

REST_API

11.4%

OpenSearch

9.7%

課題の表示

7.0%

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

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

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

最終更新日 2018 年 1 月 12 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.