Sonar scanner version:3.0.1.733
Sonarqube version: 5.6.5
We have a sonar scanner on a Windows box which scans our project and submit a result to our Sonar server which is now on a Linux box. Prior to this, both the scanner and the sonar server and sonar db were on the same Windows box and we did not have any issues. We took a sonar db backup and restored it on another database on our new Linux box (now Sonar DB and Sonarqube server are on our Linux box). The server was installed from the native packages
My Issue now is when our scanner submits to the server no issue get reported. We used to have some issues before and now everything is reset back to zero.
I investigated a little bit, I can see the background tasks were received and processed successfully. Even the server UI shows the date of the latest scan.
The scanner reports success as well. I ran the scanner in the debug mode and I can see connections to the server with 200 status responses.
I cannot see anything out of ordinary in the logs.
If I re-point the scanner back to my old Windows sonar box it still shows correct number of issues.
Could anyone help me on this?
Usual suspect
Inconsistent measures and/or issue counts just after a SonarQube migration/upgrade can indicate that the local ElasticSearch index has been corrupted.
(reminder: ElasticSearch is a search engine used by SonarQube to index issues, rules etc. so that it can access this data rapidly without having to query the database all the time, see SonarQube Architecture).
Solution
stop SonarQube
erase sonar_install_dir/data/es
start SonarQube (note: restart
might take longer due to reindexing)
Root-cause analysis
To the question of why did that happen in the first place: a common case is an ElasticSearch index not being properly rebuilt after upgrading and/or changing database. Here's a typical scenario: you first start SonarQube on embedded H2 database, experiment a bit with it, then plug it to a full-fledged database. If the ElasticSearch index does not get scratched/rebuilt in between, then the index gets corrupted as the database/dataset it used to be in synch with just changed all of the sudden.
Good news
An improvement is coming in SonarQube v6.6 to better detect/handle this scenario at the application level (i.e. detect that ElasticSearch index should be rebuilt because the DB changed). See SONAR-5681 - When a change occurs on the DB, the Elasticsearch index must be dropped .
Related
I have been experiencing one strange issue from past 2 days. I had to setup sonarqube for code analysis and so I did it firstly in my local and then after successfully configuring, I did the same on one remote server. We are using Gradle in between.
All the configuration of sonar on remote machine (where I finally have to setup sonar so everybody can see) are same as in my local sonar instance (Means MySQl DB, Java version, Sonar version ..everything). When I check any project in sonarqube, I can see a number of bugs for my localhost:9000 Sonar but 0 bugs for RemoteServerIP:9000 sonar.
One thing here is, % of Duplications are same on both the IPs, but the rest of the parameters are showing 0 on RemoteServerIP:9000 sonar.
Please check following images:
Sonar instance on my local system with same configuration:-
Sonar instance on my Remote system with same configuration:-
Please let me know what I can do here to resolve the issue.
Thanks in Advance :-)
I am in the process of setting up SQ for a large organization. I plan to have two separate systems one for update testing and rule development. The second would be the production system where real work occurs. I will be using SQL 2014 typically when I do that I use a SQL always On group to sync to a DR server in another datacenter. My question is with a SonarQube instance does it make sense to DR the application to that level. If my organization can wait for a period of time to stand up a new server in a DR event would that be possible with a proper backup of the DB? Further if there were no backups of the DB what would be lost with a fresh new SonarQube server besides setup/config time? Is there historical value of code scans that would be lost or would the next scan of the code base have us right back to where we were in terms of critical issues found etc.?
Thanks for your replies.
All the data is stored in the database so using DR on the database is a good idea. You should make backup of the database and restoring the database is also a good solution (note that you should do backup of installed plugins).
If you loose the database, you will also loose all the configuration (quality profiles, credentials, etc.) and the history of the analyzed projects.
So to restore a SonarQube instance, you have to :
Restore the database
Restore SonarQube or install the same version
Restore the plugins (${SONAR_HOME}/extensions/plugins)
During the first start, the ES files (${SONAR_HOME}/data/es) will be regenerated and you're instance will then be up and running.
If you have commercial plugins or if you are working with large SonarQube instance you may contact the sales team to have support on this setup.
Disclaimer : I'm working at SonarSource
It seems that over half of the time I try to execute analysis using Sonar Runner 2.4 on several different projects that the analysis completes successfully but the publish (via the background task) to SonarQube fails. There is no log that I can find with relevant information on the SonarQube server for the failed tasks - at least I can't find any. I am new to SonarQube. The SonarQube 5.2 server is on Windows Server 2012 R2 using SQL Server 2012(SP1) database.
The answer is the solution stated in the related SonarQube 5.3 Background Task Fails with No Log in Dashboard . There were several SonarQube servers, which I was unaware of when I originally posted, accessing the same database. When those other instances were shut down there were no more failures in the background tasks.
I am upgrading an install of SonarQube from 4.5.1 to 5.2. I wasn't part of the original install and when looking at the sonar.properties file to see what needs to be update in the new one, I see properties for "sonar.search".
What is Sonar Search? Why would I need to uncomment/update these properties?
I haven't been able to find any good documentation on the SonarQube website on what it is and "sonar" and "search" internet searches bring up way too many unrelated results to sift through.
It is an Elasticsearch instance used for indexing some database tables. It allows for example powerful search requests on issues. See the sidebar of page "Issues". It supports multi-criteria searches and displays valuable facets.
Default settings in sonar.properties are good enough for most of environments. JVM settings of this dedicated process could be overridden if dozens of millions of issues are stored in database.
I have setup SonarQube 4.5.1 on Windows, backed by a SQL server (2012). The analyzer is running on a Linux box. I have changed the sonar.properties on the Linux box to point to the SQL server and the data is getting uploaded correctly.
I also have the web server configured correctly to query the data from the SQL server.
However, if I change the rules (add new rules, change rule values, etc), the setting changes are not reflected in my analyzer box. Is there a configuration step that I am missing?
This turned out to be trivial.
In the sonar-runner.properties file under /etc/sonar-runner/conf folder, set the server.host.url correctly.
----- Default SonarQube server
sonar.host.url=http://sonar.webserver:80