Server logs

Accessing and using server logs for troubleshooting.

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 Server process (main process, compute engine, search engine, and web server).

• The access log.

• The Monitoring API deprecation 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 system properties. 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.

You can tune the log level via controls at the top of the page Administration > System. Changes made here are temporary, and last only until the next time the instance is restarted, at which point the level will be reset to the more permanent value set in sonar.properties. Regardless, if you change your log level from INFO, be sure to change it back as soon as is practical; log files can get very large very quickly at lower log levels.

Log level by process

The server-side log level can be adjusted more precisely for the four processes of SonarQube via the following system 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, set the sonar.log.rollingPolicy property to one of these values:

• 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.

Log output in JSON format

By default, SonarQube prints all logs in plain text. You can convert the standard output of SonarQube logs to JSON format by setting the system property sonar.log.jsonOutput to true. This will enable log collection tools like Loki to post-process the information provided by the application.

Related pages

• System info and server ID

• Performance issues

• Database-related issues

• Elasticsearch-related issues

• Other issues