LGTM Quarkus Dashboard

[melloware]

Fix #40933: LGTM Quarkus Dashboard
Fix #41944

cc @brunobat @alesj

• Adds Quarkus Micrometer Dashboard including JVM, HTTP, JDBC and other stats provided by Micrometer.
• I just need some guidance on the TODO how to get those values properly

[melloware]

OK I resolved that issue

[brunobat]

@melloware, back from vacations.
I wonder if we could deploy this dashboard on the grafana repository, as well.
Will need some time to review this.

[melloware]

yeah i put this here because i wasn't sure if we wanted to get feedback from other Quarkus Users if there was anything missing they want on there?

[melloware]

i also think the colors and times for uptimes might need to be tweaked but i thought it was a pretty good first stab 😄

[brunobat]

We need to make sure the app will return data for all the dashboard components and understand why they lack data or is we need to instrument something else...
I've used this app, which is basically the Quick start"https://github.com/brunobat/quarkus-lab/blob/main/micrometer-lgtm/pom.xml
But with it, out of the box, the dashboard looks like this:

[brunobat]

Also, we should pull up the HTTP parts.

[melloware]

Yes this was more of an idea, and we need to check the dashboard for startup time those eventually fill in if you leave the app running.

[melloware]

@brunobat ok i updated to move HTTP Endpoints up. Here is what mine looks like not sure why yours shows N/A at first nuless you are not wating 30 seconds for the scrape?

[brunobat]

@melloware strange... I waited a few minutes.
What app are you using to feed data to the dashboard?
I'd like to take a look at the dependencies.

[melloware]

Hmm i was just using a REST app with...

<dependency>
			<groupId>io.quarkus</groupId>
			<artifactId>quarkus-rest-jackson</artifactId>
		</dependency>
<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-observability-devservices-lgtm</artifactId>
    <scope>provided</scope>
</dependency>
<dependency>
			<groupId>io.quarkus</groupId>
			<artifactId>quarkus-opentelemetry</artifactId>
		</dependency>
		<dependency>
			<groupId>io.opentelemetry.instrumentation</groupId>
			<artifactId>opentelemetry-jdbc</artifactId>
		</dependency>
		<dependency>
			<groupId>io.quarkus</groupId>
			<artifactId>quarkus-micrometer-registry-prometheus</artifactId>
		</dependency>

[brunobat]

I understand what's going on now...
You have configured the prometheus scraper in the PR and I'm using the Micrometer OTLP registry that pushes things.
I think it makes sense to have both setups, however the visualizations will be different.

I wonder if the scraper could be activated by a property. I'm not sure if it should be on or off by default.
Ideally, all the output, in the future, should be OTLP (OpenTelemetry).

[melloware]

its just checking the Micrometer metric "expr": "process_start_time_seconds * 1000" which is exposed in the Prometheus metrics.

{
          "datasource": {
            "type": "prometheus",
            "uid": "prometheus"
          },
          "expr": "process_start_time_seconds * 1000",
          "format": "time_series",
          "intervalFactor": 2,
          "legendFormat": "",
          "metric": "",
          "refId": "A",
          "step": 14400
        }

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit fcd314f.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

[brunobat]

One solution can be the least common denominator and only show metrics available with both registries on the dashboard. What do you think @melloware ?

[alesj]

This things should be made configurable -- at least: enabled / disabled.
e.g. you don't need scraping always, some registry impls know how to periodically push metrics

[brunobat]

Yes and it can be done automatically.
You can refactor things a bit so you can use his data from the ExtensionsCatalog object:

quarkus/extensions/observability-devservices/deployment/src/main/java/io/quarkus/observability/deployment/ObservabilityDevServiceProcessor.java

Line 120 in 7a4be43

new ExtensionsCatalog(

[alesj]

OK, this can be used with actual DevServices, but not with the other 2 "flavours" - DevResource and QuarkusTestResource.
Where DevResource is pretty much non-configurable, so that might be a problem.
Where QuarkusTestResource can probably get this config via QuarkusTestResourceLifecycleManager::init ...

[melloware]

I will be the first to admit i am no expert on this stuff so any help is appreciated. I basically wanted to show how we can load our own dashboard and get metrics from the running DEV mode as currenlty the LGTM defaults have dashboards that do nothing?

[brunobat]

No worries.
I think we should probably show the minimum common denominator metrics. The ones common to both the Prometheus and the otlp registries.
This way, all metrics will show something and it's good enough to start with... It is also simpler to develop and it's just a meter of removing stuff from the dashboard.

[melloware]

Oh OK if you tell me which sections you want to "stay" i can rip all others out.

[brunobat]

Will come up with something tomorrow

[edeandrea]

We need this!