Jira Access Log Analyzer

What this tool is used for

The analyzer tool is used to read all the requests in the Jira request logs, put each one into a known "request category" and then analyze response times for each category. Running this tool will create the following three files:

  1. A summary of the incoming requests organized into a number of known categories.
  2. A web page which charts the response times of the most used categeries over the time analyzed.
  3. A summary of the unrecognized requests.


You must have a Java Runtime Environment installed to run the analyzer.

Note that Jira and web servers produce a few different types of logs. The tool is only made to analyze the "request logs" (also known as "access logs").
For example, standalone Jira produces the log files that look like:

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 

In this case we would only want to analyze the two files starting with "access_log".

You can filter out the other files using a wildcard in the file name as explained below, or you can copy the access logs to a temporary folder and analyze that whole folder.

In order to analyze the response times, the access logs must be in a suitable format. It is highly recommended to use Jira standalone and analyze the logs from the Jira Standalone 'logs' directory. See also "legacy mode" below.

On this page:


You can either copy the jar file to your server and run the tool there, or copy the log files to a workstation and run it locally.

Version File Notes
v2.0.1 access-log-analyser-2.0.1.jar Added categories for Tempo plugin
v2.0 access-log-analyser-2.0.jar Analyze Jira standalone logs for most detailed results


Running interactively

The analyser can be run in "interactive mode" by running this command:

java -jar access-log-analyser-2.0.jar

The tool will prompt you to enter a directory or filename - this can be a relative or absolute path.
You can enter a directory containing access logs only (eg "/var/jira/access-logs/" or "../logs"), an individual file name (eg "logs/access-log-2012-08-15.txt"), or use '*' as a wildcard (eg "C:\\jira\logs\access-log.*").

Running with parameters

Alternatively you can pass the path into the command, eg:

java -jar access-log-analyser-2.0.jar --file=/var/jira/access-logs/

The "file" parameter is mandatory, for all others the analyser tool will either use a sensible default or try to detect the correct behaviour.


Use the '-h' parameter to print help from the tool:

java -jar access-log-analyser-2.0.jar -h


Use this to set the access log file name, filename pattern, or directory.
eg: '--file=access_log.2014-09-18', '--file=access_log.*', '--file=/var/logs/jira/'


Sets the 'context path' (root directory) that the Jira URLs use.
eg if your URLs look like http://issues.example.com/jira/browse/ABC-123 then you could set '--context-path=jira'
This setting is optional, and can normally be omitted: the analyzer will just figure it out if it is not set.


Sets the number of request category graph lines to produce in the response-times graph.
Defaults to 5.
eg: '--num-categories=8'


Whether or not to include the 'ALL' graph line in the Total Server Time graph.
Valid values are 'true' or 'false'. Defaults to 'true'.
eg: '--include-total=false'


Use this param to force the 'response-time' behavior to on or off.
Set this to 'true' to force the analyzer to attempt to analyze response times.
In this mode, the analyzer expects the HTTP Status code to be the first field after the URL
and the response time (in milliseconds) to be the third.
Setting 'false' forces the analyzer to NOT attempt to analyze response times.


The tool will create 3 files, but what these are depends on whether it has analysed response times or not.
If response times have been analysed it will produce the following files:


This summarises the incoming requests into a number of known categories, and shows some statistics for each.
It then lists those in three separate tables where each lists the categories in a different order - ordered by Total Server Time, by Average Response Time and by raw Request Count.


Takes the most important request categories and graphs them over time.
The number of lines to show on the graphs can be controlled by the "num-categories" parameter.


This is only useful if the response-time-summary.html shows a high number of "Unknown" requests.
It attempts to group the most popular unrecognised requests.


If response times have not been analysed then it is considered to be working in legacy mode.
See Jira HTTP Requests Log Analyzer for documentation of the files created. 

Understanding the results

Request Categories

The main job of the analyser tool is to read all the requests in the request logs and put each one into a known "request category". Here is a quick breakdown on some common categories and what they mean:

  • Dashboard
    This is a call to show the Dashboard page. There is a single one of these per Dashboard, and then each "Gadget" in the dashboard will call back to Jira to load its configuration - these are shown in the "GADGETS" category. Then, most gadgets will make at least one additional REST call to load the data that it is interested in. These will most often show up in the "REST_API" category.
  • Login
    A Login request.
  • IssueNavigator
    The issue search page (simple or advanced).
  • ViewIssue
    A request to get the "View Issue" page in Jira - no surprises when this is high.
    Resources (presumably CSS, javascript and images) that are being served from a plugin.
    Generic calls to the REST API - note that there are specific REST endpoints that are categorised. These may be coming from AJAX calls in Jira pages, or could be external tools/plugins querying Jira for data. A single page can make multiple calls to REST to get information. Note that a few areas of REST are common enough to warrant their own specific category.
    See also Jira REST Documentation
    Calls to /rest/api/2/search.
    That is, doing a JQL query via REST.
  • REST_greenhopper_xboard
    Calls to /rest/greenhopper/1.0/xboard.
  • REST_greenhopper_rapidview
    Calls to /rest/greenhopper/1.0/rapidview.
  • REST_greenhopper
    Other calls to /rest/greenhopper/.
  • Unauthorized_401
    The request returned a 401 (Unauthorized) status code. The user will have been redirected to the Login page.
  • Forbidden_403
    The request returned a 403 (Forbidden) status code. The user was logged in and requested a URL that they are not permitted to see.
    Any request that ended in other 4xx HTTP response, e.g. invalid URLs will get a 404 response.
  • RPC
    Any call to the older remote APIs - XML/RPC and SOAP.
    Includes all images, CSS, javascript, etc. These resources should all be cache-able in the browser. These are ignored in our "percentages" because we are trying to get relative numbers on the dynamic resources.
  • ProjectAvatar
    The project avatar image.


Note that some of these requests will get called exactly once for a given page load (eg ViewIssue, IssueNavigator), but others can be called multiple times in a single page load (eg REST, GADGETS).

Last modified on Jan 12, 2018

Was this helpful?

Provide feedback about this article
Powered by Confluence and Scroll Viewport.