which versions are you using: Enterprise Edition v2025.1.2 (108896)
how is SonarQube deployed: Docker
what are you trying to achieve: Get used LoC for monitoring and alarming
what have you tried so far to achieve this: used api endpoint api/monitoring/metrics
We are using prometheus for metrics and have used the api/monitoring/metrics specifically the sonarqube_license_number_of_lines_analyzed_total this shows a current use of 9.4 million LoC but when I look under Administration > License Manager the LoC is 9.8 million. This caused some problems for us while we used the api point for alarming and wanted to take action at 9.5 million LoC.
I know that the biggest branch is used for counting lines but I do not know why between the api call for these metrics and looking at it in the License Manager there would be a 400k difference.
I would like to know why these are so different, which one would be considered the truth, and what would be a good solution to ensure we don’t reach our limit while the api that we relied on for alarming is counting a lower number than the License Manager. We have set a notification threshold at 8 million but we want to have several levels which is why we use the api point to keep up to date with the current use.
The source of the LoC value in both the License Manager in the UI and the response from the endpoint is the same, however, the endpoint returns the last sampled value, with sampling interval of 30s. That makes the License Manager the source of truth in this case.
Regarding the difference in the numbers, this is something that we should further investigate if it does not come from the possible delay due to the sampling interval.
To help me do that, can you please share if you were comparing response from the endpoint that was returned around the same time that you looked up the value in the License Manager? It would be great if you could please repeat the comparison once more by querying both sources at the same time.
I now called the two apis api/monitoring/metrics and api/editions/show_license?internal=true right after each other. The monitoring/metrics value for key sonarqube_license_number_of_lines_analyzed_total is still on 9.4 million while the editions/show_licenseloc shows 9.9 million.
We are suspecting a potential issue with the scheduled tasks updating the metric values, but to confirm this I would like to ask you if you could do another test by running the following SQL query: select sum(ncloc) from projects where qualifier = ‘TRK’, as well as querying both endpoints (api/monitoring/metrics and api/editions/show_license) in short period of time.
Thanks a lot in advance, I believe this test will bring us bit more insight into the problem!
And one more question related to my last reply @marikath, have you noticed stale values for any of the remaining metrics returned in the response of api/monitoring/metrics?
For example, are the sonarqube_license_days_before_expiration_total and the sonarqube_web_uptime_minutes updating as expected?
Hello @aleksandrabozhinoska it seems I can’t figure out how I would do this SQL query that you have asked me to do. From what I could google it almost seemed like it is not recommended for users of sonarqube to do this. But perhaps that was an older post. If you know where instructions for how to do this is located could you please link me to it?
Yes, you are right, we do not recommend running queries against the database, to avoid the risk of potentially compromising the data. However, in this specific case, I asked for the query above to help us investigate the issue.
In order to run it, if you do not have access to the database, you would need to reach out to somebody who has it, and then they could run the query.
But if we cannot do that at the moment, we can leave it for later, as I would appreciate if you could answer the remaining questions from my previous two posts. Hope those will give us some lead!
Thank you for the fast reply @aleksandrabozhinoska calling on the api/monitoring/metrics I can see that the sonarqube_web_uptime_minutes goes up with each call. I can give an update of the sonarqube_license_days_before_expiration_total tomorrow but it seems to me that at least that value from calling this api gets updated.
Ok, so I made the same metrics call again today and both sonarqube_license_days_before_expiration_total and sonarqube_license_number_of_lines_analyzed_total had not updated at all since yesterday. Only sonarqube_web_uptime_minutes has updated since I last made the api call.
However, to be completely certain about this, let’s make sure that at least 24h have passed since you read the old value and it is still not updated when querying the endpoint. I would ask you if you could confirm this once more, please.
Hello @aleksandrabozhinoska ,
I have run it now again today after the weekend but the result is still the same sonarqube_license_days_before_expiration_total and the sonarqube_license_number_of_lines_analyzed_total have not updated at all while sonarqube_web_uptime_minutes keeps updating.
Sorry for the slight delay in the response, but I am happy to share that we have identified the cause of the problem.
In version 2025.1.2, we are not handling errors in the scheduled monitoring tasks properly, causing the monitoring tasks not to be executed anymore after an error occurs. Restarting the server would restart the monitoring, but only until the next error.
Good news is that this has been fixed in SonarQube Server 2025.3, and since this version any error that may happen in the monitoring tasks will not stop future update of the metrics, and will additionally be logged.
Therefore, my suggestion would be to upgrade your SonarQube Server to 2025.3.1, or even better, to upgrade to the latest release, which is 2025.4.2, to benefit from additional fixes and improvements.
Thank you for the information about the issue and the provided solution. We are using the LTA version of SonarQube which seems to still be on 2025.1, is this fix also planned for LTA and in which case which version/what timeframe is there for the fix?