Depending on the situation you’re analyzing, you may enable different loggers. Here are some recommendations we have found valuable over the past years doing support for OSLC Connect for Jira.
Prepare your logs with some specific notes
Jira lets you insert a marker in the logs, as well as force a rollover of the log files.
The former helps you find when exactly you started a session. You can also mark an optional comment anytime you start a specific test, so that there is no ambiguity in your log as to what you have achieved in the debug session. With those additional markers, the log will tell you all you need to know. Also note that those markers may very well provide context regarding what will happen, as well as what just happened. You should use that (great) feature extensively in debug sessions.
The latter helps with getting small files that are easier to share at the end of the debug session.
In order to do this, you should go to the Mark Logs container, and mark them as suggested below, then click Mark.
Decide on what to review
Review incoming requests to Jira
You should do that if a remote application is experiencing problems interacting with Jira.
Incoming requests are visible in the HTTP access log.
SodiusWillert Support may ask you to activate these Jira logging:
HTTP Access Log: this contains requests coming from external tools, along with the time of the request and status of the response
HTTP Dump Log: this contains very detailed requests received by Jira, along with the very detailed responses that were prepared and sent by Jira
Review outgoing requests sent by Jira and OSLC Connect for Jira
The Jira application log will contain everything that is logged by Jira itself, based on what is configured in the Default loggers section:
This allows us to configure additional logging. The additional logging is based on a source code package that you want to enable logging for. For example, if you want to see the details of the requests sent by Jira, and the responses Jira gets from external OSLC tools, you will want to configure the following packages with a
DEBUG log level:
org.apache.http, to review the details of every request initiated by Jira
com.sodius.oslc.server.services, to review the details of the OAuth 1.0a dance provided by
Finishing the debug session
Restore your system’s previous logging features
Upon wrapping up your debug session, you want to make sure all the additional logs you have enabled have been disabled:
If you were reviewing incoming requests, you will want to disable the HTTP Access and HTTP Dump logs
If you were reviewing outgoing requests, you will also want to deactivate the additional default loggers by either restoring the original logging level to an already logged package, or disabling the logging of an added by package by turning it
Retrieving Jira logs
You should create a support .zip file from your Administration page as shown below.
You can then click the
Create zip button to generate the zip file which, once ready, you will be able to download and unzip on your computer.
Below are the log files that you need to search for (and into):
atlassian-jira.log, for Jira application logs and Jira outgoing requests, including the logs from the additional packages enabled above, such as
atlassian-jira-http-access.log, for simple Jira incoming requests
atlassian-jira-http-dump.log, for detailed Jira incoming requests
There may be a number of similar log files e.g. atlassian-jira.log, atlassian-jira.log2, etc. because when we mark the logs at the beginning with the log rollover, as well as when a log file becomes full, a new one is created. If you have only asked for a log rollover once at the beginning of your debug session, then your whole session will be in the non-numbered files.
Within these log files, all events are time stamped. So either you have noted roughly when the error occurred or else recreated the error just before looking at the log files.
We suggest attaching the log file(s) to a Jira ticket on our customer support portal.