SonarQube Logs and Monitoring
A server that runs quietly still needs attention. Logs record what happened, and monitoring warns you before users notice a problem. Both skills shorten troubleshooting from hours to minutes.
The Car Dashboard Picture
A car shows a speedometer and warning lights so the driver reacts early. The logbook in the glove box records past trips and repairs. SonarQube offers the same two tools: health checks act as warning lights, and log files act as the logbook.
Warning lights (live) Logbook (history)
┌───────────────────────┐ ┌───────────────────────┐
│ /api/system/status │ │ logs/sonar.log │
│ /api/system/health │ │ logs/web.log │
│ Background Tasks page │ │ logs/ce.log │
└───────────────────────┘ │ logs/es.log │
│ logs/access.log │
└───────────────────────┘
The Log Files
SonarQube writes several files in the logs folder.
| File | Content |
|---|---|
| sonar.log | Startup, shutdown, and process supervision |
| web.log | Web server activity and errors |
| ce.log | Analysis processing and task results |
| es.log | Search server messages |
| access.log | Each web request with time and status |
Docker users read the same information through docker logs or the mounted logs volume.
Read a Log Effectively
- Start with the file that matches the symptom. Slow analysis points to ce.log.
- Search for the words ERROR and WARN.
- Note the time of the first error, because later messages often follow from it.
- Copy the exact message into your search or the Sonar community forum.
Log Levels
Three levels cover most needs.
- INFO is the default and records normal events.
- DEBUG adds detail for troubleshooting.
- TRACE records everything and grows files very fast.
sonar.log.level=DEBUG
Return to INFO after the investigation, since detailed logs consume disk space.
View Logs in the Interface
Administrators can open Administration, then System. The page shows server information, memory use, and downloadable log files. The same area lets you change the log level temporarily without a restart.
Health Checks
Status Endpoint
The status endpoint answers without a login and reports the server state, such as STARTING, UP, DOWN, or DB_MIGRATION_NEEDED.
curl http://your-server:9000/api/system/status
Health Endpoint
The health endpoint reports GREEN, YELLOW, or RED and lists causes. It requires administrator rights or a system passcode set in the configuration file.
curl -u admin_token: http://your-server:9000/api/system/health
Watch the Background Tasks Page
This page lists every analysis task with its status and duration. Failed tasks show an error message and a link to the log. A growing pending count signals a Compute Engine bottleneck. Teams check this page every morning as a quick routine.
Connect External Monitoring
- Point an uptime tool at the status endpoint and alert on any answer other than UP.
- Collect logs with a central log service so searches cover every server.
- Track disk space on the log folder and the database server.
- Watch memory use of the three Java processes.
Log Rotation
SonarQube rotates its log files daily and keeps a limited number of old files. Adjust the retention with the sonar.log.maxFiles property when disk space is tight or audit rules demand a longer history.
Alerting Plan
| Signal | Action |
|---|---|
| Status not UP | Page the on-call engineer |
| Health YELLOW or RED | Open a ticket and inspect the cause |
| Failed tasks rising | Check ce.log for repeated errors |
| Disk above 80% | Clean old data or add space |
A Troubleshooting Example
Developers report that scans fail at random. The administrator opens the Background Tasks page and sees several failed tasks with the same message. The ce.log file reveals an out-of-memory error at each failure time. Raising the Compute Engine memory and restarting solves the problem. Logs supplied the cause, and monitoring supplied the first clue.
Quick Recap
Use the status and health endpoints as warning lights, read the matching log file for the story, and keep an eye on background tasks. Early signals keep the server dependable.