JIRA Access Log Analyzer
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.
||Added categories for Tempo plugin|
||Analyze JIRA standalone logs for most detailed results|
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.*").
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.
Whether or not to include the 'ALL' graph line in the Total Server Time graph.
Valid values are 'true' or 'false'. Defaults to 'true'.
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
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:
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.
A Login request.
The issue search page (simple or advanced).
A request to get the "View Issue" page in JIRA - no surprises when this is high.
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.
That is, doing a JQL query via REST.
Other calls to
The request returned a 401 (Unauthorized) status code. The user will have been redirected to the Login page.
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.
Any call to the older remote APIs - XML/RPC and SOAP.
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).