Checking and configuring the server logs

If you're having trouble starting your server for the first time (or any subsequent time!) the first thing to do is check your server logs. 

The following log files are created (log files rotate on a regular basis): 

• One per SonarQube Community Build process (main process, compute engine, search engine, and web server).
• The access log.
• The deprecation log which stores the Web API requests that use deprecated Web API endpoints or parameters.

If you have a support contract, you can download your instance's current log files from the UI. To do so:

• Go to Administration > System and click Download logs in the top right corner.

Otherwise, you'll find them in <sonarqubeHome>/logs:

• sonar.log: Log for the main process. Holds general information about startup and shutdown. You'll get overall status here but not details. Look to the other logs for that.
• web.log: Information about initial connection to the database, database migration and reindexing, and the processing of HTTP requests. This includes database and search engine logs related to those requests.
• ce.log: Information about background task processing and the database and search engine logs related to those tasks.
• es.log: Ops information from the search engine, such as Elasticsearch startup, health status changes, cluster-, node- and index-level operations, etc.
• access.log: access log.

Understanding the logs

When there's an error, you'll very often find a stacktrace in the logs. If you're not familiar stacktraces, they can be intimidatingly tall walls of incomprehensible text. As a sample, here's a fairly short one:

java.lang.IllegalStateException: Unable to blame file **/**/foo.java
    at org.sonarsource.scm.git.JGitBlameCommand.blame(JGitBlameCommand.java:128)
    at org.sonarsource.scm.git.JGitBlameCommand.access$000(JGitBlameCommand.java:44)
    at org.sonarsource.scm.git.JGitBlameCommand$1.call(JGitBlameCommand.java:112)
    at org.sonarsource.scm.git.JGitBlameCommand$1.call(JGitBlameCommand.java:109)
    at java.util.concurrent.FutureTask.run(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.NullPointerException
    at org.eclipse.jgit.treewalk.filter.PathFilter.create(PathFilter.java:77)
    at org.eclipse.jgit.blame.BlameGenerator.<init>(BlameGenerator.java:161)
    at org.eclipse.jgit.api.BlameCommand.call(BlameCommand.java:203)
    at org.sonarsource.scm.git.JGitBlameCommand.blame(JGitBlameCommand.java:126)
    ... 7 more

Unless you wrote the code that produced this error, you really only care about:

• the first line, which ought to have a human-readable message after the colon. In this case, it's Unable to blame file **/**/foo.java
• and any line that starts with Caused by. There are often several Caused by lines, and indentation makes them easy to find as you scroll through the error. Be sure to read each of these lines. Very often one of them - the last one or next-to-last one - contains the real problem.

Setting up the server-side logging

Server-side logging is controlled by properties set in <sonarqubeHome>/conf/sonar.properties. The standard output of SonarQube logs can be converted to JSON with the environment variable SONAR_LOG_JSONOUTPUT=true. A configuration of the log format is currently not possible.

Log level

The server-side log level can be customized via the sonar.log.level property  in <sonarqubeHome>/conf/sonar.properties. Supported values are:

• INFO: The default.
• DEBUG: For advanced logs. Starting from this log level, some personal user information can be logged.
• TRACE: Show advanced logs and all SQL and ElasticSearch requests. TRACE level logging slows down the server environment, and should be used only for tracking web request performance problems.

Log level by process

The server-side log level can be adjusted more precisely for the four processes of SonarQube via the following properties:

• sonar.log.level.app: for the Main process of SonarQube (aka WrapperSimpleApp, the bootstrapper process starting the 3 others)
• sonar.log.level.web: for the WebServer
• sonar.log.level.ce: for the ComputeEngineServer
• sonar.log.level.es: for the SearchServer

Log rotation

To control log rolling, use the sonar.log.rollingPolicy.

• time:[value]: for time-based rotation. For example, use time:yyyy-MM-dd for daily rotation, and time:yyyy-MM for monthly rotation.
• size:[value]: for size-based rotation. For example, size:10MB.
• none: for no rotation. Typically this would be used when logs are handled by an external system like logrotate.

sonar.log.maxFiles is the maximum number of files to keep. This property is ignored if sonar.log.rollingPolicy=none.

Related pages

• Setting up the server-side logging
• Performance issues
• Database-related issues
• Elasticsearch-related issues