Features • Requirements • Installation • Usage • Metrics • Screenshots

• Configure which metrics to export

Supported SonarQube versions (compatibility)

If you need to target a specific SonarQube runtime, check pom.xml properties (sonar.apiVersion and sonar.pluginApiVersion) and build accordingly.

1. Download latest snapshot release
2. Drop sonar-prometheus-exporter-1.0.0-SNAPSHOT.jar into $SONARQUBE_HOME/extensions/plugins.
3. Restart the SonarQube server.

1. Configure which metrics you want to export under Administration → Configuration → General Settings → Prometheus Exporter
2. Add a scrape config to your Prometheus instance similar to this:

scrape_configs:
  - job_name: 'sonarqube'
    metrics_path: '/api/prometheus/metrics'
    static_configs:
      - targets: ['localhost:9000']

3. Alternatively, point your HTTP client to http://localhost:9000/api/prometheus/metrics
4. You can export the dashboard from this file:

  resources/grafana_dashboard.json

5. Prometheus configuration examples

Prometheus configuration examples are available under ./resources/prometheus/ in this repository (for example ./resources/prometheus/prometheus.yml). If you used the docker-compose.yml in the repo root, a sample Prometheus config is also provided at ./prometheus/prometheus.yml.

1. Which metrics can you export? This section outlines the key metrics related to code quality and analysis that can be exported from SonarQube. The exporter also adds a severity label when severity-specific metrics are detected (for example BLOCKER, CRITICAL, MAJOR, MINOR, INFO). This allows filtering in Grafana/Prometheus using the severity label (e.g. sonarqube_vulnerabilities{severity="CRITICAL"}).

• NCLOC: Stands for Non-Commented Lines of Code, representing the actual lines of source code excluding comments and blank lines.
• BUGS: Identifies coding errors that can lead to unexpected behavior or runtime issues.
• VULNERABILITIES: Highlights security weaknesses in the code that could be exploited.
• CODE_SMELLS: Points out maintainability issues that make the code harder to understand, modify, or extend.
• COVERAGE: Measures the percentage of code lines, branches, or conditions exercised by automated tests.
• TECHNICAL_DEBT: An estimation of the effort required to fix all Code Smells and maintainability issues, often expressed in time.
• COMPLEXITY: Typically refers to Cyclomatic Complexity, which measures the number of independent paths through the code, indicating how difficult it is to test and understand.
• LINES_TO_COVER: The number of executable lines of code that could potentially be covered by tests.
• VIOLATIONS: A general term referring to any instance where the code breaks a defined quality rule (encompassing Bugs, Vulnerabilities, and Code Smells).
• ALERT_STATUS: Indicates the overall quality gate status of the project (e.g., Passed or Failed), based on predefined conditions for key metrics.
• SECURITY_HOTSPOTS: Highlights security-sensitive pieces of code that require manual review to determine if a vulnerability exists.
• DUPLICATED_LINES: Shows the percentage or number of code lines that are identical or very similar to other code blocks, often indicating a need for refactoring.
• LINES: Show the total count of lines in your project.