Jira Access Log Analyzer

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 

Installation 

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.

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.

-h

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

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

--file

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/'

--context-path

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.

--num-categories

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

--include-total

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'

--response-time

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.

Output

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:

response-time-summary.html

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.

response-time.html

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.

unknown-requests.txt

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.
• PLUGIN_RESOURCES
  Resources (presumably CSS, javascript and images) that are being served from a plugin.
• REST_API
  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. 
• REST_API_SEARCH
  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.
• CLIENT_ERROR_4xx
  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.
• STATIC_RESOURCE
  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).